SaaS Development: From MVP to Production (Stages, Timeline, Costs)

Taking a SaaS product from MVP to production means adding what a demo can skip: isolation between customers, secure sign-in, billing that copes with failed payments, an admin back office, monitoring, tested backups and a safe way to release changes. The path has five stages, and the time each takes depends more on integrations, user roles and compliance than on the number of screens. This guide is for founders and product owners in Switzerland with a validated idea or a working MVP. It covers the stages, the decisions that are hard to reverse, a readiness checklist mapped to OWASP ASVS, NIST SSDF and the AWS Well-Architected SaaS Lens, data protection and hosting.

What are the stages from MVP to a production SaaS?

There are five stages: validate the problem, scope and build the MVP, harden it for production, launch and stabilize, then run and grow. The ranges below assume a B2B web product built by a small senior team. Projects move to the long end because of integrations, user roles and security requirements, rarely because of the number of screens.

Stage	Goal	Typical output	Range	What sets the length
1. Problem validation	Confirm that someone will pay to solve the problem	Customer interviews, clickable prototype, pricing test, pilot commitments	2–6 weeks	Access to target customers
2. MVP scope and build	One core job done end to end for one type of user	Sign-up, core workflow, basic admin, deployed product	6–16 weeks	Integrations, billing from day one, number of roles
3. Production hardening	Make it safe to run for many customers	Isolation tests, security review, monitoring, backups, CI/CD, legal documents	4–10 weeks, partly parallel to stage 2	Security level customers require; data sensitivity
4. Launch and stabilization	First paying customers without incidents	Support process, status page, runbooks, fixes from real use	2–6 weeks	Number of early customers and their data migrations
5. Run and grow	Retention and expansion	Roadmap, metrics, regular releases	Ongoing	Product strategy

Validation is the cheapest stage to get right. If target customers can’t describe the problem in their own words, or none of them will commit to a paid pilot, more code won’t fix it.

What belongs in the MVP, and what can wait?

Put one core job in the MVP, done end to end for one type of user, plus the decisions that are expensive to retrofit: the tenant model, the permission model and the billing data model. Postpone what only some customers need, such as single sign-on, custom roles, a public API or native apps, unless your first customers can’t buy without them.

Build in the MVP	Decide now, build later	Postpone
Sign-up, sign-in, password reset, optional MFA	Tenant isolation model	SSO (SAML, OpenID Connect) and user provisioning
The core workflow, end to end	Roles and permissions model	Custom roles per customer
Data export for customers	Billing model: seats, usage or flat fee	Usage-based pricing experiments
Basic admin: tenants, users, plans	Audit log format	Public API and webhooks, unless the API is the product
Error tracking and structured logs	Data location	Multi-region setup, native apps

Which architecture decisions are hard to change later?

Four decisions are expensive to reverse: how tenants are isolated, how identity and permissions work, how billing is modeled and where data lives. Make them explicitly during the MVP, even if the first implementation is simple. If integrations are part of the value, plan the API early too, because other systems and AI agents will depend on its shape.

Tenant isolation. The AWS Well-Architected SaaS Lens describes three models. In the silo model each tenant gets dedicated resources. In the pool model tenants share infrastructure, and isolation is enforced in code and data. The bridge model mixes the two, for example a shared application with separate databases for regulated customers. Most B2B MVPs start pooled, with a tenant ID on every tenant-scoped row. PostgreSQL row-level security can enforce that filter in the database instead of relying on every query, and automated tests should prove that one tenant can never read another tenant’s data.

Identity and access. Don’t write password storage and session handling yourself. Use a proven framework or identity provider, offer multi-factor authentication from the start and design roles before the second customer asks for them. Larger customers will ask for single sign-on; an identity layer built on standard protocols turns that into configuration rather than a rewrite.

Billing. Subscriptions involve plans, trials, upgrades and downgrades with proration, failed payments, invoices with the correct VAT, and cancellations. A billing provider such as Stripe Billing handles much of this, but your product still needs an entitlement check that decides what each tenant may use, and reliable processing of the provider’s webhooks: signed, retried and free of duplicates, as described in CRM automation: where to start.

Admin back office. Support staff need to find a tenant, see its plan and usage, reset access and, with the customer’s consent, see the product as the customer sees it. Every such action belongs in an audit log. Without a back office, each support ticket becomes a database query for a developer.

Observability and APIs. Structured logs with tenant and request IDs, metrics, traces and alerts show a problem before customers report it. When we built a communication-API directory, we exposed the same data through a public REST API with an OpenAPI document and through a read-only MCP server, so developers and AI agents query the same facts the website shows.

What does a production-readiness checklist look like?

A SaaS is production-ready when someone could check it against a recognized reference and it would mostly pass. Map your checklist to three references: NIST SSDF for the development process, OWASP ASVS for application security controls and the AWS Well-Architected SaaS Lens for tenant isolation, operations and cost. The table shows what “ready” means in practice for each area.

