Architecture debates kill MVPs. Version one needs a boring stack, clear boundaries and a path to grow without rewriting everything.
Most first SaaS products should be a single deployable app with Postgres, server-side auth and a thin API layer. Split services only when a team boundary or scaling pain forces it.
The default stack we recommend for MVPs
- One web app (React or similar) plus one API (Node, Python or similar).
- Postgres as the system of record.
- Managed auth or a well-tested session layer.
- Object storage for uploads, not the database.
- Background jobs only for email, webhooks and long tasks.
Draw boundaries on paper first
List entities: users, organisations, the core object your product manages, billing account. Draw which service owns writes. If two modules both mutate the same row, merge them until v2.
Version one is allowed to be ugly inside if the user journey is clean. Version two pays down debt when you know which features survive.
What not to build in v1
- Separate microservices per feature.
- Custom admin framework before you have admins.
- Plugin marketplace before you have ten paying customers.
- Real-time everything unless the product promise requires it.
Handover-friendly architecture
Document env vars, migrations, seed data and how to run locally in one README. Clients who own the code should not need you to deploy a patch in year two.
Use this as a working checklist inside your team first. When the same steps repeat every week and spreadsheets start breaking, that is usually the moment to scope the smallest reliable integration that removes repeated copy-paste from a core workflow as an owned system. See the relevant Standen service · More guides · SaaS ops audit.