What infrastructure actually costs at 1, 5 and 20 people

Understanding the costs associated with building a product is crucial. Every team that self-hosts has had the argument about whether the bill is too high. The more expensive question, however, is whether it can be predicted, because that ultimately influences your business decisions and the price of your product.

I want to make a claim and then spend the rest of this walking through it.

Three things happen to what you spend on infrastructure as a company grows. It gets bigger, it gets harder to predict, and it gets harder to say which part of the business it belongs to. Almost everything written about infrastructure cost is about the first one, and the first one is the least damaging of the three.

One person, pre-revenue

The numbers at this stage are genuinely small. DigitalOcean's cheapest droplet is four dollars a month and six gets you a gigabyte of memory. Postgres sits on Supabase's free tier. GitHub Actions is free for public repositories and has a monthly allowance for private ones. AWS gives you a million Lambda requests and 400,000 GB-seconds every month, free, permanently. A domain is twelve dollars a year.

Under twenty dollars a month covers a real product with real users, and by any measure that is not a lot of money.

At this stage the instinct is to treat money as the scarce resource, but it isn't. The time it takes to find out whether the product works is. Money is the one you can see, so it gets optimized for, and the other one doesn't.

Where the spend actually adds up

The spend that actually adds up here is not the box, it's the accumulation. Monitoring, because finding out from a user gets old. Transactional email, because password resets have to work. Error tracking. CI minutes once the allowance runs out. A second box for staging. None of those are unreasonable individually and none of them were the decision you thought you were making.

Management and opportunity cost

The management cost at this stage is entirely one person and none of it gets counted anywhere, because it is made up of evenings spent on nginx configs and the Sunday the box fell over. The opportunity cost is the only one that really matters, because every weekend spent on setup is a weekend not spent finding out whether anyone wants the product.

The instinct pre-revenue is always to optimize for cheaper solutions, because you want to figure out whether the product is viable first. It is because most ideas don't work, but what matters is how quickly you figure that out and how little you have to reverse when you do. At this stage you want as few commitments as possible.

Three to ten people, and the bill stops being predictable

Eventually something works. There is revenue coming in, there are a handful of you rather than one, and the bill is now real without being large enough for anyone to worry about it.

What changes here is that the number stops being the issue and the variance starts being the issue instead.

The causes are usually mundane. A cron job retries in a loop over a weekend, or a query that was fine for a year gets slow once a table grows past a few million rows, or a scraper nobody knew about starts working through your endpoints. The one that catches people most often is egress, because AWS charges for data transfer out beyond the first 100GB a month and nothing in your architecture tells you how much you are moving until the invoice does.

The money itself is rarely the damage, because a bill that triples on a small base is an annoyance rather than a problem. The damage is that most teams find out from the invoice, which means the thing ran for two or three weeks before anyone noticed, and by the time you are looking at it you are no longer preventing a cost, you are explaining one. Somebody capable then spends a day in a billing console reconstructing what happened, ships nothing, and what you have at the end of that day is an explanation rather than a fix.

The real cost: a bill you can't forecast is a product you can't price

Now the part I think is the real cost at this stage, and it isn't the money.

You are setting a price. To price with any confidence you need to know what serving one customer costs you, and you cannot know that if the bill moves for reasons nobody can name. An infrastructure bill you can't forecast is a product you can't price. Every conversation about gross margin, about whether the cheap tier loses money, about what you can afford to give away in a trial, runs through a number you don't have.

What usually happens instead is that the price gets set by looking at what competitors charge, which works until your cost structure turns out to be different from theirs. By then the number is on a public pricing page with customers sitting on it, and changing it is a much larger piece of work than getting it right would have been. The same gap shows up the first time somebody asks what your gross margin actually is, because teams that can't answer that quickly tend to find out they have been discounting into negative margin on exactly the customers they were most pleased to win.

Management and opportunity cost

The management cost at this stage is that the bill belongs to nobody. Engineers optimize for shipping, which is correct, and the founder looks at the total once a month. Between those two points there is no owner, and an unowned cost only gets attention after it has already moved. The opportunity cost is the days spent finding out why the number changed.

Ten to twenty-five people, and the bill stops being attributable

By this point the bill is large enough that somebody asks about it in a meeting where you are expected to have an answer, and that threshold matters more than any particular figure. The amount is survivable. Not being able to break it down isn't.

The questions that get asked are which team that cluster belongs to, which customer that spend serves, and whether margin moved because of pricing or because of infrastructure. Those sound like finance questions, but they are the same question as what is actually running, which this kind of stack has never been able to answer, because the answer is spread across seven tools and one person's memory. That shape is the subject of the deploy work nobody budgets for, and the cost consequence is the part that article left out.

The cost allocation tag trap

