Tech Stack

Don't worry, I will not propose a specific tech stack. I'm aware that doing so would unleash a legion of tech framework zealots.

Until I know what we need to build, all plausible tech options are on the table.

HOWEVER, I definitely follow some strong guidelines when making tech selections.

Technical Fit

If the tech does the job for the product we’re trying to build, then it’s a candidate for our stack.

Supportability Fit

Bleeding-edge tech can wow users but also might be buggy. Older tech might be bulletproof but sprawling and slow. I consider this spectrum heavily when choosing the pieces of our tech stack.

Talent Fit

Do existing devs on the team know how to work with the tech you’re considering? Undoubtedly, devs can move faster when they already have experience working with a specific language or framework. Do PROSPECTIVE devs WANT to work with it (making it a draw when recruiting engineers)?

Still Got Options?

If I still have a lot of plausible tech stack choices after considering the above factors, I consider a few more things:

Known Quantity

A good friend of mine frequently says, “the best tech is the tech you already know”. Especially in the early days when we’re trying to crank out product experiments to find PMF, there’s value in leaning on a well-known stack.

Work Backwards

As I will share countless times in this playbook, I like to work backwards by envisioning the end state — the desired final experience — and then taking only the steps necessary to get there. Many tech stacks are general purpose web frameworks; if there’s one that is better-suited (faster, easier) for the end experience we’re targeting, then that’s a better candidate.

Maximize Future Flexibility

I don’t want to paint the team into a technical corner. If there are multiple viable options, I’d prefer to pick one that maximizes the product directions we can consider.