How We Chose Our Tech Stack (and When We'll Break Our Own Rules)

Having a default tech stack is less about believing it's the objectively best option in every case, and more about not re-deciding foundational architecture from scratch on every single project. A default is a starting position, not a rule without exceptions - and the exceptions matter as much as the default itself.

What We Actually Optimized For

Our default stack decisions weren't made by chasing what's newest or most discussed. We weighed a specific, narrower set of factors: how many engineers can competently maintain the codebase later, not just build it initially; how mature and stable the ecosystem is for the kind of applications we build most often; how well it supports the maintainability our clients need, since most of our relationships extend well past initial launch into ongoing support; and how predictable its hosting and scaling costs are at the traffic levels our typical client actually reaches, not at hypothetical massive scale.

None of these factors reward chasing the newest framework the moment it appears. Stability and maintainability compound in value over a multi-year client relationship in a way that a marginally faster benchmark doesn't.

Why a Default Stack Matters More Than People Assume

A consistent default means our team can move faster on new projects because the foundational decisions aren't being re-litigated every time. It means a developer coming onto a project mid-stream, or picking up support work on something built a year ago, isn't learning an unfamiliar stack on top of learning the specific codebase. And it means our estimation process - which depends on genuinely understanding the work involved - is more accurate, because we're estimating against a stack the team already knows deeply rather than one they're learning as they go.

Where We Break From It Anyway

The default doesn't hold when a project has a specific, well-justified reason to diverge. If a client's team will maintain the codebase after handoff and already has deep expertise in a different stack, we build in what they can actually support long-term - a technically excellent solution nobody on the client side can maintain isn't actually a good outcome for them. If a project has a specific technical requirement our default stack handles poorly -certain real-time or high-concurrency workloads, for instance - we use what the requirement actually calls for. And if we're integrating tightly with an existing system built on a different stack, fighting that reality to preserve our own default usually costs more than it saves.

What We Don't Treat as a Valid Reason to Deviate

We don't switch stacks because a new framework is generating buzz, because a developer personally prefers a different tool, or because a client has heard a specific technology is "the modern choice" without a concrete reason attached to their situation. These are the reasons stacks tend to fragment across an engineering team for no real benefit, and we've seen what that fragmentation costs in maintainability later - a codebase that's a patchwork of individual technology preferences is harder to hand off, harder to hire against, and harder to support consistently.

How the Decision Actually Gets Made

When a deviation is proposed, we ask the same question every time: does divergence solve a specific, real requirement of this project, or does it solve a preference. The first gets a serious evaluation of trade-offs. The second gets weighed against the real cost of stack fragmentation, and usually loses.

Revisiting the Default Itself

The default stack isn't static either - it gets reviewed periodically against the same criteria we used to choose it originally: maintainability, ecosystem maturity, team capability, and cost predictability. When something changes enough on those dimensions to justify updating the default, we do. What we avoid is treating every new tool that appears as a reason to reconsider - the bar for changing the default is the same bar we use for justifying an exception, applied to the whole team rather than one project.