SaaS Product Development

Build your SaaS once.

Most first versions get rewritten within two years. We build yours multi-tenant, billing-ready and easy to change, so the code that wins your first customer can carry your thousandth.

Start a SaaS project See the 12-week plan
SaaS products launched
24
a year billed through code we built
$14M
years building multi-tenant products
9

Fig. 1 — A billing screen from a SaaS we'd build, marked up the way we review our own work.

  1. Upgrade mid-month? Prorated to the day.
  2. Seat limits come from the plan, not the code.
  3. Card fails? Three retries and a kind email. Access stays on.
  4. VAT on every invoice, in the customer's country.

01Start where you are

Every SaaS is at one of three stages. Start with yours.

Pick the one that sounds most like you. The plan, the team and the price change with it.

Sounds like you if

  • You've talked to customers, and a few will try it first.
  • There's a date: a pilot, a funding round or a conference.
  • You need a product that holds up after the demo, not just for it.

What we'd do

  1. One week of discovery: scope, risks and a fixed quote.
  2. A clickable prototype, tested with five real users.
  3. Ten weeks of building, with a demo every Friday.
  4. Launch, then 30 days of fixes while your first customers settle in.
Timeline
10–14 weeks
Team
Product lead, designer, two engineers, QA
Typical investment
$25k–$80k, fixed price
First thing you'll see
A clickable prototype in week 2
Talk about launching

Sounds like you if

  • You have paying customers and a backlog that keeps growing.
  • Every release breaks something that used to work.
  • New sign-ups drop off before they ever see the value.

What we'd do

  1. A two-week audit of code, infrastructure and onboarding, written up.
  2. Fix the foundations first: tests, CI/CD and monitoring.
  3. Rework onboarding around the moment users first get value.
  4. Ship your roadmap in two-week cycles, without a rewrite.
Timeline
Audit in 2 weeks, then ongoing
Team
A dedicated squad of four or five
Typical investment
From $12k a month
First thing you'll see
An audit report you keep, whoever does the work
Talk about your product

Sounds like you if

  • Enterprise prospects send you security questionnaires.
  • Customers ask for SSO, roles and audit logs before they sign.
  • The database starts to sweat at peak times.

What we'd do

  1. SSO with SAML and OIDC, detailed roles and audit logs.
  2. Performance work: caching, queues and read replicas.
  3. SOC 2 readiness: policies, logging and evidence.
  4. Uptime targets, with on-call, alerting and a status page.
Timeline
6–12 weeks per project
Team
A senior squad, plus DevOps
Typical investment
From $18k a month, or fixed projects
First thing you'll see
A scaling plan, ranked by revenue at risk
Talk about scaling

02The other 60%

The 60% of a SaaS nobody budgets for.

Customers pay for your core feature. They stay because of everything around it. It's where rushed MVPs cut corners, and where rewrites come from.

Part 01 of 08

Sign-up and onboarding

  • Sign-up with email, Google or Microsoft
  • A first-run checklist that gets people to value fast
  • Invites, so one user brings their whole team

The mistake we see most

Asking for everything up front. Every extra sign-up field costs you users. Ask later, when it matters.

Usually live by week 4

Part 02 of 08

Accounts, teams and roles

  • Workspaces that keep each customer's data apart
  • Owner, admin and member roles, ready to extend
  • Account switching for people in more than one team

The mistake we see most

Tying data to users instead of accounts. The day a customer buys a second seat, everything has to move.

Usually live by week 4

Part 03 of 08

Plans and billing

  • Plans, trials and per-seat or usage pricing on Stripe
  • Upgrades and downgrades with proration
  • Failed-payment retries, receipts and tax

The mistake we see most

Letting payment events switch features on and off directly. One delayed webhook and a paying customer is locked out.

Usually live by week 6

Part 04 of 08

Admin back office

  • Find any customer and see their plan and activity
  • See exactly what a customer sees, safely, to debug
  • Refunds, credits and plan changes without an engineer

The mistake we see most

Skipping it. Then every support question becomes a database query, run by your most expensive engineer.

Usually live by week 8

Part 05 of 08

