Portable architecture for small products with one maintainer

A studio with one maintainer cannot carry a large operational surface. Every additional service is another thing to patch, monitor, pay for, and understand again after six months away from it.

So the question we ask of any component is not whether it is the best tool, but whether it is a tool we are willing to be woken up by. That reliably produces smaller architectures than the ones the reference diagrams suggest, and they have been notably easier to keep alive.

Full cloud-agnosticism is a tax paid up front for a benefit that usually never arrives. Complete lock-in is a risk with no ceiling. The middle position we settled on is to keep the boundaries portable and let the middle be pragmatic.

Concretely: business logic has no vendor types in it, storage is behind a narrow interface, anything long-running is a queue plus a worker rather than a proprietary orchestration format, and configuration comes from the environment. Managed services are used freely behind those boundaries.

That has been enough to move workloads between platforms twice without a rewrite, while still using the convenient bits of each.

Every dependency is a bet on someone else's next five years. For products that are meant to outlive our enthusiasm for them, we bias hard toward widely used libraries with slow release cadences, and we prefer writing fifty lines to adding a package that does slightly more than we need.

The reward shows up at upgrade time. A small, boring dependency tree can be brought current in an afternoon; a fashionable one can take a week and a partial rewrite.

A product that costs a meaningful amount per month at zero users is a product on a clock. We design for a near-zero idle cost so that anything we build can simply stay online while it finds its audience — or while it finds none at all.

That means scale-to-zero compute, storage priced by what is stored, no always-on cluster, and seasonal capacity that exists only when it is needed. It also means measuring cost per user early, because a shape that is fine at a hundred users and ruinous at ten thousand is better discovered before the ten thousand arrive.

The operational kit is deliberately small: structured logs, a handful of alerts that only fire on things a human must act on, one dashboard per product, and a documented restore path that has actually been executed at least once.

Anything more elaborate goes unread. Anything less and a quiet failure runs for a fortnight before anyone notices — which, for a studio building its own ideas, is the failure mode that actually costs you something.