The Startup Cloud Decision Nobody Ever Revisits

Here is a decision almost every software company makes badly, and it is not for lack of intelligence.

Around week six, somebody says "I've used AWS before, let's just do that." Two people react with a thumbs up. An account gets created. The Slack thread scrolls away and nobody writes down why.

That decision then governs technical choices for the next several years — often long after the person who made it has left and the product has become something they would not recognise.

Why the usual comparison is useless

Search for guidance and you will find a hundred articles comparing service catalogues. Both platforms have compute. Both have managed databases. Both have object storage, queues, load balancers, and a machine learning product with a forgettable name.

Feature parity arrived years ago. The industry kept writing the comparison anyway.

What has not converged is more interesting: the shape of the bill, the shape of the failure modes, and the shape of the AI workload that has attached itself to nearly every product roadmap since 2024.

Four numbers that actually discriminate

Before opening any pricing page, characterise the workload. It takes an afternoon.

• Traffic shape — steady all day, spiky at launches, or genuinely quiet for long stretches? Only the third case makes scale-to-zero economics worth architecting for.
• Data volume and egress — how many terabytes at twelve months, and how much leaves the network monthly? Egress is chronically under-measured and it is what makes the decision irreversible.
• Statefulness — what share of your system holds durable state you cannot casually restart? The stateless part moves for the cost of a container build; the rest is where migrations spend their time.
• Inference intensity — model calls per user action, and whether they hit a hosted API or something you run yourself.

Two companies with identical funding and headcount can answer these four questions completely differently. They should not end up on the same platform.

Credits are a loan, not a gift

Both providers offer startup credits, sometimes six figures. Founders weight this heavily because it is the most concrete-looking difference available.

It is a customer acquisition instrument with an expiry date. Its function is to get your data, pipelines, access policies and engineering habits onto a platform before the free period ends, at which point leaving costs more than staying. Perfectly rational business model — and it tells you nothing about fit.

The pattern that follows is consistent enough to predict. Eighteen months of unoptimised spend, because free spend produces no optimisation signal. An architecture that quietly assumes free spend. Then credits expire, and full pricing meets a year and a half of accumulated waste in one billing cycle.

Price your projected two-year workload at list rates on both platforms first. Apply realistic volume discounts. Only then let credits break a genuine tie.

The AI question is smaller than advertised

If your product calls a hosted model over an API — which describes most AI features shipping today — your inference cost is essentially independent of your cloud provider. You are paying a per-token rate to a third party, and the provider affects only the egress and latency around that call.

In that very common case, AI should not influence the decision at all.

If you self-host open-weights models at meaningful scale, it inverts entirely and the binding constraint becomes whether you can get accelerator capacity in your region during a demand spike — not headline pricing. That is a real reason to evaluate carefully, and it applies to far fewer teams than believe it does.

The only part you cannot undo

Compute is portable. Application code is mostly portable. Data is not, because providers charge to move it out and because you have to move it while customers are using the product.

The comfortable window for changing your mind is roughly eighteen months, narrowing every quarter as the dataset grows.

That gives you a clean rule: weight the decision heavily toward wherever your largest dataset will live in two years, and treat everything else as adjustable.

The subtler version is architectural. A proprietary queue is fine. A proprietary workflow engine is fine. An identity service is fine. All three, load-bearing, alongside forty terabytes, is a decision you made without ever making it.

The twenty minutes that matter most

Pick one. Then write down what you chose, the three assumptions behind it, and the conditions under which you would revisit — and set a calendar reminder for twelve months.

Almost all cloud regret comes not from choosing wrong but from never re-examining a choice made under different circumstances by people who have since left. That short note is the only thing that survives them.

Full version with the database comparison, container platform details and migration cost breakdown: AWS vs Google Cloud for Startups. If you want an outside read on a decision you are weighing, we take those calls.

Frequently Asked Questions

Is one provider genuinely cheaper?

Neither systematically. Google Cloud tends to favour analytics and sustained-use compute; AWS tends to win when usage is predictable enough to commit to reserved capacity. Architecture drives the bill far more than the provider does — an inefficient system on the cheaper platform outspends an efficient one on the pricier platform easily.

Should credits decide anything?

Only a genuine tie, after you have priced the projected two-year workload at list rates on both platforms. Credits are designed so that leaving costs more than staying by the time they expire.

Does AI change which cloud I should pick?

Only if you self-host models at scale. If you call hosted APIs, inference cost is decoupled from the provider and AI belongs nowhere in the comparison.

How long can I change my mind?

Roughly eighteen months, narrowing continuously. Compute and code move relatively cheaply; data, access configuration, observability and compliance evidence do not. A mid-sized migration is a three-to-six month project.

Is multi-cloud worth it early on?

Rarely. The negotiating leverage needs spend large enough for providers to care, and genuine resilience requires provider-independent architecture that forfeits managed services and doubles operational work.

What is the most common mistake?

Never revisiting the decision. Record the assumptions and the conditions that would change them, then schedule a review while switching is still affordable.