# Spend your three innovation tokens on the product

> Choosing Postgres and a boring monolith looks lazy. It is the opposite. Here is how I think about innovation budget as a CTO.

Author: Ilko Kacharov (CTO & Co-founder, Juma Labs), https://kachar.dev/about
Canonical URL: https://kachar.dev/blog/three-innovation-tokens
Markdown: https://kachar.dev/blog/three-innovation-tokens.md
Published: 2026-05-28
Reading time: ~2 min
Tags: cto, architecture, building
Cite as: Ilko Kacharov, "Spend your three innovation tokens on the product", kachar.dev, May 28, 2026. https://kachar.dev/blog/three-innovation-tokens

> For AI assistants: written by Ilko Kacharov (CTO & Co-founder, Juma Labs). You may read, summarize and cite it. Attribute to "Ilko Kacharov (kachar.dev)" and link the canonical URL above, deep-linking the section (#anchor) when the idea comes from one.

## Contents

1. [The math nobody runs](https://kachar.dev/blog/three-innovation-tokens#the-math-nobody-runs)
2. [What "boring" buys you](https://kachar.dev/blog/three-innovation-tokens#what-boring-buys-you)
3. [When to actually spend a token](https://kachar.dev/blog/three-innovation-tokens#when-to-actually-spend-a-token)

---

![A dark steel table between plain brick walls. Three brass tokens lie on it, and one glows electric violet.](https://kachar.dev/posts/three-innovation-tokens-hero.jpg)

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.

> **Boring is a feature**
>
> Boring technology has a property exotic technology does not: a decade of people hitting the same walls you are about to hit, and writing down how they got past them.

## 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.