SaaS product development, from a focused MVP to multi-tenant scale

A SaaS MVP should include the one workflow customers will pay for, plus the minimum commercial plumbing needed to charge and support them. That usually means sign-up and authentication, a tenant model, the core feature done well, basic billing through Stripe, transactional emails, product analytics and a simple admin view. Nice-to-have features, extra integrations and complex permissions wait until real usage shows they matter, which keeps the release small without weak foundations.

Most SaaS products should start multi-tenant, with one codebase and one deployment serving every customer, because it keeps operations and hosting costs manageable. The real decision is how to isolate data: a shared database with tenant identifiers and row-level security, a schema per tenant, or a separate database for each customer. Dedicated single-tenant deployments suit mainly large customers with strict residency or contractual isolation needs, and a well-designed platform can offer them later as a premium option.

We enforce tenant isolation in several layers, so one missed filter in application code is not enough on its own to expose another customer's records. Every request resolves the tenant from the authenticated session, database queries are constrained by PostgreSQL row-level security or separate schemas, and file storage, caches and search indexes are partitioned by tenant too. Automated tests attempt cross-tenant access on every build, and support tools that open customer accounts require permission and leave an audit record.

We build billing on Stripe, with your application reacting to billing events rather than calculating charges itself. Plans, trials, coupons, seat changes, proration, tax and invoices are configured in Stripe, while webhooks update each tenant's subscription status and entitlements in your database. Failed payments trigger retries, reminder emails and a grace period before features are restricted, so recovery runs without anyone chasing it. Finance gets clean records for reporting and reconciliation.

Yes, and the architecture should support both even if you launch with one. Per-seat pricing ties billing to the active members of a workspace, updated as people are invited or removed. Usage-based pricing needs dependable metering: events such as API calls, documents processed or AI requests are counted per tenant, aggregated and reported to Stripe each billing period. Keeping pricing rules in an entitlements layer lets you test new plans without rewriting product code.

A SaaS MVP can launch only when its core workflow, sign-up, billing and support tooling are all ready, so the slowest of those sets the date, not the headline feature alone. Payment edge cases, transactional emails and tenant setup often take as much effort as the core feature, so we build them alongside it rather than after. Outside approvals, such as Stripe account verification or a partner granting API access, can also set the pace, so we start them during discovery. Working software every one to two weeks keeps progress visible.

The cost of a SaaS product depends mainly on the scope of the first release, the integrations it needs, your data and security requirements and how much design work already exists. It is usually more than the feature list suggests, because tenancy, billing, onboarding, admin tools and operations sit underneath the core workflow. We give a fixed quote for the MVP after discovery, and we also model what each customer will cost you to serve, from hosting to payment fees and email, so you can set prices with a margin in mind.

We design onboarding backwards from the activation moment, the first point where a new account gets real value from your product. Every step before it is questioned: which fields can wait, which settings can default sensibly, whether sample data or an import wizard helps, and when to invite teammates. Each step is instrumented so you can see where accounts stall, and in-product guidance is combined with lifecycle emails triggered by what users have or have not done.

At launch you need an internal console that lets support and operations staff help customers without asking engineers to run database queries. That typically covers tenant and user search, plan and trial changes, credits and refunds linked to Stripe, feature flags per account, consented support access to a customer's view, and a log of every admin action. Health scores, usage dashboards and bulk operations can follow as the customer base grows.

Add enterprise features when their absence starts blocking deals with larger customers, but lay the foundations from the beginning. If your data model already has proper roles, an event log and tenant-aware configuration, adding single sign-on, SCIM provisioning, audit log export and custom retention later is incremental work. Without those foundations, the same request can become a rewrite. Many SaaS companies package these controls in a higher plan, which also gives larger customers a clear upgrade path.

Yes, and with an existing SaaS product the first questions are about tenancy and money. We check whether tenant isolation is enforced in the database or only in application code, whether Stripe webhooks are processed idempotently so a repeated event does not charge or upgrade a customer twice, and what each tenant actually costs to host. Findings are ranked by risk for your next stage of growth. Fixes usually start with tests around billing and isolation, while feature work continues alongside.

We scale infrastructure in response to measured load, not ahead of it. Early on, a managed database and containerised services on AWS or Google Cloud are usually enough. As usage grows we add read replicas, caching, background job queues, autoscaling on Kubernetes where it is justified, and per-tenant monitoring so a single heavy customer can be spotted and contained before it slows everyone else. Infrastructure is defined in Terraform and deployed through pipelines, so every change is reviewed and repeatable.