Emails and notifications

  • Transactional emails that land in the inbox, not spam
  • In-app notifications with per-user preferences
  • Digest emails that bring people back

The mistake we see most

Sending everything, instantly. Batching and preferences are the difference between useful and unsubscribed.

Usually live by week 8

Part 06 of 08

Product analytics

  • An event plan agreed in week 0
  • Activation and retention dashboards
  • Feature usage by plan, to guide your pricing

The mistake we see most

Adding tracking after launch. By then you've lost your first cohort, the one that teaches you the most.

Planned in week 0, dashboards by week 9

Part 07 of 08

Integrations and API

  • Webhooks, so customers can react to events
  • A documented, versioned public API
  • Connections to the tools your buyers already live in

The mistake we see most

Publishing an unversioned API. Your first breaking change breaks your best customers' integrations.

Usually live by week 10

Part 08 of 08

Security and audit trail

  • Tenant isolation enforced by the database
  • An audit log of who changed what, and when
  • SSO and two-factor sign-in, when customers ask

The mistake we see most

Treating security as a phase before launch. Adding isolation and logging later costs far more than building them in.

From week 1, reviewed before launch

03Your first 12 weeks

What the first 12 weeks look like.

This is the plan for a typical stage 1 project. Yours will be drawn in week 0, with your features in it.

Read the full playbook
Twelve-week plan. Discovery in weeks 0 and 1. Product design from week 1 to 5. Accounts and sign-in in weeks 3 and 4. Billing in weeks 5 and 6. Core product from week 4 to 11. Admin, emails and analytics from week 7 to 9. Integrations in weeks 9 and 10. Testing and security reviews throughout. Launch in weeks 11 and 12. A demo every Friday. Milestones: prototype tested in week 2, first subscription in week 6, beta in week 10, launch in week 12.

  1. 1Week 2

    Prototype tested

    Five future customers have clicked through it. You know what to build first.

  2. 2Week 6

    First subscription

    Sign up, create a team and subscribe with a test card, on a real URL.

  3. 3Week 10

    Beta

    Your design partners use it for real work, and we fix whatever they hit.

  4. 4Week 12

    Launch

    Live for paying customers, with monitoring, backups and a proper handover.

Your squad, week by week

You meet all five before you sign. Nobody gets swapped out after.

  • Product lead

    50%

    Owns scope, priorities and your weekly update.

  • Product designer

    100% → 50%

    Prototype and design system first, then polish.

  • Two senior engineers

    100%

    Full-stack. One leans backend, one frontend.

  • QA engineer

    25% → 100%

    Tests every sprint and owns the release checks.

  • DevOps engineer

    On call

    Infrastructure early, launch readiness late.

04Decisions we make early

Decided in week one, so you don't pay for it in year two.

Our defaults, written the way engineers record decisions: what we choose, why, and when we'd choose differently.

ADR-001Default

Multi-tenant from the first commit

Why
Adding tenancy later touches every table and every query. It's the most common reason a first version gets rewritten.
We'd change it if
You'll only ever have a handful of enterprise customers, each wanting their own deployment.
Revisit: rarely, if ever
ADR-002Default

The database keeps tenants apart, not just the code

Why
With Postgres row-level security, even a query that forgets a filter can't return another customer's data.
We'd change it if
A contract requires a separate database for each customer.
Revisit when: first regulated deal
ADR-003Default

Billing on Stripe, never home-grown

Why
Proration, retries, tax and invoices are a product of their own. Stripe Billing has already solved them.
We'd change it if
You sell to consumers worldwide and want someone else to handle sales tax. Then it's Paddle, as merchant of record.
Revisit when: fees outgrow a billing team
ADR-004Default

Access comes from plans, not payments

Why
Payment events update what a customer is entitled to, and features read entitlements. A late webhook never locks out someone who has paid.
We'd change it if
We wouldn't. This is the one default we don't bend.
Revisit: never
ADR-005Default

Ship daily, behind feature flags

Why
Work merges every day and stays hidden until it's ready. Releases are small, rollbacks take seconds, and chosen customers can try features early.
We'd change it if
Your industry requires formal release windows. Then we batch releases and keep the flags.
Revisit when: approvals slow releases
ADR-006Default

