Hosting a SaaS MVP: Infrastructure That Scales Later

The only constraint that matters at MVP stage

An MVP has one scarce resource, and it is not money or compute. It is the number of hours your team can spend before the market tells you whether the idea works. Every infrastructure decision should be judged against that clock.

This leads to a counterintuitive rule. The right architecture for an MVP is the one that is fastest to operate, not the one that is cheapest to run or the one that would scale best if you succeeded beyond expectation. Paying a provider to manage a database is usually cheaper than an engineer spending a Saturday on replication.

What follows is a stack that a small team can stand up quickly, plus a note on where the seams should be so that a later rebuild is a project rather than a rewrite.

A stack you can run with two engineers

Almost every business SaaS needs the same seven pieces. Name them explicitly, decide managed or self-hosted for each, and resist adding an eighth until something breaks.

Note the email row. Running your own mail server on a cloud instance fights both the provider and the receiving networks, for reasons set out in port 25 and outbound email.

Choosing where it runs

Three families of destination suit an MVP, and the difference is how much of the runtime you are willing to own.

A deploy-from-git platform removes servers from your life entirely. You push, it builds, it runs. The cost per unit of compute is higher and the customisation ceiling is lower, but for a team of two chasing product-market fit that trade is often correct. Heroku popularised the model, and the Heroku account listings describe what that environment includes.

A developer cloud with managed add-ons sits in the middle. You run your own instances but the database, load balancer and object storage are somebody else's problem. This is the most common resting place for a funded MVP, and a DigitalOcean account covers the whole set within one console.

A hyperscaler gives you every service you could eventually need and a bill you will need to learn to read. Choose it when a specific service is central to the product, or when enterprise buyers are part of the plan from the start. The middle two options are compared directly in Heroku versus DigitalOcean.

The tenancy decision you cannot defer

Most early architecture choices can be revisited. How you separate customer data is not one of them, because changing it later means migrating every customer at once.

The common models are a shared schema with a tenant identifier on every row, a schema per tenant inside one database, and a database per tenant. Shared schema is simplest and scales furthest operationally; it demands discipline, because one missing filter in a query is a data leak.

Schema per tenant makes export and deletion trivial and suits businesses selling to buyers with data separation requirements. It becomes awkward once migrations have to run across a large number of schemas.

Database per tenant is the heaviest and only justifies itself when contracts demand it. Pick deliberately, write the decision down, and enforce the tenant filter in one shared layer of code rather than in every query.

What to deliberately not build

An MVP infrastructure plan is mostly a list of things you are not doing yet. Saying so explicitly prevents the slow drift into a platform nobody asked for.

• Autoscaling. Two fixed instances handle early traffic, and scaling rules tuned against imaginary load are worse than none.
• Kubernetes. It solves problems that appear with many services and many engineers, not with one application and two people.
• Multi-region. A single well-chosen region plus off-site backups is the right posture until customers say otherwise.
• A service-oriented split. Keep the monolith; extracting services later is easier than reassembling them.
• A bespoke CI platform. A hosted runner with a short pipeline is enough, as covered in CI/CD pipelines that deploy to cloud servers.

The one thing not to defer is a staging environment. Testing against production is how early customers discover your bugs first, and building a mirror is cheap while the system is small, as described in building staging environments that mirror production.

Leaving seams for the version that scales

You can keep a simple system without painting yourself into a corner. The trick is to isolate the three things that are expensive to change later.

Isolate storage access behind a thin internal interface, so swapping one S3-compatible endpoint for another is a configuration change. Isolate the job queue behind a small abstraction, so moving from a database-backed queue to a broker does not touch business logic. And keep the database schema clean, because schema debt is the most expensive kind.

Instrument before you optimise. A request-duration histogram and slow query logging will tell you which component actually needs attention, and that evidence is worth more than any architectural instinct. The trade-off between running your own database and buying one is explored in managed databases versus self-hosted.

Finally, keep everything reproducible. If the whole environment can be rebuilt from a repository and a backup, you can move platforms when the economics change, which for a growing SaaS they eventually will.

Key takeaways

• Optimise the MVP stack for operating speed, not for unit cost or hypothetical scale.
• Seven components cover almost every business SaaS; buy the database managed and send mail through a dedicated service.
• Pick the platform by how much runtime you want to own, from deploy-from-git through developer cloud to hyperscaler.
• Decide the tenancy model deliberately and enforce tenant isolation in one shared layer, with a test that proves it.
• Defer autoscaling, Kubernetes, multi-region and service splits, but never defer staging.
• Leave seams around storage, the job queue and the schema, and instrument before optimising anything.

For platform specifics, see the DigitalOcean App Platform documentation and the Heroku architecture reference, both of which describe the runtime constraints in the vendors' own terms.