What we built Frontastic on

Here is the stack we ran Frontastic on, told plainly. CouchDB as the primary datastore. PHP for the application. MySQL, later CloudSQL, where we wanted relational data. And for a long time it ran on plain compute instances, not Kubernetes, because back then Kubernetes was new and not yet the safe default it became.

By innovation-token accounting that looks disciplined, and mostly it was. We spent essentially nothing on novel infrastructure. The attention we saved did not sit idle: it went into the domain, the editing experience, and the actual problems our customers had. For an early-stage product that is the only place the budget should go.

But one of those choices does not fit the story, and it is the interesting one.

CouchDB was the boring choice. For us.

In the mid-2010s, CouchDB was not a boring technology. By any market measure it was the opposite: a document database most teams had never run in production, a small hiring pool, few war stories to learn from. On the standard reading, choosing it spent an innovation token, maybe an expensive one.

It did not cost me anything close to a token, because I had run CouchDB in production for years and had written the PHP library for it. For me and the people I brought in, CouchDB was the option I understood most deeply, the one whose failure modes I already knew, the one I could debug at three in the morning. It was, in the most literal sense, the boring choice.

And it more than earned the trust. In all the years we ran it, almost nothing I have operated has been as stable as CouchDB or caused as few daily production issues; no other database comes close. Big kudos to the CouchDB team for that, it is the kind of reliability you only notice by how loudly its absence shows up everywhere else.

That is the refinement. An innovation token is not denominated in how novel a technology looks from the outside. It is denominated in how much your team already knows it. The same database is a spent token for one team and the boring default for another, and the only thing that changed is who is choosing.

Which way it cuts

This matters because it cuts in both directions, and people usually only hear one.

It means a technology the conference circuit considers exotic can be the right boring choice for you, if you happen to know it cold. Do not let the market's opinion of how adventurous something looks override your own hard-won experience with it.

It also means the reverse. A mainstream, universally-recommended technology that nobody on your team has actually run is still a spent token. "Everyone uses it" is not the same as "we know it". Picking the popular option you have never operated can cost you exactly the token you thought you were saving, and you will pay it during the first incident, when it turns out nobody knows how the thing behaves under load.

So "choose boring technology" is better read as "choose the technology your team already knows cold", which now and then means choosing something the rest of the industry would call a bold move.

Summary

The innovation-token budget is the right model, and you should spend almost none of it, especially early, when every token not spent on tech is attention spent on the product instead. I have argued before that the place for your tokens is the domain, not the backend. The refinement is only this: boring is not a property of a technology, it is a property of the fit between a technology and the team choosing it. Measure the token from your own team's chair. Sometimes the safest possible choice is the one that looks, from the outside, like your most daring.