A digital product is built in phases. Each one is quoted when the previous one closes, once you know what's inside.
01
Product design
Architecture, data model and a clickable prototype. It ends with a firm quote for the MVP.
02
MVP in production
A working product with real users on it, who use it every day.
03
Product v1
The complete modules and the billing cycle, now with real usage data to decide what to build.
∞
Evolution
The phase that never ends. Whoever built it keeps it alive.
Product design is required before any MVP: it's what makes a serious quote possible and lets you commit without betting the whole project at once. It's deducted if you go ahead.
The scope
What sits underneath a SaaS.
A SaaS is a product used by many companies at once, each seeing only its own data, that someone pays a recurring fee for. What the customer sees is the small part. Underneath sit the engineering and infrastructure that decide whether it holds up.
What your customer sees
app.yourproduct.com/orders
AAcme Inc.▾
Orders
Customers
Reports
Settings
Admin
Orders+ New order
This month
Pending
Issues
Paid
Pending
In progress
Paid
And the engineering that holds it up
01
Multi-tenant architectureEvery customer isolated in every query
organization in every table
RLS in Postgres
02
API and business rulesA validated, documented contract
server-side permissions
audit log
03
Background workHeavy lifting, out of the user's way
queue with retries
idempotent webhooks
04
Continuous deliveryEvery change tested before it ships
automated tests
zero-downtime migrations
rollback in minutes
05
Elastic, secure infrastructureScales with usage and defends itself
more machines as usage grows
encryption at rest and in transit
firewall and abuse control
06
Monitoring and backupsIf something fails, someone knows
tracing and alerts
tested restores
None of this shows up in a demo. Without it, the product falls over with its first big customer. How much of each layer yours needs is decided during design.
How it's built
The work you don't see, in four steps.
They go in order: the first step is settled in phase 01 and the other three are built into the MVP.
01
The architecture gets worked outBefore any code
Some architecture decisions can't be changed later without rewriting the product. That's why they're made before any code is written.
The biggest is how each customer's data is kept apart. In a SaaS, that runs through every table and every query, and everything else hangs off it. Along with it come the data model, who can see and change what, and what happens when someone stops paying. It gets drawn up and agreed with you before any code is written, because it's the part that can't be moved later.
02
Known patterns get appliedNothing improvised
Most SaaS problems already have a known, documented solution. That's the one we use.
Billing every month, retrying a payment without duplicating it, moving heavy work out of the user's way, changing the data model without downtime: each of those is a documented pattern. Using them, instead of inventing a home-grown solution, is what makes the product predictable and easy to maintain. If you ever wanted to hand it to another team, they'd find pieces they recognize, not somebody's bright idea.
03
The infrastructure holds upResilience
The infrastructure is built so the product keeps working when usage spikes or a server goes down.
Heavy work (sending a thousand emails, generating invoices, processing a file) goes into a queue and several servers share it out, so nobody waits in front of the screen. If one goes down, the others carry on and the job gets retried. If usage goes up, more machines come in; if it drops, they shut down and the bill drops with it. Backups are actually restored at least once. And alerts go off on a specific person's phone.
04
It integrates with what you already haveWithout replacing it
The SaaS connects to the tools you already use. You don't have to replace them.
Recurring billing, which comes in phase 3, is handled by a payment provider such as Stripe, which takes care of the cards: we never see or store them. Invoicing can go to QuickBooks or whatever accounting software your accountant already uses, so nobody copies an invoice by hand. The same goes for your CRM, transactional email, e-signature or your ERP. Each integration is looked at separately, because each depends on what the other side allows. They're quoted separately.
What's included
What an MVP in production includes.
Six things, almost all of them in the part nobody sees. They're what it takes to have real people using it.
Core flows plus two business flowsWorking with real usersSign-up, sign-in and roles, plus the two basic business flows agreed during design, end to end and in production, with outside people actually using it. What counts as a flow.
Many companies, one platformData isolated per organizationThey all share the same installation and none of them sees anything of another's. It's the decision that runs through the whole model, which is why it's there from day one.
Who can touch whatAccounts, roles and permissionsEach role sees and changes only what's theirs, checked on the server. Hiding a button isn't a permission.
To run it without calling usAdmin panel and alertsOnboard someone, fix a record or see what happened with a customer. And alerts that reach a specific person's phone.
Everything in your nameRepository and infrastructureFrom day one. If you ever want to take it to another team, there's nothing to untangle and nobody to ask for permission.
At handoverDocumentation and a 60-day warrantyHow it's put together and how it's deployed, written for an outsider. And two months in which anything that doesn't work as agreed gets fixed at no cost.
What a flow is
A flow is measured by its use cases.
A flow is the complete path someone follows to get something done inside the product. How big it is comes down to its use cases: everything a role can do along that path, with its rules, its states and what happens when something fails. The number of screens says little.
The MVP includes all the core flows (the ones every SaaS has) and two basic business flows (the ones that make your product unique). A complex flow isn't part of that price: it's scoped during design and billed separately.
Always included · don't use up your two flows
Core flows: the ones every SaaS has.
Sign-up, sign-in, password recovery, team invitations and roles. They look alike in every product and nobody gets in without them, so they're included and don't count against the two business flows. Being included doesn't mean they're small: sign-up alone is six steps.
Sign-up use cases
Sign up step by step
Verify the email
Resend the email if it doesn't arrive
Reject an expired link
Block an email that's already registered
Create the organization and its admin
Six steps and two services. None of them is about your business: that's why it's included and doesn't use up either of your two business flows.
Core flow: sign-up: Step-by-step sign-up → Account in Firebase Auth → Verification email → Link gets validated → Organization created → Into the dashboardCounts as a business flow
Basic business flow: inside your platform.
What makes your product unique, handled with your own data and without depending on any outside service. The two flows in the starting price are this size.
Task board use cases
Create a task
Assign it to a teammate
Notify the assignee
Change its status
Comment and attach files
See overdue tasks on the board
Everything happens inside your platform: a flow this size is one of the MVP's two.
Basic business flow: task board: Task created → Owner assigned → Assignee notified → Status changes → Comments and attachments → Manager's boardScoped and billed separately
Complex business flow: several systems you don't control.
When the path crosses the frontend, the backend and third-party services (payment provider, invoicing, email), each integration brings its own use cases: payments confirmed late, notifications that arrive twice, invoices that need correcting. That's why
it isn't one of the two in the starting price: it's scoped in the design phase by counting its use cases and billed separately. And if it involves billing, it goes in phase 3 or is quoted separately, like the rest of billing. Why a repeated notification ends up as a double charge is explained in the article on idempotency.
Checkout use cases
Pay with 3-D Secure authentication
Confirm the payment even if the tab is closed
Don't charge twice if the notification arrives twice
Issue the invoice in the invoicing service
Send the confirmation with the invoice
Retry a declined payment
Refund and correct the invoice
Every amber box is a system you don't control, and each fails in its own way: it isn't one of the MVP's two and it's billed separately.
Complex business flow: checkout: Cart and billing details → Order and payment attempt → Payment provider → Payment webhook → Invoicing SaaS → Email system → Order confirmed → Payment declined
Security
Many customers on one system, each in their own space.
In a SaaS, many companies' data lives in the same system. Besides working, it has to make sure none of them ever sees another's data and that nothing gets lost.
Every customer isolatedEach company's data is kept apart in every query, so a bug on one screen can't expose another's. How it's isolated is decided during design.
Permissions on the serverWho can see and do what is decided by the server on every request. Every change is logged, with who made it and when.
Encryption and defenseData encrypted at rest and in transit, a firewall and abuse control against repeated attempts. Where it's hosted and under which jurisdiction is decided during design.
Backups that have been restoredAutomatic backups and, before going live, at least one real restore. A backup that has never been restored may fail on the day you need it.
How long a session lasts and who can end it is also decided during design, because it shapes everything else. There's more in our article on where to store sessions.
Handover
Real production, verified.
On handover day, this list gets checked with you watching.
The core flows and the two business flows working end to end in production.
Sign-up, sign-in and password recovery working.
Admin panel with the agreed operations.
Backups tested with a real restore.
Alerts active and reaching a specific person.
Architecture and deployment documentation handed over.
Repository, infrastructure and accounts in your name.
After that, a 60-day warranty on defects. The code is yours from the final payment.
New
Already have a prototype that keeps breaking?
It gets built fast with Lovable, Bolt, Cursor or a no-code tool, works in the demo, the first customers come in and it starts falling over, because it was never designed to handle simultaneous users, permissions, payments or data migrations.
What happens when real users arrive
prototype production
10 users1001,000
Prototype diagnosis
One week. What holds up and what doesn't, where the cracks are in security, performance and data, and what it would cost to rebuild. It's deducted if you go ahead.
Software engineering
Backend and architecture rebuilt to production standards, keeping the product you've already validated: the flows, the interface and everything learned from real users.
The prototype's code is replaced in full: we don't work on other people's code.
Afterwards
The phase that never ends.
A live product with paying customers needs someone keeping an eye on it. The people who built it look after it. It's a separate contract and you can start whenever you like, including later on.
01
€390/month
Monitoring of the service and its errors, security patches, a response within 48 business hours to any incident, and a monthly report.
02
€890/month
Everything above, plus four hours a month for improvements that don't warrant a project, an 8-hour response and a quarterly architecture review.
03
€1,600/month
Everything above, plus ten hours a month, a 4-hour response, after-hours on-call and uptime targets agreed in writing.
Prices are published.
With the starting price, exactly what it covers and what moves each quote.