Every so often a business comes to me wanting to move their app somewhere new. There’s usually a reason. The collaboration with the old developer ran its course, or the monthly cost crept up past what felt fair, or they simply want their own team behind something that now matters.
And every so often that conversation stops dead at the same place. The app runs on a computer nobody in the room has the password to. The business paid for the software, but never owned the infrastructure that powers it.
You can own the software and still not own what it runs on.
This post is about the least glamorous line in your whole project, the running costs. What it actually is, who pays for it, and why whose name it’s in ends up mattering more than most people expect.
What “the server” actually is
When someone tells you your app “needs a server,” here’s what they mean. Your software has to live on a computer that’s always switched on and connected to the internet, so your customers can reach it at any hour of any day. You don’t buy that computer. You rent it, by the month, from a hosting company. Might be a giant like Amazon or Google, might be a smaller provider. And that rented computer is only the middle of a longer chain.
My domain, bovolato.dev, is the equivalent of an address in the internet’s phone book. Everytime a new address comes up, it has to appear in this phone book, and must be kept up to date. All computers in the world look up that same phone book (DNS), and that’s expensive to maintain. You rent the address by the year, that’s the only way for the DNS to stay alive.
Then the app itself needs somewhere to keep things, usually a database. Copies of that data get taken automatically, in case a disk fails or somebody deletes the wrong row, and those backups are stored and billed too. The emails your app sends, like password resets, go out through a specialist service that charges per message. Each of these is a separate utility that has to be paid for.
It’s worth being clear on why none of this can be free. Somewhere there is a real machine in a real building, drawing real electricity, cooled, connected, and kept alive around the clock by real people. You’re renting a slice of that. Free tiers exist, and they’re fine for a hobby or a demo, but you also outgrow them fast.
A lot of these meters bill by usage. Per email sent, per gigabyte stored, per amount of traffic served. The monthly invoices shows you how much the app is used.
That’s exactly why a someone who offers you a fixed price every month has to build in a cushion, in the same way an insurance operates. To offer you predictability, they have to cover the worst scenario, or they lose money on the deal.
Whose name is on the accounts
When you rent an apartment, you want the utilities in your name. Because the day you fall out with the landlord, you don’t want your electricity to be something they can switch off.
For software it’s the same. Ideally every one of those is in your name, from the start. Your developer gets full access to set them up and run them, does all the hands on work, and you never have to touch a control panel. But the accounts belong to you.
Most of the time you can, and should, let them run it. The point isn’t that you manage these accounts. It’s that you hold them. That single boring distinction is what buys you three things:
- You can change developers whenever you want. Access is a permission you grant and take back, not a favor you have to beg for. You revoke the old developer’s access, hand it to the next one, and the app never moves.
- If your developer disappears, your app doesn’t go with them. When the accounts are theirs and they go quiet, the bills eventually stop getting paid and the whole thing can be switched off from under you. When they’re yours, that can’t happen.
- You can see the real numbers. The hosting company bills you directly, so you know what the infrastructure genuinely costs, separate from what you pay a person to look after it.
Own the accounts, and switching developers is just a normal day. Don’t, and it becomes a rescue operation.
The three ways it actually gets set up
The developer hosts it and bills you
Everything sits on the developer’s own accounts, and they either pass the cost through or fold it into a flat monthly fee. This gets an unfair reputation, but it’s genuinely convenient. Nothing for you to set up, one invoice instead of six, zero admin time. It can also be cheaper than doing it yourself, because a developer running many clients on shared infrastructure buys in bulk and passes some of that on, and it tends to be faster for them to work on, because it’s their environment and they know every corner of it.
The thing to understand is simply what you’re getting. You’re renting your foundation from the person who built the house. You don’t see the underlying costs, leaving is harder, and if the developer vanishes your app can go with them. For something your business genuinely depends on, it deserves some thought.
You own the accounts, the developer runs it
You pay one (or more) company directly for the infrastructure, and you pay the developer for the work of keeping it healthy. Two separate relationships, and you can end either one without losing the other. It’s barely more effort to set up than the first option, and it removes almost every way the arrangement can trap you later. This is what I lean towards for anything a business actually relies on.
You own it and your own team runs it
Your team owns the accounts and operates everything themselves. This is the right answer once you’re big enough to have that, and it usually arrives as part of bringing the whole system in house.
Infrastructure and the labor are two different things
One last distinction:
- The infrastructure bill is what you pay for all the metered services. This scales with how many people use your app.
- The work of looking after it, watching to make sure it’s up, testing backups, applying updates, being reachable when it breaks at an awful hour, scales with how much it would hurt for the app to go down.
They’re genuinely different animals, and it’s worth knowing which one you’re paying for, even when they turn up on the same invoice as a single figure. An app that was cheap to build but is used by a million people can cost far more to keep online than an expensive one that a dozen staff open twice a day.
So what does it all cost
So, you want a number. Treat these as rough all in monthly figures:
- A small internal tool with light traffic. Server, a modest database, backups, some sent emails. Realistically tens of euros a month.
- A mid sized customer facing app with a real database, backups, payments and a steady volume of emails. Low hundreds a month, call it roughly a hundred to five hundred euros, and it moves with traffic.
- A larger platform with heavy traffic and enough spare capacity that it stays up when a piece of it fails. Several hundred to a few thousand a month, and climbing from there with scale.
The takeaway
The server is the least interesting part of your software and one of the easiest to get wrong. It’s rented computers, wrapped in a handful of metered services, billed every month for as long as the app is alive, and separate from both the cost of building the thing and the cost of looking after it. None of that is complicated once it’s laid out.
What matters is whose name is on the accounts, because that one dull detail is the whole difference between owning your software and renting it back from the person who built it. You can hand the running of it to me, or to anyone good, and never touch a control panel. Just make sure that when you’d want to walk away, the keys are already in your pocket.
If you’re not sure whose name your app is currently running under, or you’re staring at a monthly figure and can’t tell what’s inside it, that’s a short conversation worth having before you sign anything.