Choosing the right stack

Before we choose a stack, we ask: what’s the problem, who’s building it, and what do they already know? The answer usually narrows the field a lot. We’re not looking for the most powerful option—we’re looking for the one that gets out of the way. In practice that often means React (or similar) on the front, Node or a straightforward backend, Postgres, and hosting that we can reason about. Boring, yes. But boring means fewer surprises, easier hiring, and less “this was a great idea at the time” debt. We’ll reach for something more specialised when the problem clearly demands it: real-time, heavy data pipelines, or domains where the right tool cuts complexity in half. Otherwise we resist. The cost of a wrong bet is high; the cost of using a known quantity is low. The best choice is often the one you can explain in one sentence and that a new hire can be productive in within a week. We optimise for that.