Product analytics from day one

Why
You can't improve activation you can't see. We agree the event plan in week 0, so your first customers are measured.
We'd change it if
Your customers' contracts forbid behavioural tracking. Then we measure on the server only.
Revisit when: real usage data arrives

05A SaaS we built

LP Lumen PayFintech · United Kingdom · B2B SaaS

From a PDF form to self-serve onboarding in 12 weeks.

Before
New business customers filled in a seven-page PDF. Ops staff retyped it, chased missing documents by email, and onboarding took nine days.
What we built
A multi-tenant onboarding product with automated ID checks, a review queue for the compliance team, and per-seat billing for partner banks.
After
Most customers finish in one sitting. Three partner banks now resell it under their own brand.
faster onboarding
3.2×
weeks to launch
12
critical incidents in 90 days
0
“They pushed back on half our feature list in week one. That's why we launched on time.”
Amelia Hart, COO, Lumen Pay
Ask for the full case study

Honest advice

Sometimes the best SaaS build is no build.

We'll tell you on the first call which of these you are, even when the answer isn't "build".

  1. Don't build yet

    If nobody has paid you yet.

    Test demand with a landing page, a payment link and a manual service behind it. We can help set that up in days, not months.

  2. Buy and adapt

    If a tool already does 80% of it.

    Use it, and build only the missing 20% as an integration or add-on. It's faster to launch and cheaper to run.

  3. Build

    If your workflow is the product.

    When the way you work is what customers pay for, owning the software is your advantage. That's where we come in.

06What it costs

Rough numbers, before you have to ask.

These are the ranges most projects land in. Your price is fixed in writing after a short discovery.

Stage 1 · Idea to launch

Your stage

$25k–$80k

Fixed price · 10–14 weeks

  • Discovery, prototype and MVP
  • Accounts, billing, admin and analytics
  • Launch and 30 days of fixes
Plan your MVP

Stage 2 · Launch to traction

Your stage

From $12k

Per month · dedicated squad

  • Two-week audit, written up
  • Foundations fixed: tests, CI/CD, monitoring
  • Your roadmap in two-week cycles
Book an audit

Stage 3 · Traction to scale

Your stage

From $18k

Per month · or fixed projects

  • SSO, roles and audit logs
  • Performance and uptime work
  • SOC 2 readiness
Plan for scale

What moves the price

  • How many kinds of user there are, and what each can do
  • Your billing model: usage-based costs more than per-seat, per-seat more than flat
  • The number of integrations with other tools
  • Compliance needs, such as HIPAA or SOC 2

Always included

  • Your code, cloud and Stripe accounts, in your name from day one
  • Automated deploys, monitoring and backups
  • Documentation and a handover your team can use
  • 30 days of fixes after launch

FAQ

Questions founders ask us about SaaS.

Further reading

Can you take over an MVP another team built?

Yes. We start with a two-week audit of the code, infrastructure and product, and share a written report with a plan. The report is yours whoever does the work, and most takeovers continue without a rewrite.

Will it be ready for enterprise customers?

The foundations will be: tenant isolation, roles and an audit trail from the start. Features such as SSO and custom contracts are added when a real customer asks, which keeps the first version lean.

Do you help with pricing and plans?

Yes, as part of discovery. We model plans, trials and limits with you, and build billing so prices can change without a release. For deep pricing strategy we can introduce a specialist.

Which compliance standards can you support?

GDPR by default, HIPAA-ready builds for health products, and SOC 2 readiness: the controls, logging and evidence an auditor asks for. We work alongside your auditor rather than replacing one.

Who owns the code and the Stripe account?

You do, from day one. Repositories, cloud, Stripe and analytics accounts are created in your company's name, and we're invited as collaborators.

What happens after launch?

Thirty days of fixes are included. After that, choose a support plan with guaranteed response times, keep the squad for the next roadmap, or hand over to your own team with full documentation.

Tell us about your SaaS.

Send one paragraph: who it's for, who pays, and when it needs to be live. Our CTO reads every SaaS enquiry and replies within one business day.

Start a SaaS project Book a 30-minute call