Cloud Stack Decisions for Early-Stage Startups: What Actually Matters

The “best stack” question is the wrong question

Every few months someone asks me what cloud stack a new startup should pick. They want a list. Should we be on Vercel or Fly? Supabase or RDS? Auth0 or Clerk? Next or Remix? Bun or Node?

It’s a reasonable question. It’s also, almost always, the wrong one.

Pick any two reputable tools in a category and the difference between them at month three of a startup is essentially nothing. They’ll both ship. They’ll both scale to your first thousand users. The trade-offs only start to matter at the point where you’re past product-market fit and have a real team, and by then you’ll re-platform anyway, because the constraints have changed. I’ve written about that re-platforming pattern from the inside; the Saiku rebuild is a textbook case of an old stack being eaten and replaced once the priorities flipped.

The questions that actually predict whether your stack will hurt you are different from the ones people argue about online. They’re not about which tool is best. They’re about how the tool behaves when you, specifically, are tired, under-resourced, and being asked to ship a thing you don’t fully understand.

Here’s the shortlist I actually run through.

1. What does this cost to leave?

The question isn’t what it costs to adopt; vendors make adoption cheap on purpose. The question is what it costs to migrate off when you outgrow it, or when the vendor’s pricing changes, or when they get acquired by somebody whose roadmap doesn’t include you.

A Postgres database on any provider has a near-zero exit cost: you pg_dump it and move on. A bespoke backend-as-a-service with proprietary query languages, custom auth flows, and a particular flavour of edge functions has an exit cost measured in months of engineering work. Both might be the right call at week one. They are emphatically not the same level of bet.

A useful framing: for each piece of the stack, ask “if this vendor doubled their price tomorrow, how long would it take me to be off them?” If the answer is more than a quarter of engineering time, that’s not a tool you’ve adopted, it’s a marriage. Make sure you actually want the marriage.

The corollary: standards-based pieces (Postgres, S3-compatible storage, OpenTelemetry, Docker) are almost always worth picking even when a proprietary option is slightly nicer. The “slightly nicer” is paying you a small dividend every day; the exit cost is the principal. Most startups confuse the dividend with the principal and end up surprised.

2. Who pages, and what do they have to know to fix it?

A stack that needs five different skill sets to operate is a stack you cannot run with two engineers. This sounds obvious. It’s the single most-violated rule I see.

The temptation is to pick the “right” tool for each layer, best-in-class queue, best-in-class observability, best-in-class container orchestration, best-in-class CDN. By the time you’re done you have eight vendors, four control planes, three different IaC tools, and a single oncall engineer who has to know all of them at 3am when the thing breaks. That engineer is going to quit. And the thing will break, because you’ve built a system whose surface area exceeds your team’s bandwidth.

The pragmatic answer is to pick a stack with a small operational surface area, the number of distinct things a human has to keep in their head to operate the system. One database flavour beats two. One IaC tool beats two. One observability vendor beats Prometheus + Datadog + custom logging in S3. The “best” tool in each category, combined, is almost always worse than a competent default everywhere.

I’ve made the same argument about Kubernetes specifically: the question isn’t whether it’s powerful, it’s whether your team is large enough to absorb the operational tax. The same logic applies to your entire stack.

3. Will your second engineer be able to read this in a week?

Codebases are written by founders and read by the next ten hires. The technologies that survive in early-stage startups are not the ones that are best, they are the ones that are most legible to a competent generalist who has never seen the codebase before.

Boring Postgres beats clever schemaless storage, because the second engineer has used Postgres before. A Rails or Django or Next.js monolith beats a microservices puzzle, because the new engineer can hold the whole thing in their head. SQL beats a custom DSL. JSON-over-HTTP beats a proprietary RPC. None of this means the boring option is technically better, it just means it has the lowest onboarding cost, and onboarding cost is the dominant cost at a stage when you’re tripling headcount every six months.

When you adopt something exotic, a niche language, a young framework, a clever new database, you should be doing it deliberately, with a clear answer to “what does this give us that’s worth the cost of every future hire having to learn it?” If the answer is “it’s nicer,” you’re paying a tax for taste. Sometimes that’s fine. Just notice you’re doing it.

4. Where does state live, and how do you back it up?

The single technical question that matters most in the first year is, where is your durable state, and how do you get it back when something destroys it?

It is staggering how often this question goes unanswered until the first incident. The application servers can come and go; that’s a deployment problem. The database is the company. If you cannot, today, restore your production database to a point in time before whatever stupid thing just happened, you do not have a business, you have a hopeful prototype.

That doesn’t mean you need a fancy backup strategy. It means you need some backup strategy, tested, with a written runbook, before you have any users. Managed Postgres on a major cloud gives you point-in-time recovery by checking a box. Use it. Test the restore once, in anger, before you need it.

The corollary: be very conservative about where you put state. Stateless services can be replaced in an afternoon. Stateful ones cannot. Concentrate your scary, hard-to-change choices in the state layer, and then leave that layer alone.

5. Can you turn the bill off?

Cloud bills compound the way mortgages do, except worse, because nobody’s amortising the principal. The thing to fear isn’t the bill the day you ship. It’s the bill twelve months later, when forgotten environments, idle instances, and abandoned experiments are quietly grossing up the monthly invoice and nobody has the appetite to audit them.

Two practical defences, both cheap:

• Tag everything from day one. Every resource gets an owner tag, an environment tag, and a project tag. Untagged resources are tomorrow’s billing surprise.
• Have a killswitch. A documented, tested process for turning off all non-production workloads on a weekend. You may never need it. The fact that it exists changes the way you think about provisioning.

This is the same operating-model gap I described in the context of migrations going badly, bills don’t get out of control because the cloud is expensive, they get out of control because nobody owns them. Build the ownership in early, when there are only ten resources to tag, not ten thousand.

So what would I pick?

This is the part of the post where you expect a list of tools. I’m going to skip it, because if I name names I’ll be wrong by the end of the year, and the named tools will absorb all the attention and miss the point.

What I will say is this: the startups I’ve seen ship cleanly almost all use a small number of boring things, run by people who know them well, on a single major cloud, with state in a managed database, observability through a single vendor, and a deploy pipeline a new hire can read on day one. They look unfashionable. They also work, and they don’t generate the kind of stack-related crises that consume an early team’s bandwidth at exactly the moment that bandwidth needs to go into product.

When somebody asks me what stack to pick, what they’re usually actually asking is “how do I avoid making an irreversible mistake?” The shortest honest answer is: keep the irreversible choices to a small number, make them deliberately, and put the rest in a place you can change cheaply when you learn more.

If you’re navigating these decisions and want a second opinion grounded in dozens of these conversations rather than a vendor’s marketing site, our for-startups practice is built for exactly this stage.