Why I build on boring technology

The stack I choose — for clients at TWENTYONE and for TRVL alike — is deliberately unremarkable. React for the interface, Next.js to render it, Node.js on the server, React Native for the iOS and Android apps, and PostgreSQL underneath all of it. None of it would get a conference talk accepted. That is exactly why it is there.

The clearest version of the argument is Dan McKinley's essay Choose Boring Technology. Every organisation, he suggests, gets a small number of innovation tokens to spend. Each new, unproven piece of technology spends one, because nobody yet knows how it fails. Spend them on what makes your product different, and build everything else on things whose failures are already understood.

That last phrase is the real benefit. When PostgreSQL misbehaves, somebody has seen it before, written it down and answered the question. The error message is searchable, the behaviour under load is documented, and the edge cases have been argued about for decades. A new database may well be faster in the benchmark on its homepage; it is certainly less known in the situation you will actually be in when it goes wrong.

The second benefit belongs to the client. A system built on the most widely used open-source tools in the world can be handed to any competent developer anywhere and understood in a week. That is a property worth more than most features. It means a business is never hostage to the one person who understood the clever part, including us.

The third is that one language runs everywhere. With TypeScript across the web front end, the server and the mobile apps, the rules that decide a price, validate a booking or format a date are written once and shared, rather than reimplemented three times and allowed to drift. Most of the bugs I care about live in the gaps between two implementations of the same rule; the fewer copies, the fewer gaps.

PostgreSQL deserves a paragraph of its own, because it is routinely underused. It is a relational database with real transactions, and it is also a perfectly capable store for JSON documents, a full-text search engine, and — with the PostGIS extension — a geographic database. Many products add a separate service for each of those. Each one is another thing to run, secure, back up and keep consistent with the others. Often the boring answer is that the database you already have can do it.

Boring is not the same as never changing. The tools themselves move constantly — React and Next.js release major versions often enough to keep anyone busy — and keeping up with them is part of the job. What stays fixed is the choice of foundation, so that effort goes into the product rather than into migrating between fashions.

And there is a time to spend a token. When the product itself is the new idea — when the unusual technology is the thing customers are paying for — then the unusual technology is the right call. The discipline is in spending the token on purpose, once, where it counts, rather than by default in every layer because something new was available.