What It Actually Costs to Run a Small Software Product
A small software product can look cheap to run until you count everything that keeps it alive.
Take a small app with a handful of paying customers and check its hosting bill, and you’ll usually be pleasantly surprised — a few dollars a month, sometimes less. That number is real, and it’s also almost meaningless, because hosting was never the expensive part of running software. It’s just the part that’s easiest to check.
The expensive part is everything that number doesn’t include: the email service that sends account notifications, the payment provider taking its cut of every transaction, the monitoring tool that pages you when something breaks, the backups, the domain renewal, the third-party APIs you’re quietly dependent on. None of these cost much individually. Add up a dozen of them and you’ve got a real monthly number that never shows up when someone asks “what does it cost to host your app?” — because hosting was never the question that mattered.
The number that actually matters isn’t what it costs to run — it’s what it costs to get a customer
Here’s a scenario worth sitting with: a product charges 50 of advertising spend, and the average customer sticks around for two months, the business just lost $30 on a “customer” that looked profitable in every spreadsheet that only tracked hosting.
This is the trap in how people talk about running software cheaply. They mean serving customers is cheap, which is often true. They rarely mean acquiring customers is cheap, which is a completely separate number, frequently much larger, and the one that actually decides whether the business survives.
Free users still cost something
A generous free tier is a legitimate way to grow a product — people try it, tell other people about it, some fraction convert to paying. But “free” describes what the customer pays, not what the product costs to deliver. A free user still stores files, sends API requests, generates support tickets, shows up in your infrastructure bill. None of that is a reason to avoid free plans. It’s a reason to know, specifically, what a free tier costs you and what you expect to get back for it. A free plan with no clear purpose doesn’t stay harmless — it just quietly becomes an expense nobody budgeted for.
The biggest cost usually isn’t money — it’s time
For most small software products, the single largest expense never appears on a bank statement. It’s the founder’s own time, and because nobody’s writing themselves a paycheck for it, it’s easy to pretend it’s free. It isn’t. Three weeks spent building a feature that four people asked for is three weeks not spent fixing the onboarding flow that’s losing you customers, or talking to the ten people who’d actually pay you more if you asked. That’s a real cost — an opportunity cost — even though no invoice will ever show up for it.
Shipping doesn’t end the spending — it starts a different kind
The first version of a product is the cheap part, relatively speaking. What comes after is a permanent, low-grade tax: dependencies need updating, security patches need applying, a browser update breaks something that worked fine last month, and a feature that was fine for 100 users starts creaking at 10,000. None of this is a sign you built something wrong. It’s just what “maintained software” means, and it’s a cost that never really goes to zero for as long as the product is alive.
Pricing decides whether any of this works
The exact same codebase can be a disaster at one price and a healthy business at another. A product that costs 500 is bleeding out. The same product bringing in 10,000, the infrastructure barely registers. This is why cost-cutting alone rarely saves a struggling product — the fix is usually on the revenue side, not the expense side. The job isn’t to spend the least possible amount. It’s to create enough value that people will pay meaningfully more than it costs you to deliver it.
And revenue is not the same thing as profit, however obvious that sounds written down. A product doing 9,000 in expenses is a fundamentally different business than one doing 2,000, even though both would show up identically in a “we’re doing $10k MRR” tweet.
Retention changes the whole shape of the economics
A customer who pays once is not worth the same as a customer who pays every month for three years — obviously, on some level everyone knows this, but it’s easy to underweight in practice. If people churn quickly, the business is permanently running to replace them, which means permanently spending on acquisition just to stand still. A product with strong retention gets to spend that same energy improving the thing itself instead. This is arguably the single biggest lever in small-software economics, bigger than almost any cost-cutting move available.
Small doesn’t mean copying a big company’s overhead
One genuinely avoidable mistake is small teams adopting the operating structure of companies fifty times their size — separate tools for every function, processes designed for coordination problems a two-person team doesn’t have, subscriptions accumulated because they seemed like what a “real” company should be paying for. A product with a few hundred customers rarely needs any of that. It needs the smallest set of tools that reliably does the job, reviewed occasionally enough that dead subscriptions get cancelled instead of quietly renewing forever.
What the numbers are actually telling you
Strip away the individual line items and the real question underneath all of this is simple: how much does it cost to get a customer, how much do they pay you, how long do they stay, and how much does it cost to keep them happy while they do? Those four numbers, taken together, tell you far more about whether a product is healthy than its user count ever will. A product with thousands of signups can be losing money every month. Another with a few hundred paying customers can be quietly, boringly sustainable — which is its own kind of success, even if it never makes for an exciting headline.
Software has a real advantage buried in all of this: once it exists, serving one more customer is usually far cheaper than making one more unit of almost anything physical. That’s the leverage that makes the business model powerful in the first place. But leverage only works in your favor once the underlying economics — acquisition cost, retention, and the ongoing cost of keeping the thing alive — actually line up. Getting those three things right is the real work. The hosting bill was never it.