A playbook for founders and product leads who have an idea for a software product and no revenue yet. Its goal is deliberately narrow: the first customers who pay for the job the product does. Not a launch event, not a valuation — revenue from one real customer journey. It follows the Guild's twelve-chapter format: the problem first, the checklist last.
The problem
First releases fail in recognisable ways. The product is built for everyone, so nobody's journey is complete. It has ten half-finished features instead of one finished path. It launches before anyone has agreed to pay, so the price is a guess nobody has tested. Or the team builds infrastructure for a scale that never arrives.
Each of these spends the scarcest resource a new product has — the months before the money runs out — on something other than learning whether anyone will pay.
Concept overview
The playbook rests on three ideas.
- One customer. A specific person in a specific kind of organisation, with a job they already do badly or expensively today.
- One journey. The path from "I have this problem" to "the product solved it once": sign up, set up, do the job, see the result. This is the first valuable customer journey, and the release is framed around it.
- One price. A charge for that result, asked for early.
First revenue means a customer paying for the journey from their own budget — not a pilot fee quietly waived, not a letter of intent, not a friend being kind. It is the cheapest strong evidence a product idea can get. This is the minimum viable product idea applied strictly: the smallest release that tests whether people will pay, not the smallest release that can be demonstrated.
When to use this
Use it when you have a product idea that has not launched, an early product with users but no revenue, or an internal tool you want to sell to others.
It is less useful when you already have paying customers — then the questions are retention and expansion — or when the product cannot be sold before a long certification process. In that case, treat a funded pilot as the first revenue milestone and apply the playbook to it.
Architecture: the thinnest system that can take money
The first release needs every layer, but only a thin slice of each.
| Layer | Must have in release one | Can wait |
|---|---|---|
| Access | Sign-up, sign-in, password reset; roles if the buyer and the user differ | Single sign-on, provisioning, fine-grained permissions |
| The journey | Every step of the first valuable journey, complete and reliable | Adjacent journeys, settings, customisation |
| Billing | One plan, card or invoice payment, receipts | Tiers, usage billing, coupons |
| Data | A model that fits the journey, separation between customers, backups | A warehouse, exports, integrations nobody has asked for |
| Operations | Error tracking, uptime alerts, a support channel | A status page, an on-call rota |
| Measurement | An event for each journey step and for payment | Dashboards for everything else |
The Guild's MVP Launch path for SaaS products is scoped to up to five core functions, with an eight-week target. Most of this playbook is about choosing which five.
Core components
The customer statement
One paragraph: who the customer is, what job they need done, how they do it today, what that costs them, and roughly what they would pay to make the problem go away. If you cannot write it, you need conversations, not code.
The journey map
The steps from first contact to first result. For each: what the customer does, what the product does, and what can go wrong. Mark the moment of value — the point where the customer would say "that worked".
The scope line
Everything on the journey is in. Everything off it is out. Features that serve a different customer or a later journey go on a visible "later" list rather than into the release.
The price hypothesis
A price, a unit (per user, per account, per transaction) and a reason, anchored in what the job costs the customer today. You will be wrong. Write it down so that you can be wrong precisely.
The measurement plan
Five numbers: sign-ups, activated customers (those who reached the moment of value), time to value, conversion to paid, and customers still active after thirty days.
Implementation
- Talk to customers first. At least ten conversations with people who have the problem. Ask about what they did last time, not whether they like your idea; listen for the current workaround and what it costs.
- Write the customer statement and the price hypothesis, then ask for a commitment before the build: a paid pilot, a pre-order, or at least an agreed price.
- Map the journey and draw the scope line. Agree both with whoever is paying for the build.
- Design the architecture for the journey, with the must-haves from Figure 1 and nothing more.
- Build in vertical slices. Each slice is one step of the journey working end to end, shown to a real prospective customer. Each stage produces evidence before the next commitment.
- Launch to a small cohort, starting with the people from step 1. Onboard them personally and watch where they stop.
- Charge from the start. A trial is fine. Free forever for the first cohort teaches you nothing about price.
- Review weekly. Where did people stop, who paid, and why did the others not? Finish the journey before adding to it.
Athena note — A first release rarely grows too wide in one decision. It grows one good idea at a time. The scope line holds when every request has to answer a single question: which step of the journey does this complete?
Evaluation
Measure the journey, not the feature list.
- Activation — the share of sign-ups who reach the moment of value.
- Time to value — how long it takes to get there. Shorter beats richer.
- Conversion — the share of activated customers who pay.
- Early retention — the share of paying customers still using the product after a month.
- Support load — questions per customer. A high number usually points to a journey step that is not finished.
Set a target for each before launch. Release one has done its job if you know which number is weakest and have revenue to show for it.
Security and governance
Small is not an excuse for careless. From the first release:
- use proven identity and payment providers rather than building your own;
- enforce the separation between customers' data in the data layer, deny by default, and test that one customer cannot reach another's records;
- keep secrets out of code, and give production access to as few people as possible;
- take backups, and restore one at least once to prove they work;
- publish a privacy notice that matches what the product actually collects;
- give any AI feature the same rules as any agent: approved data, bounded actions and a person accountable for it (The Governed Agent Blueprint).
On the Guild's SaaS missions, security and readiness is Sentinel's part of the work, while Hephaestus leads engineering and delivery and Atlas looks after systems and integration.
Cost considerations
The build is the visible cost. The others arrive later: hosting, email, monitoring and other services that grow with usage; payment fees; support time, usually the founder's; and the features nobody pays for, which keep costing in maintenance long after they ship.
The levers are simple. Hold the scope line. Prefer managed services in release one. Remove features the first cohort does not use. Work out the cost of serving one active customer early, so that the price reflects it.
Example
Illustrative example, not a client engagement.
A founder wants to build booking software for independent physiotherapy clinics. Conversations with clinic owners show that the expensive problem is not booking but missed appointments: every no-show is lost income, and receptionists spend hours phoning patients to confirm.
The customer statement names clinic owners with two to six practitioners. The first valuable journey: the clinic connects its calendar, patients receive reminders with a one-tap confirm or reschedule, and the owner sees which appointments were missed. The scope line excludes patient billing, clinical notes and a mobile app. The price hypothesis is a monthly fee per practitioner, set below the value of one recovered appointment.
Release one has five functions: clinic sign-up, calendar connection, reminder rules, patient confirm or reschedule, and a weekly missed-appointment report. The clinics from the first conversations are onboarded by hand. If most of them pay after the trial, the hypothesis has survived its first test; if owners keep mentioning the weekly report rather than the reminders, that tells the team what release two is for.
Failure modes
| Failure | What you see | What fixes it |
|---|---|---|
| Everyone is the customer | Features for three segments, none complete | One customer statement; a visible "later" list |
| Feature first | Many screens, no complete journey | Vertical slices along the journey |
| Free forever | Busy users, no revenue, no signal about price | Charge from the first cohort |
| Premature scale | Infrastructure for a million users before the tenth customer | Managed services; build for the next step, not the third |
| Silent churn | Sign-ups who never return, unnoticed | Events for every journey step; personal onboarding |
| Unowned launch | Nobody watching errors or support after go-live | Operations basics in release one; a named owner |
Checklist
- A one-paragraph customer statement exists, and real customers recognise it.
- The first valuable journey is mapped, with its moment of value marked.
- Everything off the journey is on a visible "later" list.
- A price, a unit and a reason are written down.
- At least one customer has agreed to pay before the build is finished.
- Release one includes access, the whole journey, billing, data separation, backups, error tracking and support.
- One customer cannot reach another's data, and that is tested.
- Every journey step and every payment emits an event.
- The first cohort is onboarded personally.
- Activation, time to value, conversion and early retention have targets.
- A named person owns the product after launch.
