the boring stack we keep recommending

over the last decade we have shipped roughly the same architecture, in the same shape, on top of the same handful of tools. it is not glamorous. it is also the reason we sleep at night.

the shape

postgres for the data. a single application server in whatever language the team already knows — usually go, sometimes typescript, occasionally elixir. one cache, one queue, one storage bucket. a single managed kubernetes cluster, or a single fly.io app, or a single render service. one deploy pipeline. one observability vendor.

that is the whole picture. we draw it on the wall on day one and it almost never changes.

why one of everything

at the scale most studios actually operate, complexity is the bug. every additional moving part is a new failure mode, a new on-call rotation, a new vendor contract, a new line in the runbook. a team of seven engineers cannot meaningfully maintain three databases. they can barely maintain one.

so we pick one of each, and we pick boring.

postgres is still the answer

jsonb columns cover most of what people reach for mongo for. tsvector covers most of what they reach for elasticsearch for. logical replication covers most of what they reach for kafka for, until it doesn't — and by the time it doesn't, you can afford a real platform team.

what we will not pick

• microservices, until you have more than one team.
• graphql, until your client surface genuinely needs it.
• a custom auth stack. ever.
• your own kubernetes cluster, until you have someone whose job it is to care about it full-time.

the part that's actually hard

the stack is the easy decision. the hard one is the model — the names of the tables, the contracts between the services, the shape of the api. that is what we spend the first two weeks on, and what we re-litigate every quarter. the stack just has to stay out of the way while we figure that out.