Spend your three innovation tokens on the product

Choosing Postgres and a boring monolith looks lazy. It is not. It is one of the highest-leverage decisions a small team can make, and most people get it backwards.

Here is the model I use. You get about three interesting-technology bets before complexity starts eating your speed. Three. That is the whole budget. Every exotic database, every bespoke message queue, every clever microservice boundary spends one of those tokens.

The math nobody runs

At six engineers, every token you spend on infrastructure is a token you did not spend on the product. And the product is the only thing that decides whether you get to have a year four.

So spend all three on the thing customers actually feel. None on your infra.

What "boring" buys you

• Answers already exist. Your weird production issue has a Stack Overflow thread from 2019.
• Hiring is easy. You are not training every new engineer on a stack only you understand.
• Operations are predictable. Boring systems fail in boring, documented ways.

You are not Google yet. That is the point. Google earned its exotic infrastructure by first surviving on boring infrastructure long enough to have problems worth solving with exotic infrastructure.

When to actually spend a token

Spend a token when the exotic choice is the product. If your differentiator is real-time collaboration, spend a token on the hard sync problem. If it is search quality, spend it on the retrieval stack. Spend where the customer feels it.

Everywhere else, be relentlessly, unfashionably boring. Future you, debugging at 2am with a sleeping team, will be grateful.

Glossary

Tools

Postgres

An open-source object-relational database system that extends SQL. It is a common default choice for storing application data.

Stack Overflow

A question-and-answer site where programmers ask and answer technical questions.