What a small product actually costs to run

Every “I built a SaaS in a weekend” post ends at launch. The interesting part starts about three weeks later, when the first customer emails you at 11pm because something is broken, and you discover which of your architectural decisions were actually decisions about your evenings.

This is the list I now go through before starting anything. Not to talk myself out of it — to know what I am signing up for.

The bill you expect

For a small product with real but modest traffic, the infrastructure is close to free, and that genuinely is the modern situation:

• Hosting. Static front end on a CDN: free. A small application server or serverless functions: a few dollars a month up to a few tens.
• Database. A managed Postgres small instance costs less than a takeaway. Serverless offerings have free tiers that are enough to launch on.
• Object storage. Pennies until you have real volume, and then still cheap if you picked a provider with sane egress pricing. Egress is the line that bites — check it before you pick, not after.
• Domain. Ten to fifteen a year.
• Email sending. Free tiers cover thousands of messages. This stops being free at scale, and it is worth knowing where the cliff is.

Under $50 a month covers an enormous amount. This is why the “weekend project” genre exists, and it is not wrong.

The bill you forget

Transactional email deliverability. Not the sending — the arriving. SPF, DKIM, DMARC, a dedicated subdomain, and a week of wondering why Outlook is eating your password resets. No money, quite a lot of Saturday.

Error tracking and uptime monitoring. Free tiers exist and are fine. But there is a decision point, because without them you find out about outages from customers, and that is a worse product than the outage itself.

A status page. You do not need one until the first incident, at which point you need it immediately.

Payments. Two to three percent plus a fixed fee per transaction, which is fine and fair. The hidden part is everything around it: failed-payment retries, dunning emails, VAT and sales tax in the places that want it, invoices with the right legal fields. A merchant-of-record service takes a bigger cut and makes all of that somebody else’s problem, and for a solo product that trade is usually worth it. I have done it both ways and I would not hand-roll tax handling again.

Support. This is the real cost and it is not money. Even a good product generates email — and most of it is not bugs, it is people who cannot find something, which is a documentation problem wearing a support costume. Budget an hour a day once you have a hundred paying customers, and write down every question you answer twice.

Security work nobody asked for. Rate limiting, spam on any public endpoint, someone probing your API with a scanner in week two. Anything with a public form gets abused. ShipMyForm exists partly because I got tired of rebuilding that layer on every client project.

The line that surprises people

Attention. A product you have shipped is a small, permanent tax on your ability to concentrate on anything else. Not the maintenance hours — the background process. Is it up? Did that deploy go out? Did that customer reply?

I take this seriously now when deciding what to build, because it is the resource I have least of. Two products is not twice one product. It is somewhere closer to three times, because the switching cost is real and the interruptions do not queue politely.

How I keep it small

A few rules that have held up.

Boring infrastructure. Managed database, static front end, a single application container or a set of functions. No Kubernetes, no service mesh, no message broker I have to operate. Every piece of infrastructure is a thing that can page me.

One database, and back it up automatically. Then restore it, once, to a scratch environment, so you know the backup works. An untested backup is a feeling, not a backup.

Logs that tell me what happened. Structured, searchable, with request ids. The first hard bug in production is where this pays for itself, and by then it is too late to add.

A deploy I can do from my phone. Not because I want to. Because I will need to, on a day I am not at my desk, and the alternative is a product that goes down until I get home.

No feature I cannot support. If a feature will generate support email I cannot answer in two minutes, it needs documentation before it ships, not after.

What I would tell someone starting

Build the thing. The costs above are all manageable and none of them are a reason not to start.

But make two decisions consciously rather than by default, because they are the ones that are painful to reverse: who handles your payments and tax, and how you find out when it breaks. Everything else — framework, hosting, language, database — you can change later for less effort than you think.

And write down what it actually costs you each month, including the hours. Not for a blog post. For the moment eighteen months in when you are deciding whether to keep going, and you want the decision to be made with numbers rather than with how you feel that week.