The short version: find ten organisations with the same painful problem, get at least a few to commit money or serious time before you build, scope a first release around one workflow for one kind of customer, make three architectural decisions carefully (tenancy, identity, billing), launch to a small group, charge from the start, and let activation and retention decide what you build next. Plan on six to nine months from a validated idea to the first paying customers.
Stage 1: Validate before you build (2–8 weeks)
Building is the most expensive way to find out whether anyone wants the product. Cheaper evidence comes first, in roughly this order of strength:
- Problem interviews. Fifteen to twenty conversations with people in the target role. Ask how they handle the problem today, what it costs them and what they have already tried. People who have paid for a poor solution, or built their own spreadsheet, have a real problem.
- A manual or “concierge” version. Deliver the outcome by hand for a few customers using spreadsheets, email and off-the-shelf tools. You learn the workflow in detail, and you find out whether the result is worth paying for.
- Commitment. A signed letter of intent, a paid pilot, a deposit, or a design-partner agreement in which the customer commits time every week. Compliments are not commitment.
A reasonable bar before funding a build: three to five organisations that match your target profile and have committed money or structured time. If you cannot reach that, the problem is either not painful enough or you have not found the right buyer, and code will not fix either.
What to decide during validation. Who the buyer is and who the user is (often different people in B2B), what they pay for the problem today, and a first pricing hypothesis: per seat, per workspace or per unit of usage. Pricing shapes the product, so it cannot wait until launch.
Stage 2: Scope the first release (1–3 weeks)
The first release of a SaaS product is one workflow, for one customer segment, that one buyer would pay for. General feature prioritisation is covered in our step-by-step MVP guide; what follows is specific to SaaS.
What a sellable first release needs
- The core workflow, end to end, without manual intervention from you
- Sign-up, team invitations, and two or three fixed roles
- Every record scoped to a customer account (tenant)
- A way to pay: one or two plans, a trial, cancel and update card
- A first-run experience that reaches a useful result in one session
- Transactional email that arrives: verification, invitations, receipts, key alerts
- An internal admin view so you can support customers
- Error tracking, backups and basic product analytics
- Terms of service and a privacy policy
What can almost always wait
- Custom roles and permission editors
- A public API and webhooks
- Single sign-on, unless your first customers are enterprises that require it
- Annual billing, coupons, multiple currencies, referral schemes
- Native mobile apps
- Configurable dashboards and report builders
- White-labelling and custom domains
- Integrations beyond the one your design partners cannot work without
Write the result down as a scope document with acceptance criteria. It is what a fixed price and a timeline are based on, whether you work with an agency or your own team. For what each of these blocks costs, see SaaS development cost.
Stage 3: Get the expensive-to-reverse decisions right
Most early technical choices can be changed later at moderate cost. A few cannot, because they are woven through every table and every screen. Spend your architectural attention here and keep everything else simple.
| Decision | Sensible default | Why it is expensive to reverse |
|---|---|---|
| Tenancy model | One database, shared tables, a tenant ID on every row, enforced centrally | Retrofitting tenant scoping means revisiting every query, file, cache key and background job, and mistakes leak data between customers |
| Identity model | Users are separate from organisations; a membership record joins them and carries the role | If a user “belongs to” exactly one account, you cannot later support consultants, agencies or people who change employer without a migration that touches authentication |
| Authentication | A managed service or a well-maintained library, never hand-written | Moving users between auth systems means password resets or delicate hash migrations, and SSO added late is harder if identity was modelled loosely |
| Billing architecture | A hosted subscription provider as the source of truth; your database holds a synced copy of plan and status; plan limits defined in one place | Pricing will change. If plan checks are scattered through the code, every pricing change becomes an engineering project |
| What a “seat”, “workspace” or “unit” is | Defined in discovery, matching the pricing hypothesis | The billable unit shapes the data model, the limits and the invoices |
| Primary database | A relational database such as PostgreSQL | Business data is relational. Migrating a live product between database types is a major project |
| Data location | One region, chosen with your first customers’ requirements in mind | Moving customer data between regions later involves downtime, contracts and sometimes regulators |
Things that are not worth agonising over at this stage: the front-end framework, the hosting provider, the CSS approach, the job queue. Pick mainstream options and move on. Our SaaS tech stack and architecture guide goes through each layer and the tenancy models in detail.
Stage 4: Design and build (10–22 weeks)
Design comes first and covers more than the core screens. Sign-up, empty states, invitations, billing pages and error states are where new users form their opinion. Review a clickable prototype with two or three design partners before engineering starts; changes at that point cost hours.
A sensible build order:
- Foundations. Tenant model, authentication, memberships, roles, deployment pipeline, staging environment, error tracking.
- The core workflow, thinnest end-to-end path first, then depth.
- Billing in test mode, with plan limits enforced. Early, because it interacts with everything.
- Onboarding, email and the admin area.
- Hardening. Tenant-isolation tests, backup and restore rehearsal, performance on realistic data volumes, security review of the basics.
Insist on a staging link from the first weeks and show it to your design partners regularly. Their reactions during the build are worth more than any amount of feedback after it.
Who builds it
The options are a technical co-founder, in-house hires, freelancers or a studio. Each suits a different situation, and the right answer depends on your funding, timeline and how central engineering will be in the long run. We compare them in how to hire developers for a startup. If you choose an external team, BBR’s SaaS development service describes how we run this stage.
Stage 5: Private beta (4–8 weeks)
Launch to your design partners and a small number of invited customers before opening sign-up. The aims are narrow:
- Watch real onboarding. Sit in on the first session if customers allow it. Note every hesitation.
- Migrate their real data. It will be messier than your test data and will expose assumptions.
- Charge them. Card entered, invoice issued, plan limit reached, cancellation tested.
- Fix what blocks them weekly. Responsiveness at this stage wins references.
The exit criterion is not a date. It is that new beta customers reach the first useful result without your help, and the first ones are still using the product a month later.
Stage 6: Launch and first customers
For B2B SaaS, launch day is rarely an event. It is the point at which you open sign-up and begin repeatable customer acquisition: direct outreach to the segment you validated, the communities those people already use, content that answers what they search for, and marketplaces or integrations if your product sits beside a larger platform. Early customers come mostly from founder-led sales. Keep doing the onboarding calls yourself long after it feels inefficient, because they are your best source of product direction.
Operationally, before opening the doors:
- Monitoring and alerts reach a person, not only a dashboard
- Backups restore successfully (tested, not assumed)
- Support address monitored, with a simple status page
- Email domain authenticated so that messages reach inboxes
- Billing live, with failed-payment emails switched on
- A way to give customers their data and delete it on request
The metrics that matter early
With a few dozen customers, averages are noisy and dashboards can mislead. Track a short list and read individual accounts alongside the numbers.
| Metric | What it tells you | Early-stage note |
|---|---|---|
| Activation rate | Share of sign-ups that reach the first useful result | Define the activation event precisely. This is usually the first thing to fix |
| Time to first value | How long activation takes | Minutes or one session is the goal for self-serve products |
| Trial-to-paid conversion | Whether the value shown is worth the price | Read alongside the reasons given by those who did not convert |
| Weekly active accounts | Whether the product is part of a routine | Count accounts, not only users, in B2B |
| Logo retention and churn | Whether customers stay | Follow monthly cohorts. Talk to every churned customer |
| Net revenue retention | Whether existing customers grow or shrink | Becomes meaningful after six months or more |
| MRR | The scoreboard | A result of the rows above, not a lever |
| Support requests per account | Where the product confuses people | Group by topic; the top group is your next usability fix |
The usual order of problems: activation first, then retention, then acquisition. Spending on acquisition before the first two are healthy fills a leaking bucket.
A realistic timeline
| Stage | Typical range | Can overlap with |
|---|---|---|
| Validation | 2–8 weeks | Nothing; do it first |
| Discovery and scoping | 1–3 weeks | Late validation |
| Design | 2–4 weeks | Start of foundations work |
| Build | 8–18 weeks | Design-partner reviews throughout |
| Private beta | 4–8 weeks | Continued development |
| Open sign-up and first paying customers | Ongoing | Monthly iteration |
Added up with sensible overlap, that is around six to nine months. Products with a single simple workflow and customers already waiting can do it in four. Products with integrations into slow-moving enterprise systems, or regulated data, take longer, and the delay is usually on the customer and compliance side, not in the engineering.
Mistakes that cost the most
- Building for a year in private. Every month without customer contact increases the chance of building the wrong thing.
- Several segments at once. A product for “any business that schedules things” has no clear buyer. Narrow wins first.
- Free pilots with no end. They produce polite feedback and no evidence.
- Treating pricing as a launch-week task. It determines the data model and the limits.
- Single-tenant thinking. Building for the first customer’s specifics and discovering that the second customer works differently.
- No budget after launch. The first release is the beginning of the spend, not the end. Ongoing iteration is what our product engineering model exists for.