What SaaS teams get wrong about infrastructure

July 27, 2026 · 4 min read · Josh Dargie · Markdown

I spent years on the platform side of hosting companies, which means I spent years watching SaaS teams make the same infrastructure mistakes from a front-row seat. Not exotic mistakes. The same four or five, over and over, at companies of every size. This one is for the practitioners.

The single-region assumption you did not know you made

Almost nobody decides to build a single-region product. They just build, and one day they notice that every assumption in the codebase quietly depends on everything being in one place: one database with millisecond latency to the app servers, one job queue, one cache, timestamps that assume one clock, a deploy pipeline that targets one environment.

The mistake is not running in one region. For most SaaS businesses, one region with good backups is a perfectly defensible choice, and pretending otherwise leads teams into half-built multi-region setups that are worse than either honest option. The mistake is not knowing which choice you made. Write it down as a real decision: here is what happens when our region has a bad day, here is roughly how long recovery takes, here is who accepted that risk. If the answer embarrasses you in writing, that is the signal to fix it. If it reads as acceptable, stop feeling guilty about it and move on.

The half-measure to avoid: a "failover" environment that has never once served production traffic. That is not a second region, it is a second bill.

Backup theatre

Every SaaS team has backups. A much smaller number has restores. I have sat in more than one incident where the backups had been running green for months and the first actual restore attempt, performed under maximum pressure, revealed that the dumps were incomplete, the credentials had rotated, or the restore took thirty hours against a customer promise of four.

The fix is cultural, not technical: a restore that has not been rehearsed does not count. Put a recurring calendar entry on it, restore into a scratch environment, time it, and record the number. Then compare that number to whatever your contracts and status page imply. The interesting output is not "it worked", it is the duration, because that duration is your real recovery time and it usually surprises people.

I wrote an owner-level version of this argument in a backup strategy an owner can actually audit. The engineering version is the same three questions with more zeroes attached.

The bill nobody owns

Cloud cost surprises are rarely one big line item. They are forty small ones: the logging tier someone enabled during an incident and never disabled, cross-zone traffic between chatty services, snapshots accumulating since 2023, the oversized instances that were "temporary" during a launch. Each is too small for anyone to own; together they are a salary.

Two habits fix most of it. First, someone specific owns the bill and reads it monthly, line by line, the way a CFO reads anything else that size. Second, cost gets estimated at design time: a one-line "this feature adds roughly X per month at current traffic" in the design doc changes decisions while they are still cheap to change. Untracked spend behaves exactly like untracked shortcuts in code; it compounds quietly, the way I described in technical debt in plain terms.

Capacity planning is the other half of the money conversation, and most teams do it by vibes. It does not take much rigour to do better; the approach in capacity planning for hosting scales down to a spreadsheet and an afternoon.

Boring technology is a competitive advantage

The highest-margin infrastructure decision a SaaS team can make is to be uninteresting. Postgres, a mainstream cloud or a competent managed host, one well-understood queue, deploys that are dull. Every additional novel component is a tax paid in on-call pages, hiring difficulty, and upgrade projects, and the tax recurs forever.

The teams I watched succeed treated infrastructure novelty as a budget: you get one or two exotic choices, spent only where they touch the actual product advantage. Everything else should be the most boring thing that works, run by people who have seen it fail before. Some of the most reliable platforms I worked on were built from components a Hacker News thread would sneer at, operated with total discipline.

Your customers cannot tell what your stack is. They can absolutely tell whether you were up last night.

The pattern under the pattern

All four mistakes are the same mistake: infrastructure decisions made implicitly, by accretion, instead of explicitly, by someone accountable. The fix is not heroics, it is writing decisions down and rereading them on a schedule.

If your team has grown past the point where infrastructure decisions happen by accident and nobody has time to own them properly, that gap is what my fractional engagements exist for: a few hours a week of someone who has watched these movies before, on a monthly retainer, with no platform to sell you.

← All posts