What is the difference between an MVP and a production V1?

An MVP answers “does anyone want this?” and may depend on you to work. A production V1 answers “does it hold when a customer uses it every day?”: auth, solid data, real payments, email, handled errors, admin, monitoring. The boundary is the first paying customer.

What does a production-ready SaaS need?

Authentication, authorisation, a solid data model, error handling, billing, transactional email, analytics, an admin interface, support tooling, logs, monitoring, security, backups, rate limits, handled edge cases, exports, privacy and recovery paths. The full list is on this page.

How long does it take to build a SaaS V1?

Four to six weeks of sprint after a week of scoping, with a demo every Friday. Week one lays down data and auth; weeks two and three deliver the core flow and payments; the following weeks build what makes the product hold.

Can we start from the existing prototype?

Sometimes for the interface, rarely for the data. A prototype usually has a data model designed for the demo; I re-lay it in week one rather than pay for it in week ten. Scoping says so plainly.

What happens after the V1?

The product is yours, with thirty days of support. What follows is decided with the first customers: each evolution is a new scoped fixed fee, or your team takes over — the code is built for that.

SaaS V1 · Production

SaaS V1 development.

A prototype only needs to demonstrate an idea. A V1 needs to survive its first real customer. That is what I build: the first version of a SaaS that stands on its own — authentication, authorisation, a solid data model, error handling, billing, transactional email, analytics, an admin interface, logs, monitoring, security and backups — without the features that can wait for the second customer.

Scope a V1 Read: Prototype or v1 ↓Contact form

Updated 17 Oct 2026

In brief

Thesis: A prototype demonstrates. A V1 survives its first customer.
Timeline: 4-to-6-week sprint, demo every Friday
Range: CHF 20’000 – 45’000 fixed fee depending on scope
Build order: Data → auth → core flow → payments → email → admin → observability → deployment
What waits: Advanced multi-tenancy, public API, secondary integrations, customisation, native mobile
In production: Atamatax · Horvera · Wabiro — built with this list

The question is not “how many features” but “what happens when it goes wrong”. A first customer will enter unexpected data, pay with a card that fails, forget their password, ask for an export, and write to support at 10pm. A V1 is the version that absorbs all of that without you opening the database.

This page is the list of what a production-oriented V1 contains — in the order I build it — and what it deliberately does not. It works as a reference for scoping a project, including with someone other than me.

01 — What a V1 contains

What a production-oriented V1 must contain

Eighteen elements. None is a feature the customer asks for; all are what keeps you from losing them.

Authentication: Sign-up, sign-in, reset, email verification, server-side sessions, brute-force protection. The first screen a customer sees, and the first that breaks in a prototype.
Authorisation: Who can see and do what — modelled in the database (account, role, resource), checked on every read and write on the server. An interface that hides a button is not authorisation.
Data model: The Postgres schema with its constraints, indexes and versioned migrations. Laid down first, because it is the only element the rest of the product cannot work around.
Error handling: Every failure has a message for the user, an entry in the log and, if serious, an alert for you. A V1 that fails silently loses customers without anyone knowing.
Billing: Stripe with signed webhooks, subscription state in the database, invoices, failed payments, plan changes, cancellation. Tested with the test cards for every case — not only success.
Transactional email: Welcome, verification, receipt, failed payment, reset — from a verified domain, with a send log. The channel through which your product speaks when the user is not on it.
Analytics: The events that say whether the product is used: sign-up, activation, key action, payment, churn. Without them, month two is flown blind.
Admin interface: Search an account, see what it did, fix, refund, deactivate. The first support ticket arrives before the first feature request.
Support tooling: A way to see what the user sees — their data, their last actions, the emails they received — without a SQL query. Often a page of the admin; always necessary.
Logs: Structured server logs, an audit log for sensitive actions (payment, deletion, role change). What you will re-read the day a customer says “that wasn’t me”.
Monitoring: Availability, errors, latency, webhook failures — with an alert that wakes you if needed. A V1 without monitoring learns about its outages from its customers.
Security: Server-side validation of every input, secrets outside the code, security headers, data scoped per account, rate limiting on sensitive endpoints, dependencies kept current.
Backups: Automatic database backups, tested at least once with a real restore. A backup that has never been restored is a hypothesis.
Rate limits: On authentication, public forms, expensive endpoints and usage-billed features. What separates a traffic spike from a surprise invoice.
Edge cases: The account with no data, the 200-character name, the time zone, the double submit, the webhook received twice. They all arrive in the first week.
Data exports: The user can retrieve their data (CSV, JSON) — a trust requirement, often a legal one, and the first tool of your own support.
Privacy: Which data is collected, where it is hosted, for how long, who accesses it — decided and documented for the Swiss FADP and GDPR, with account deletion that works.
Recovery paths: What happens when a payment fails, when an email does not go out, when a user deletes the wrong thing. A V1 does not prevent everything; it lets you repair.

02 — What waits

What a V1 deliberately does not contain

The features that seem indispensable before launch and that, almost always, wait for the second customer.

