From MVP to Series A: The Architecture Decisions That Either Save or Sink You

The Series A diligence call usually goes well for the first 45 minutes. The founder talks about traction, the market, the team. Then a technical partner at the firm pulls up the code review notes from their consultant, and the next 15 minutes get harder. The product works. The codebase doesn't.

We've seen this enough times to be confident about it: the difference between founders who Series A from a healthy technical foundation and founders who Series A despite their codebase comes down to a small number of decisions, made early, often by accident.

This is the list. Get these right at MVP, and the codebase will scale — not perfectly, but cleanly enough — through 100x growth. Get them wrong, and every quarter past PMF gets harder.

Some choices have one-time effects. You picked the wrong button colour; you change it. Other choices keep paying interest. The choice radiates through every future decision and either accelerates or drags every subsequent change.

The decisions on this list compound. They're worth getting right not because they're hard, but because the cost of getting them wrong is paid every day for years.

The most expensive technical-debt category we encounter, by far, is "we modelled this wrong at the beginning." Renaming a column on a table with five million rows is a multi-day operation with locks and partial-state risk. Changing the data model — users should have been accounts with multiple users, or messages should have been events — is a several-month migration that touches every endpoint.

The discipline at MVP isn't to model perfectly. It's to model for what you actually know about the domain, plus the next obvious thing. Two questions to ask before shipping any schema:

• What's the next domain object that might need to exist that this one is currently conflating? (e.g., are workspaces and accounts the same thing or different?)
• What's the relationship cardinality that might change? (e.g., does a user have one organisation, or might they have many?)

You don't need to build the more-general version. You need to leave a path to it — usually a foreign key column that doesn't yet have a table behind it, or a JSONB extension field that absorbs early variance.

The schema-design principle that saves the most pain over time: prefer modelling reality. If real users will eventually belong to multiple orgs, model that now even if your initial UX assumes one. The schema will outlast the UX choice.

How you partition customer data — shared schema with tenant_id, schema-per-tenant, database-per-tenant — is the most consequential infrastructure decision you'll make. Changing it later is a months-long project that touches every query.

For most early-stage SaaS, the right default is shared schema with tenant_id on every table. Every query filters by tenant. Row-level security in Postgres can enforce it at the database layer once you have the budget for the operational complexity.

Schema-per-tenant has narrow good uses (regulated industries with strict data isolation requirements). Database-per-tenant is almost always premature optimisation; you'll spend more engineering on the orchestration than you'll save in any operational benefit.

The mistake: starting with no tenant column at all because "we'll add it when we have a second customer." You will not, because by then every query and every relation is built assuming one tenant, and retrofitting is a quarter-long project.

The fastest way to break in production is to do real work inside an HTTP request. Sending an email, calling a third-party API, generating a report, processing a payment — none of these belong in the request-response cycle.

At MVP, the cheap answer is a job queue: Postgres-backed (with pg-boss, Inngest, or similar), or Redis-backed (BullMQ, Sidekiq). You don't need Kafka. You don't need Temporal at MVP. You need somewhere to put async work so your HTTP layer stays fast and your retries are sane.

The architectural pattern that survives the longest: all side effects go through a queue. The HTTP handler writes the canonical state and enqueues the work; workers do the rest. This pattern absorbs every operational lesson you'll learn over the next two years — rate limiting, retries, ordering, fairness, observability — without rewriting the application logic.

Teams that start without this pattern almost universally rewrite their app once it starts hurting. Teams that start with even a basic queue inherit a foundation that takes them most of the way to Series B.

You cannot bolt observability onto a system that wasn't designed to be observed. You can technically — but it's expensive, partial, and politically painful (everyone has to change their habits at once).

The right MVP move is to wire the three core observability surfaces from the first commit:

• Logs: structured (JSON), with request IDs, user IDs, tenant IDs. Shipping to a single place (Datadog, Better Stack, even just stdout into Cloud Logging).
• Metrics: at least HTTP latency by route, queue depth, database connection pool usage, error rate by source.
• Traces: at least one tool that ties an HTTP request through its database queries and downstream calls. OpenTelemetry is the standard; the SaaS providers (Datadog, Honeycomb, New Relic) all consume it.

This sounds like a lot. With modern tooling it's a day's work. The compounding payoff is enormous — when something breaks in production, you know within minutes; when you're optimising for cost, you know where to cut.

Almost no startup loses on the merits of their authentication system. Many startups lose months to rebuilding theirs.

