SaaS development: from MVP to a production platform

What does SaaS development involve beyond the features?

A SaaS product has two parts: the features customers pay for, and the platform that lets many customers use them safely at the same time. The platform covers tenant isolation, sign-up and team management, subscriptions and billing, a public API, admin tooling, monitoring and a release process. In the first year it is often as much work as the features, and it is the part that is most expensive to retrofit. We design both from the start and build only as much platform as the current stage needs.

From MVP to production: the stages

Stage	Goal	What exists at the end
Discovery	Find the riskiest assumption and the smallest product that tests it	Scope, architecture note, tenancy and pricing model
MVP	Real users on real data	Sign-up, core workflow, billing, error tracking, backups
Production	Paying customers who depend on it	Roles, audit log, public API, admin console, monitoring, security review
Scale	Growth without firefighting	Queues, caching, per-tenant limits, performance budgets, on-call runbooks

An MVP is small in scope, not in quality. Authentication, tenant isolation and logging are in it from the first release, because adding them later means touching every query and every screen.

Architecture decisions we make early

Tenancy model. Shared database with a tenant column, a schema per tenant, or a database per tenant. We usually start with a shared PostgreSQL database and enforce isolation with row-level security, so a forgotten filter in application code cannot expose another tenant’s rows. The design leaves room to move a large customer to a dedicated database later if a contract requires it.

Identity and access. Sessions for the web app, scoped API keys for integrations, and short-lived signed tokens (RS256) when the product is embedded in another platform. Permissions are checked in the backend on every request.

Billing. The billing provider is the source of truth for payments; your product is the source of truth for what each plan allows. Signature-verified webhooks keep the two in sync, and access is never granted from a browser redirect alone.

API first. A versioned REST API with an OpenAPI document, cursor-based pagination and idempotency keys on write requests. For products that AI agents should be able to use, a read-only MCP server sits next to the API.

AI features with limits. Where the product calls LLMs, we add per-tenant cost ceilings, validation of model output, a fallback provider, and a record of model, prompt version, tokens and cost for every call.

What goes wrong between MVP and production

• Data visible across tenants. Prevented by database-level isolation and automated tests that attempt cross-tenant reads.
• Billing drift. A missed webhook leaves a canceled customer with access, or a paying customer without it. Idempotent handlers and a daily reconciliation job close the gap.
• Noisy neighbors. One customer’s bulk import slows everyone down. Background queues and per-tenant rate limits contain it.
• Blind support. Without an admin console and request IDs in the logs, every support ticket turns into guesswork.
• Webhooks that fail silently. We sign every outbound delivery, retry with back-off, and disable endpoints that keep failing while telling the customer why.

Security and compliance

We use the OWASP Application Security Verification Standard (ASVS) as the production-readiness checklist and follow the practices of the NIST Secure Software Development Framework (SP 800-218): code review, static analysis and secret scanning in CI, and a documented release process. The revised Swiss FADP applies to personal data processed in Switzerland or with an effect there. The GDPR applies if you offer the product to people in the EU, and the EU AI Act can reach AI features whose output is used there. We design data flows, processor lists and hosting (Switzerland or an EU region) so that your answers to customers’ security questionnaires are accurate.

What drives cost and timeline

Driver	Effect on effort
Tenancy and isolation	Dedicated databases or regional hosting per customer add build and operating work.
Billing model	Seats, usage metering, trials and taxes each add rules and edge cases.
Integrations	Every third-party system brings its own authentication, limits and failure modes.
AI features	Prompt design, evaluation and cost controls come on top of the feature itself.
Enterprise requirements	Single sign-on, audit exports and security reviews arrive with larger customers.
Existing MVP	Replacing a no-code or prototype codebase needs data migration and parallel running.

We price the MVP as a fixed-scope project after discovery, then plan later stages against what it teaches you. The stages and a readiness checklist are covered in more depth in from MVP to production.

How it connects to the rest of the business

A SaaS product needs a commercial system around it. Trials and sign-ups flow into CRM and sales automation. Onboarding, billing and usage emails run through email automation. Product data is exchanged with your customers’ tools through API integrations.

Why Sensaria

We build and run platforms of this kind. PingMyUsers, which Sensaria operates, publishes a public REST API with eight endpoint groups and an OpenAPI document, plus a read-only MCP server with 10 tools; free-text requests go through a deterministic parser rather than an LLM, so the same question always gets the same answer. For a client we built a multi-tenant product with PostgreSQL row-level security, signed outbound webhooks with retries and auto-disable, and an embeddable widget authenticated with short-lived tokens. Sensaria AG is based in Lugano, Switzerland, and works in English, Italian, German and French.