Early-stage infrastructure decisions are made under uncertainty and with little time. The useful distinction is between the decisions that are cheap to change later and the two or three that are not.
The decisions that are genuinely hard to reverse
- Where the data lives. Region choice is constrained by law and by latency, and moving it later means moving the data — see cloud regions and IP location explained.
- Account ownership. An account in a founder’s personal name, on a personal card, becomes a real problem at the first diligence process. Set it up as the company from the start.
- Deep use of proprietary managed services. Not wrong, but each one raises the cost of ever moving. Choose them because they save real work now, not out of habit.
Almost everything else — instance sizes, the number of servers, the deployment tool — can be changed in an afternoon.
Set the account structure up once
- Separate production from everything else, by account or project rather than by naming convention. This makes a development mistake unable to touch production data or the production budget.
- Named identities for every person, multi-factor authentication on all of them, and the top-level login locked away.
- Billing to a company payment method with a company email as the recovery contact.
- A budget alert on day one.
That takes an hour and removes an entire category of later pain.
Choosing the provider
Two reasonable strategies, and the wrong one is picking neither deliberately:
- Start simple. A predictable flat-rate provider, one or two servers, a managed database. Lowest cost, lowest cognitive load, entirely sufficient for the first year of most products.
- Start where you will end up. A hyperscaler, if you already know you need a specific managed service — a model catalogue, a data warehouse, a compliance region — badly enough to pay for it now.
Credit programmes are worth taking and are a poor reason to choose a platform on their own: they end, and the workload stays. Compare on what the bill looks like in month thirteen. The comparison pages set out the structural differences.
What not to build yet
- Kubernetes, unless you already have many services and more than one team.
- Multi-region anything. It multiplies cost and complexity to solve a failure you have not had.
- A microservice architecture, before there is a team boundary that requires one.
- A custom observability stack, when four signals and three alerts will do.
- Reserved capacity commitments, before the workload has been stable for months.
Each of these is defensible later and expensive now, and the cost is mostly the attention it takes from the product.
What to revisit at month twelve
- Right-size everything against a year of real measurements.
- Consider commitments for the baseline that has proven stable — see on-demand, reserved and spot.
- Review who still has access.
- Test a restore. If nobody has, that is the most urgent item on this list.
- Read the bill by service and ask which line grew fastest and why.
Where to go next
Questions
Frequently asked
Which cloud provider should a startup choose?
Either a predictable flat-rate provider for simplicity, or a hyperscaler if you already need a specific managed service. Choose deliberately and compare on month thirteen rather than on introductory credits.
Should a startup use Kubernetes?
Rarely in the first year. It solves coordination problems that appear with many services and multiple teams, and adds a system to operate before that.
What infrastructure decision is hardest to reverse?
Where the data lives. Region choice is bound by latency and by law, and changing it later means moving the data with all the cost and downtime that implies.