Two SaaS products. About 360 users. $125 a month in infrastructure — less than I spend on coffee.
The four business questions I asked before picking any of the tech — and the receipts.
Every business has overheads. Rent, staff, suppliers, the till. Run a corner shop badly and the overheads eat you before the customers do. Software businesses are no different — they just hide their overheads better.
I run two software products. Between them they serve about 360 users and generate real revenue every month. The total cost of the infrastructure that powers both of them, before I serve a single customer, is roughly $125 a month. That’s less than I spend on coffee.
That number isn’t a flex. It’s the answer to four basic business questions I asked before I picked any of the technology. None of them are technical questions. All four are the same questions a shopkeeper asks about rent, staff, suppliers and till speed.
1. What does it cost me to keep the lights on before I sell anything?
In most software businesses this number creeps up quietly. A bit of monitoring here, an “enterprise” database there, a logging tool everyone said you needed, a paid uptime monitor, a fancy error tracker. By the time you check, you’re spending more on tools than you earn from customers. The default cloud stack today has a fixed monthly cost that would have looked like a small office lease a decade ago.
I set a rule before I started: fixed costs stay under a coffee budget. Anything that needs to grow has to grow with revenue — not with architectural choices I made three years ago and forgot to revisit.
That single rule eliminates an enormous amount of software fashion. No Kubernetes. No managed observability platform. No specialist database for every use case. No third-party queue service. No vendor whose pricing page starts at “contact us” — if I can’t read the bill, I can’t run the business.
2. How many people do I have to hire just to keep it running?
People are the biggest line item in any software business. Servers are cheap. Operators are expensive. The moment a stack needs three specialists to keep upright — a DevOps engineer to babysit the cluster, a database administrator for the bespoke datastore, a frontend specialist for the framework’s quirks — the margins are gone before the first customer pays.
I don’t have a development team. I don’t have an operations team. I don’t have an on-call rota. I have me, and I have AI coding tools — Claude and Codex — that have got dramatically better in the last 18 months.
So the technology has to be readable, maintainable, and fixable by that team of one. Boring frameworks beat clever ones. One database doing several jobs beats five specialised services. Plain TypeScript everywhere beats a bag of clever DSLs. A codebase an AI can read in seconds beats magic that only makes sense in a senior engineer’s head.
This isn’t a sentimental preference for simple things. It’s a payroll decision I’m making years in advance.
3. When something breaks at 2am, whose phone rings — and what does that cost?
Every “best practice” stack I see ships with five tools that page someone at 3am about nothing in particular. A flaky test, a transient retry, a CPU spike, a third-party API hiccup. Each of those alerts is a salary, a contractor invoice, or a weekend lost.
I picked tools that don’t shout unless a customer is actually hurt. Built-in cloud monitoring instead of a third-party platform that costs more than the thing it watches. Errors classified into “this is the customer’s broken integration” versus “this is my system failing” — only the second category wakes me up. Database-backed queues instead of a separate queue service, because every separate service is another thing that can break independently and produce its own alerts.
A small business can’t afford a paging culture. The fix isn’t more dashboards. It’s fewer things that page in the first place.
4. How fast can I respond when a customer asks or a competitor moves?
Small businesses beat big ones with speed, not budget. If a customer asks for something on Monday and the change ships on Tuesday, that becomes a story they tell other customers. If it takes three weeks because the codebase fights me at every step, I’ve lost the round before I knew it started.
Velocity is a business asset. It’s how a single operator competes with a venture-funded team of twenty. So the tech has to protect it: type safety so refactors aren’t terrifying, preview deployments so changes are visible before they go live, no platform lock-in so I never have to ask permission to change layers, and a codebase organised so Claude or Codex can find what it needs without me hand-holding.
The opposite of velocity isn’t slowness — it’s ceremony. Every meeting, ticket, review board, change-management process and “let me check with infrastructure” is ceremony that small businesses can’t afford and big ones can’t escape.
The receipts
Now that the four questions are on the table, the numbers tell the story.
- $49 a month for the customer-facing product — the platform 360 users log into. That covers everything: web hosting, database, authentication, background jobs, email, staging environment, the lot.
- $76 a month for the engine running underneath it — the system doing the heavy lifting on the users’ behalf. Down from $284 last spring. Same product, same customers — I just paid attention and rebuilt the most expensive parts.
- $0 in salaries for ops, DevOps, or SRE. Not because those people aren’t valuable, but because I designed the stack so I wouldn’t need them yet.
- $5 a day per customer, hard-capped, on AI spend. Enforced before the cost happens, not after the bill arrives.
- Days, not weeks, to ship a customer-requested change. Most of them ship the same day they’re asked for.
Roughly $125 a month for the lot — about the cost of a flat white a day for a month. The business has overheads, like any business. They’re just the size of a coffee habit instead of a small office’s worth of cloud services.
What I’m not claiming
I’m not claiming this is what every software business should look like. A venture-funded team building for hyperscale has different problems and a bigger headcount budget to spend on them. Their answers to the four questions will be different — that’s fine.
I’m claiming this: if you’re running a small or bootstrapped software business, the four questions above are the right ones to ask first, before any of the tech. The default answers — “use the standard cloud stack, hire some people, hope the monitoring works” — are extremely expensive for a business that doesn’t have the margins to absorb them yet. There are better answers if you’re willing to think like a shopkeeper.
What’s next
Over the next five pieces I’ll walk through the specific decisions behind those numbers — what I picked, what I deliberately didn’t pick, and the business reasoning behind each one.
- Part 2 — “Bubble Became a Ceiling, Not a Foundation” — what vendor lock-in actually costs a small business, and how I knew it was time to leave.
- Part 3 — “The $49 Stack: A Line-by-Line Walkthrough” — where the money goes, where I refused to spend it, and what each saved dollar bought me.
- Part 4 — “I Want My Hosting Provider to Be Boring” — why AWS, and only the boring parts.
- Part 5 — “Postgres Is the Stack” — how one database doing four jobs saved me from hiring three specialists.
- Part 6 — “Serverless for the Bursty, Containers for the Steady” — which jobs should be pay-per-use, and which should pay rent.
None of it is clever. All of it is the kind of reasoning a shopkeeper would recognise.