Area	“Ready” means	Reference
Secure development process	Review of every change, dependency and secret scanning, protected main branch, a documented release process, a channel for vulnerability reports	NIST SP 800-218 (SSDF 1.1): prepare the organization, protect the software, produce well-secured software, respond to vulnerabilities
Application security	Authentication, sessions, access control, input handling and logging verified against the ASVS level you commit to	OWASP ASVS 5.0
Tenant isolation	Isolation enforced below the application code; automated cross-tenant access tests	SaaS Lens: silo, pool and bridge models
Reliability	Automated backups, restores tested on a schedule, defined recovery point and recovery time objectives, health checks	Well-Architected reliability pillar
Operations	Logs with tenant and request IDs, alerts routed to a person, runbooks, a status page	SaaS Lens operational excellence
Delivery	Tests in CI on every change, a staging environment, migrations in the pipeline, rollback	DORA delivery metrics
Data protection	Records of processing, processor agreements, privacy notice, breach procedure	FADP and GDPR (next section)
Cost	Cost per tenant visible; budgets and alerts	SaaS Lens cost optimization

We hold the systems we build to the same list. The communication-API directory mentioned above runs gates before every deploy (data schema, score verification, link audit, content checks and a confidentiality scan), and a pre-commit hook blocks any commit that contains a secret value. An outreach platform we built for a SaaS client fails closed: its dashboard won’t start on a public address without authentication. Passwords are hashed, repeated failed logins trigger a lockout and write actions are restricted by role.

What do the FADP and GDPR require from a SaaS product?

The revised Federal Act on Data Protection (FADP) applies to processing that has an effect in Switzerland (Art. 3). The GDPR applies as well if you offer the product to people in the EU. Both require data protection by design and by default, contracts with processors, records of processing and a breach procedure. As a vendor you are usually a processor for your customers’ data and a controller for your own account and billing data.

• By design and by default: FADP Art. 7, GDPR Art. 25. Collect only what the feature needs and make the privacy-friendly setting the default.
• Processors: customers will expect a data processing agreement from you (FADP Art. 9, GDPR Art. 28). You need one with each sub-processor, such as hosting, email delivery, the support desk and analytics. Under the FADP a processor may hand processing to a third party only with the controller’s prior approval.
• Records of processing: FADP Art. 12, with exceptions for companies under 250 employees whose processing poses a negligible risk; GDPR Art. 30.
• Breaches: under the FADP, the controller notifies the FDPIC as quickly as possible when a breach is likely to cause a high risk (Art. 24), and processors must inform the controller. The GDPR sets 72 hours where feasible (Art. 33).
• Export: the FADP gives individuals a right to data portability (Art. 28), so build data export early.
• AI features: if the product uses AI and is offered in the EU, check whether the EU AI Act (Regulation (EU) 2024/1689) applies to your use case.

Where should a Swiss SaaS be hosted?

Swiss law doesn’t require hosting in Switzerland. The FADP allows disclosure to countries on the Federal Council’s adequacy list, which includes all EU and EEA states, and to other countries with safeguards such as approved standard contractual clauses. Swiss hosting becomes a requirement when customers demand it, for example some in finance, health or the public sector, so ask your first customers before you choose.

Option	Suits	Consider
Hyperscaler region in Switzerland (AWS Zurich since November 2022; Google Cloud Zurich)	Products that need managed services and Swiss data residency	Check that the managed services you need exist in that region
Swiss hosting provider	Customers who want a Swiss provider as well as a Swiss location	Fewer managed services, more operations work
EU region or EU provider	Most B2B SaaS without a Swiss-hosting requirement	Disclose the location in your privacy notice and records

Data location covers more than the main database. Backups, logs, email delivery, error tracking, support tools and analytics are processors too, and each one belongs in the same list.

What changes after launch?

After launch the work shifts from building features to running a service. You need a support process with response times, a way to learn from incidents, metrics that show whether customers stay, and a roadmap that reserves capacity for security updates and technical debt. Budget for this before launch: running a SaaS is a monthly cost, not a one-off project.

Track two kinds of metrics. Product metrics show whether the business works: activation, retention, churn and monthly recurring revenue. Delivery metrics show whether the team can keep changing the product safely; DORA currently defines five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.

What drives the cost of SaaS development?

Cost follows complexity, not screen count. The main drivers are the number of user roles and permissions, integrations, billing complexity, the security level your customers require, the tenancy model, languages, data migration from existing tools and any AI features. We don’t publish price lists; after a short discovery we give a fixed-price or phased proposal for the MVP and the hardening phase.

The cheapest MVP to build is often the most expensive to fix. Skipping the tenant model or the permission design moves that cost into the hardening phase, when real customer data makes every change riskier.

What are the most common mistakes?

Troubled transitions from MVP to production tend to share a handful of mistakes: building before validating, retrofitting tenant isolation, writing authentication from scratch, treating billing as a checkout button, skipping staging and restore tests, writing personal data into logs, and splitting a small product into many services too early. Each is cheap to avoid in the MVP and expensive once paying customers depend on the system.

How Sensaria takes a SaaS from MVP to production

We design the tenant model, permissions and billing during the MVP, and map security and operations work to ASVS, SSDF and the SaaS Lens before launch. A communication-API directory we built shows the approach: a data model with a sourced fact per field, a public API and an MCP server, and gates that run before every deploy.

If you have an MVP, a prototype or a no-code version that needs to become a production platform, see SaaS development or send us a short brief.