Mission RHW
All writing

Boring tech
is usually the right tech.

AI builders often reach for the newest, shiniest tools. They are fast to start and painful to run. Older, duller tools usually wear better. Here is how to tell the difference.

Reading time · 7 minutes For you if · a builder is about to name a dozen tools you have never heard of

In a first call with a builder, there is often a moment when they list the tools they will use. Ten or fifteen names, most of which mean nothing to you. It sounds impressive. It sounds modern. It often is not a good sign.

The tools that hold up best for small business builds are usually the oldest, dullest, least-exciting ones. That is not a matter of taste. It is a matter of how software breaks and how long you have to live with it afterwards.

Chapter 01

What “boring tech” actually means.

Boring tech is software that has been around long enough to stop breaking in surprising ways. Ten years, twenty, thirty. Most of its bugs have been found. Most of its edges have been smoothed. Most people working in software know how to use it. Most other tools know how to connect to it.

Shiny tech is newer. It does some things better. It also breaks more, changes more often, has fewer people who can fix it, and is more likely to be shut down or to change prices dramatically next year.

A small business build needs to keep working for years on a small budget. Boring tech is better suited to that, almost every time.

Chapter 02

The shortcut trap that AI-assisted builders fall into.

AI coding tools make it easy to start. A builder can type a paragraph and get a working app back the same afternoon. That speed is a trap when the builder takes every shortcut the AI offers without asking if the shortcut is worth it.

The most common shortcut is installing outside pieces for every tiny problem. The AI suggests a third-party tool. The builder says yes. Another one. Yes. Another. By the end of the build, your software is a stack of fifty outside pieces, any one of which can break when its maker updates it.

A better builder, using the same AI, slows down at that moment. They ask: do I need a whole outside tool for this, or can I write twenty lines of my own code that does the same job? Most of the time, twenty lines of your own code is the right answer.

This is not a matter of working harder. It is a matter of deciding where to spend the help the AI is giving you. Spend it on writing something specific to your business. Do not spend it on bolting together pieces you will then have to manage forever.

Chapter 03

Why boring tech usually wins for you.

Concrete reasons, in plain terms:

  • Fewer surprises. Boring tools have stopped changing shape every six months. You will not wake up to an email telling you your software stopped working because a tool updated itself.
  • More people can fix it. If your original builder moves on, a replacement can pick up your project without learning five brand-new tools they have never seen. That labour market matters a lot when you are hiring help.
  • Cheaper to run. Most boring tools are free or cost very little. Shiny tools often have a clever pricing model that gets expensive when your use grows.
  • Harder to break. The more outside pieces a build depends on, the more things can fail. A build with three dependencies is more reliable than a build with fifty.
  • Easier to keep private. Boring tools you can run on your own computer. Many shiny ones require sending your data to their servers to work.
Chapter 04

How to tell which kind your builder is proposing.

You do not need to know the names of any tools. You just need to ask one question and listen carefully to the answer:

A good answer sounds like:

“Three, all of them old and stable. If one of them changed in a way that broke things, I would know about it early, and the fix would be a small update. I have written most of the logic specifically for your business, so it is not going to drift.”

A bad answer sounds like:

“Oh, I do not know exactly, probably twenty or thirty. It is all standard stuff. Everyone uses them. We will deal with breakages as they come up.”

The second answer is not always wrong. For a throwaway prototype it is fine. For software you will run a business on for years, it is an expensive future problem.

Chapter 05

Red flags.

  • Uses a tool that became popular in the last year.

    Sometimes fine, if the builder has a specific reason. Usually a sign they are chasing what is new rather than what will last.

  • Cannot list the outside pieces their build will depend on.

    If they do not know, nobody will when something breaks. This is a bigger warning than it sounds.

  • Every part of the build lives on a different service.

    “This lives here, that lives there, the AI bit lives somewhere else, the data is on another service.” Every service is a place your build can fail. Reduce the count.

  • The word “cutting-edge” shows up in their proposal.

    You do not want cutting-edge. You want the part that is no longer cutting-edge and has the scars of everybody else’s mistakes already worked out.

The short version.

You are not paying for novelty. You are paying for software that still works a year from now, that you can afford, that somebody else can take over if they have to. Boring tech is the easiest way to get all three of those.

When your builder lists the tools, ask how many they are, how old they are, and what happens if one of them changes. Listen to the answer. It tells you almost everything you need to know.