There is a specific trap worth knowing about here. Cloud providers do let you tag resources for cost attribution, but AWS cost allocation tags apply only from the moment you activate them and are not applied retroactively. So the month you finally need a breakdown is the month you begin to be able to produce one, and the history you wanted to compare against does not exist.

Leaked spend also turns from annoying into material, and it is usually made of the same three things: a staging database nobody switched off, an orphaned volume left behind by a service that was deleted in March, and an instance that was sized for a load test which ran once.

The uncomfortable version of this is that most teams at this size cannot say what a single customer costs them to serve, not even approximately. They know the total and they know revenue, and everything in between is an estimate somebody produced once under pressure and nobody has revisited since. Once a cost can't be attributed it gets argued about instead of managed, because every team is confident the spend belongs to another team and nobody can prove it either way.

Should you hire for it?

This is also the stage where team management enters properly, because the question of whether to hire for this becomes real. The honest way to think about it is not the salary but what the week actually goes on, which is upgrades, credentials, cost investigations, and answering the same questions other engineers keep asking. That is a real job producing real value, and it is also a job you are creating on purpose, with onboarding and a handover and a bus factor of its own.

Hiring for it is the right call when infrastructure is part of what makes your product good, and it is a mistake when it is a way of making a problem somebody's job rather than removing it. The test worth applying is whether the role would still exist if the work were three times easier. The other thing nobody prices in is that once one person owns all of it, the rest of the team stops learning how any of it works, which is fine until that person leaves and you find out you were renting the expertise rather than building it.

The opportunity cost nobody sees

The opportunity cost at this stage is the deepest one in this article, because friction doesn't only slow down what gets built, it changes what gets proposed. If standing up a new service takes three days and two interruptions, nobody suggests the feature that needs one, and that cost never appears anywhere because the idea never reaches a roadmap for anyone to decline.

There is no line in any budget for this and there never will be, because the decision happens before anything gets written down. Somebody thinks about what a feature would take, decides it isn't worth the conversation, and proposes something smaller instead, and everyone in the room agrees that was a sensible plan. That is what makes it so hard to catch, because a team that stopped proposing ambitious things because deployment is painful looks exactly like a team being disciplined about scope.

The costs that never enter anybody's model

There are four more worth naming briefly.

• Latent cost. Setup that exists only in someone's head, and you pay it on the day that person is on holiday or leaves.
• Switching cost. Everything you build yourself you also have to migrate off yourself later, and that is the same work done under worse conditions with users already on it.
• Evaluation cost. The weeks spent comparing options, and those are real weeks whichever option wins.
• The cost of being wrong slowly. This is the largest one here. If shipping is slow then you find out you were wrong about the market slower, and that is the only cost in this article that can actually end the company.

What to do about it

Five things worth doing regardless

There are five things worth doing regardless of what else you change, roughly in this order.

1. Tag everything now, before you need the breakdown, because the tags are not retroactive and the history you will want does not exist until you start collecting it.
2. Set billing alerts rather than relying on a monthly review, because a threshold alert turns a spike into a Tuesday afternoon instead of an invoice.
3. Run a quarterly sweep for volumes, environments and instances that nobody claims, which takes about an hour and always finds something.
4. Give the bill an owner, and make that a person rather than a team, whose explicit job is being able to say where the money went.
5. Write the runbook even if you write it badly, because a bad one turns a two-day rebuild into a two-hour one.

Three structural choices

Then there are three structural choices, and I'll be straight about all three.

1. Keep building it yourself. This is the right answer if infrastructure is part of what makes your product good. The condition is that you make the cost visible by putting it on a roadmap with an owner, rather than treating it as free because it never appears on an invoice.

2. Use a managed platform. Railway, Render, Fly and Heroku are all good at this and most of them will run your database as well. The thing worth checking before you commit is the shape of the bill as you grow rather than the starting price, because most of them meter the pieces separately, and separate meters are how a modest application becomes a number you have to explain to somebody.

3. Stop owning the layer at all. This is what we are building. Choreon takes your source, whether that is a repository, a container image or a folder on your laptop, and runs it, with Postgres or Redis if you need them and with secrets, domains and gateway auth included. The part that matters for this article is the bill, because the database, the bandwidth and the auth sit inside the plan rather than on separate meters, which means the price on the pricing page is the price you actually pay. It starts at $6.99, and running the same setup on your own AWS, GCP or Azure account is coming, with a waitlist open for it.

Which problem do you have right now?

So the useful question is not whether your infrastructure bill is too high, it is which of those three problems you currently have. Most teams are still managing the one they had at their last size, which is why the bill keeps being the thing that gets discussed and the forecast never does. Work out which cost is actually binding on you right now, because it is rarely the one you are watching and it is almost never the number on the invoice.