Boring stack

Every piece of technology you adopt is a claim on future attention. A framework nobody else uses means every future hire starts from zero, every stack trace ends in source code you did not write, and every upgrade is a project.

So our default is boring: Postgres, a queue you have heard of, a runtime your team can already debug, deployment that fits on one page.

Where boring pays

• Hiring. The candidate pool for common technology is measured in thousands; for niche technology it is measured in people you personally know.
• Incidents. At 3am you want the answer to be a well-worn runbook, not a novel. Common failures have published fixes.
• Exit. If we are hit by a bus — or you simply decide to build it in-house — the next team inherits a codebase full of ordinary parts.

Where we are happy to be interesting

Your differentiator. If the thing that makes your product worth paying for is a novel ranking model, a simulation, a compiler, then that is exactly where unusual choices are justified — because that is where being ordinary would waste your advantage.

The rule is: be boring everywhere except the thing you actually sell.

What this is not

It is not a refusal to adopt new technology. It is a demand that new technology pay rent. If a newer tool removes a real operational cost we are carrying today, we will move — with a written reason and a way back.

The test we apply

Could a competent generalist, hired next year, take this over from the documentation alone? If the answer needs us specifically, we have built the wrong thing.