Why we always challenge the tech stack before we start a build and what we find

Before we start any build, we run a technical framing session. One of the things we always cover is the proposed tech stack — and we almost always find it was chosen for the wrong reasons.

The most common reason founders choose a stack: it's what their first developer knows. Not what fits the product. Not what fits the hiring market. Not what fits the infrastructure budget. What the developer happens to know.

This is understandable. It is also the source of a significant percentage of the technical rework we see in early-stage startups. Three months in, the founder needs to hire a second developer and discovers the stack their first developer chose has a thin talent pool. Or the infrastructure costs are significantly higher than projected. Or the developer who left is the only person who understood the architecture.

What a good stack decision considers:

Team fit can your current team execute well in this stack, and can you hire people into it within a reasonable timeline?

Ecosystem maturity does the stack have well-maintained libraries for the integrations you need, or will you be building those from scratch?

Infrastructure cost at 3x scale what does it cost to run this stack when your user base is three times its current size?

Security defaults does the framework have good security defaults, or does it require significant additional work to be production-safe?

These four questions take two hours to work through properly. The answers change the stack decision more often than not.

If you want this thinking applied to your build before development starts: foundersbar.com/advisory