Pick one identity provider that handles SSO, social login, MFA, and session management. The options are well-trodden — Clerk, Auth0, Supabase Auth, Stack Auth, WorkOS. Pick on the basis of pricing tier, ecosystem fit, and how it interacts with your auth model.

Build a thin abstraction over the provider so you can swap if pricing changes. Don't reinvent. The cost of doing so is real engineering that produces zero customer value and adds attack surface to your security posture.

The Series A team that has Clerk in front of every request and a requireAuth() helper at every API boundary is in a fundamentally different state from the team that hand-rolled JWT verification with five edge cases in five files.

The team that can deploy reliably ten times a day will out-execute the team that deploys carefully twice a week, every time. The infrastructure that supports that is built at MVP, not Series A.

The required surfaces:

• Source-of-truth in git. Production state is main plus the migrations that have run.
• A single command (or click) to deploy. Not "SSH into the server and run these five things." Not "if Brian is available."
• Migrations that run automatically and reversibly, with a documented rollback procedure.
• A staging environment that reflects production, with realistic data shape (not necessarily volume).
• Feature flags for risky changes, so deploys don't have to map to releases.

This is a couple of weeks of work at MVP and an unending tax if you defer.

For 95% of MVPs, the answer is monolith. One repo, one deployable, one database. The complexity tax of microservices is enormous and the benefits don't materialise until you have enough team and enough product surface that coordination cost exceeds operational cost.

The exception: where you have a genuinely separate workload — heavy ML inference, scheduled batch processing, a real-time service with different scaling characteristics — that wants different deployment, different scaling, or different language. Then carve that off as a separate service. Not because microservices, because that particular workload doesn't belong inside the HTTP request path.

The pattern we see most often: teams that split into microservices "to be ready to scale" end up scaling the coordination overhead instead of the system, and the Series A diligence rounds note the unnecessary complexity. Teams that stayed monolithic until they actually had a scaling reason ended up with cleaner systems.

Cloud costs are the second-biggest line item in many SaaS companies' P&L. The teams that have per-customer cost visibility (or per-feature, or per-tenant) can make rational pricing and optimisation decisions. The teams that have one big AWS bill cannot.

Wire cost attribution in at MVP — tags on every resource, separate cost centres for the workloads that matter (inference, storage, egress). Use the AWS / GCP cost-explorer tools and add a thin per-tenant view in your own admin. By Series A you'll know which customers are profitable, which features are subsidised, and where the next 20% of margin is.

This was nice-to-have in 2022. In 2026, with inference costs being meaningful, it's table stakes.

A short list of things a competent technical diligence person will check for. If you can pass these, the architecture conversation is over:

1. Can you deploy in under 10 minutes, end-to-end, no human in the middle?
2. Can you roll back a deploy in under 5 minutes?
3. Are migrations automated and reversible?
4. Is there a staging environment that reflects production?
5. Are logs, metrics, and traces accessible without an engineer's help?
6. Is auth handled by a known provider, not hand-rolled?
7. Is there a queue between HTTP and side effects?
8. Is multi-tenancy structurally enforced (not just by convention)?
9. Is there per-customer cost visibility?
10. Are there tests covering the critical paths and CI running them on every PR?

Each of these is a day's work at MVP. Each of them is a multi-week project to retrofit at Series A.

How much architecture should an MVP have?

Enough that the choices above are made deliberately, not enough to slow you down. A useful test: if a senior engineer joining the team today couldn't read the codebase and understand the rough shape in two hours, you have too much. If they couldn't deploy a small change in two days, you have too little.

We have technical debt — how do we know if it's a problem?

The honest signals: how long does it take to ship a typical new feature? Trending up over time = problem. How often do incidents happen on routine deploys? Increasing = problem. How long does the test suite take to run? Increasing past 10 minutes without a budget to fix = problem.

Should we do TDD?

No. Write tests for what matters — the critical paths, the failure modes, the regression-prone surfaces. Aim for ~70% line coverage that you can explain rather than 95% you can't.

Is "we'll fix it after fundraising" ever the right answer?

Almost never. The post-fundraise period is the worst time to do major architecture work because the team is hiring and the runway pressure makes the room for refactoring smaller, not larger.

Architecture at MVP is not about getting everything right. It's about getting the compounding things right, so the codebase ages well instead of badly. Get the eight items above into the foundation, and the rest is recoverable.

If you're between MVP and Series A and want a sanity check on your architecture before the next round of due diligence, we offer a one-week architecture review aimed exactly at this stage. The output is a list of "you'll get asked about this" items, ranked by what you should fix before the diligence call and what you can defend on the call.