Advanced customisation — themes, custom fields, configurable workflows. You do not yet know what needs to be configurable.
The public API and outbound webhooks — until a customer asks to integrate.
Secondary integrations — the first integration is in the V1 if it is core to the product; the next ones wait for a request.
Advanced multi-tenancy (nested organisations, enterprise SSO) — unless your first customers are enterprises.
The native mobile app — a responsive web application covers the first customer.
Premature optimisation — distributed cache, microservices, message queues. A well-indexed Postgres goes a long way.
“Just in case” features — every extra screen is a screen to maintain before you have a user.

The rule: if an element keeps you from losing the first customer, it is in the V1. If it helps you win a tenth, it waits. The distinction between prototype, MVP and V1 is detailed in Prototype or v1.

03 — Order

In which order I build a V1

Week one: the data model and authentication. The Postgres schema is laid down, migrated, and the first account can sign up, sign in and see nothing but what belongs to it. Nothing else is visible, and that is deliberate — everything that follows rests on it.

Weeks two and three: the core flow — the thing the customer pays for — end to end, with its errors handled, then payments with Stripe and their webhooks, then email. The Friday demo of week three is the moment a real user could, in principle, pay.

Weeks four to six: the admin interface, analytics, logs, monitoring, backups, edge cases, exports, the privacy page, the hand-off documentation. It is the part a prototype skips, and the part that makes a V1 hold. The technical detail is in Next.js architecture for a production SaaS.

04 — Cost

What a SaaS V1 costs

Between CHF 20’000 and 45’000 fixed fee, in 4 to 6 weeks. The low end is a one-role product, one core flow, simple payments; the high end adds multiple roles, dense business logic, integrations, a dashboard. The mechanics are in How much does it cost to build a SaaS v1 in Switzerland; the calculator places your product in the range.

Scope it with the calculator

Five minutes. A complexity band, not a quote.

05 — Hire?

Hire to build the v1?

A v1 has an end: the version that holds up in front of the first customer. Hiring to build it means committing to a permanent capability before knowing whether the product will find customers — and leaving one person alone with every architecture decision. Once the product holds, hiring becomes the right decision: the roadmap no longer stops.

The hire-or-outsource guide compares both paths with the real employer cost in Switzerland.

Is this the right service?

This makes sense if

A real customer — paying, or with their data — will use the product within three months.
You have a prototype or an MVP that “works” as long as you are behind it, and that no longer holds.
You are raising or signing a pilot and need the version you can show without apologising.

It is not the right service if

You are still testing whether anyone wants the product — a prototype or a waiting page costs a fraction.
The product has to be a complete platform from day one — that is a V1 by slicing, not a V1.
You want to keep everything from the existing prototype without an architecture review — I often re-lay the data model, and I say so.

Proof — products I built and run

My own products, with their actual state. No client project is published yet.

How it works

Four steps, fixed scope, price agreed upfront.

01
Diagnose
20 minutes, free. Business model, workflows, risks and product scope. If I’m the wrong person, I say so.
02
Architect and propose
Within 48h: data model, system boundaries, integrations, UX — and one fixed fee with dated milestones. No “starting at”.
03
Build
4 to 6 weeks of controlled iterations. A demo every Friday on a Vercel preview. You watch the system grow live — no black box.
04
Launch
Payments, analytics, deployment, operational workflows. You leave with the repo, the accounts, the pipeline — and 30 days of 24h replies.
05
Improve
Measured iteration on real usage: a fresh fixed-fee scope per increment, or nothing if your team takes over. No hidden dependency.

The full process, guarantees and prices →

Frequently asked questions

What is the difference between an MVP and a production V1?
An MVP answers “does anyone want this?” and may depend on you to work. A production V1 answers “does it hold when a customer uses it every day?”: auth, solid data, real payments, email, handled errors, admin, monitoring. The boundary is the first paying customer.
What does a production-ready SaaS need?
Authentication, authorisation, a solid data model, error handling, billing, transactional email, analytics, an admin interface, support tooling, logs, monitoring, security, backups, rate limits, handled edge cases, exports, privacy and recovery paths. The full list is on this page.
How long does it take to build a SaaS V1?
Four to six weeks of sprint after a week of scoping, with a demo every Friday. Week one lays down data and auth; weeks two and three deliver the core flow and payments; the following weeks build what makes the product hold.
Can we start from the existing prototype?
Sometimes for the interface, rarely for the data. A prototype usually has a data model designed for the demo; I re-lay it in week one rather than pay for it in week ten. Scoping says so plainly.
What happens after the V1?
The product is yours, with thirty days of support. What follows is decided with the first customers: each evolution is a new scoped fixed fee, or your team takes over — the code is built for that.

SaaS V1 development.

What a production-oriented V1 must contain

What a V1 deliberately does not contain

In which order I build a V1

What a SaaS V1 costs

Hire to build the v1?

This makes sense if

It is not the right service if

Proof — products I built and run

Four steps, fixed scope, price agreed upfront.

Diagnose

Architect and propose

Build

Launch

Improve