“Zero infrastructure cost” usually means one of three things: a free tier about to expire, a credits programme about to run out, or a system that has never seen load. Ours means something more boring and more durable.
Our stated target is no mandatory monthly infrastructure cost at roughly 100 daily active users, in production, without giving up security, data ownership, or portability. Payment-processing fees per transaction are fine — they scale with revenue. A mandatory monthly subscription for required infrastructure is not.
The mechanism, not the trick
There is no clever billing arrangement. There is an architectural constraint that made the cheap path and the correct path the same path: every provider category sits behind an interface the core domain owns, and every interface ships a working free default selected through exactly the same configuration mechanism a paid implementation would use.
That last clause matters more than it looks. The free path is not a special-cased “cheap mode” branch. It is the same code path with a different value, which is why it does not rot and why moving off it is uneventful.
What that looks like per category
- Queue — a Postgres table, not SQS, Redis Streams, or Kafka.
- Search — Postgres full-text search, with pgvector available if semantic search is ever actually justified. No dedicated vector database.
- Cache — in-memory, and the system stays correct with the cache cold or entirely absent. Cache is never the source of truth.
- Storage — local disk by default, object storage behind the same interface.
- Email — a provider that logs instead of sending.
- Inference — deterministic mock responses, no API key required.
Explicitly not in V1: Kafka, SQS, Redis Streams, Elasticsearch, OpenSearch, or any dedicated vector database. Postgres does the job of a queue and of search until measured load says otherwise.
The honest part
We keep a table of every free tier we depend on, with the allowance, the restrictions, the pricing source, and the date we last verified it. The rule attached to that table is blunt: never treat any tier as free forever, and re-confirm the numbers before shipping a dependency on them.
There are live tradeoffs we accepted rather than hid. Free compute that sleeps after fifteen minutes idle means a cold start on the next request — a genuine user-experience cost, not a rounding error. A free Postgres tier with a six-hour point-in-time-recovery window is a real constraint on our recovery story. We chose our hosting partly because its free tier permits commercial use, having ruled out a more generous one that does not.
We also keep a planned migration path per category, so a tier tightening or disappearing is a budgeted transition rather than an outage. That plan is the actual product of this work. The zero is a side effect.
Why the zero is not the point
The number people react to is the cost. The number that matters is the cost of change. When a workload outgrows a free tier, we change a configuration value. Teams that treat infrastructure spend as something to negotiate later usually end up negotiating their roadmap instead — because by then the vendor is not a line item, it is a load-bearing wall.
Own every layer.