When you should not build anything

Ask an AI whether you need AI and it will almost certainly say yes. Ask a software company whether software would help and you will get the same answer. That is not dishonesty; it is what happens when everyone you consult is paid by the outcome they are recommending.

My income comes from five companies that sell networks, camera security, property, software and lead follow-up. This site sells nothing, which is the only thing that makes the following worth reading.

When should you not build anything?

Do not build when volumes are low, when every price is negotiated per customer, or when the process itself is the problem. In the first case you never earn the build back, in the second there is no rule to encode, and in the third you make something faster that should not exist.

Does low volume really rule it out?

Usually, yes. If something happens four times a month, doing it by hand costs less than building, testing and maintaining a system for it, and the maintenance never stops, even in months when the thing does not happen at all. Software is not a one-off purchase. It is a standing obligation.

Count before you decide. People are consistently wrong about their own volumes, in both directions, because memory weights the annoying occurrences. The step everyone complains about turns out to happen twice a quarter, and the one nobody mentions happens forty times a week.

There is one exception worth naming. Low volume plus severe consequences can still justify building: something that happens rarely but costs a great deal when it is missed is a different calculation. That is risk work, not efficiency work, and it should be argued on the risk.

What if every price is negotiated?

Then there is nothing to encode. A configurator, a pricing engine or a model can only reproduce a rule, and if the number comes out of a conversation about this customer, this month, that volume, the rule does not exist. Whatever you build will be confidently wrong, which is worse than slow.

The tell is easy to hear. Ask what the price would be for a specific situation and listen for “it depends”. If the depends-on list is short and factual — surface area, distance, number of rooms — you have a rule and you can build. If it is “depends on who it is and how the last job went”, you have a relationship, and automating it removes the part that was working.

Half-measures fail here too. Publishing a price range so that the negotiation still happens sounds like a compromise, but it anchors every conversation to the lower end and you have given away your position for nothing.

What if the process itself is the problem?

Then you are about to build a faster version of something that should not exist. This is the most expensive of the three because it looks like a success: the tool works, people use it, the numbers improve, and the underlying nonsense is now permanent and has a maintenance contract attached.

The diagnostic question is where a step came from. Ask why a form is checked twice and you will often be told that someone made a mistake years ago, or that two departments do not trust each other’s data. Automating that check makes the distrust cheaper to maintain. Removing one of the two systems fixes it.

Getting this wrong has a compounding cost that nobody puts in a business case. The organisation concludes that the improvement has been made, the subject is closed for a few years, and the person who suggested it has spent their credibility. The next honest proposal from that person now sounds like sales.

Why does everyone else say yes?

Because their revenue depends on it, and because saying yes is more pleasant. A supplier who tells you your process is the problem is criticising the person paying them, in front of the people who designed it. A model asked whether AI could help is trained on a world that mostly writes about the cases where it did.

This is why a dated, signed no is worth more than another yes. Not because negativity is wisdom, but because the yes was always going to be available and costs the person giving it nothing.

I do build things, often. There is a case where building was worth it and one where the customer does the work instead. The ratio just runs the other way from what the industry implies.

How do you tell a bad process from a slow one?

A slow process produces the right result too late. A bad process produces a result that has to be corrected, checked twice, or argued about afterwards. Speed problems are worth building for. Correctness problems usually mean information is missing at the start, and no amount of tooling adds information that was never captured.

There is a simple test that costs one morning. Follow one item all the way through — one order, one enquiry, one file — and write down each moment where somebody has to ask a colleague something. Every one of those questions is information that arrived too late or in the wrong place. If the list is long, you have a design problem, not a throughput problem.

Is it ever right to build something small anyway?

Yes, when the goal is to learn something you cannot learn any other way. A small build that answers a real question is cheap and honest: will people actually use this, does the data hold up? The condition is that you decide in advance what result would make you stop, and that stopping is genuinely allowed.

Without that condition it is not an experiment, it is a start. Almost every oversized system I have been asked to rescue began as something small that nobody was ever permitted to switch off.

What does a no actually cost?

It costs the fee, the enthusiasm in the room, and sometimes the client. What it buys is the only thing that matters over years: when you later say something is worth building, people believe you. That is not a moral position. It is the cheapest form of marketing I have found, and it works precisely because it is occasionally expensive.

It is also, by a distance, the hardest skill in this job — harder than any part of the technology, and the reason the roles are advertised at senior level. If you want the day-to-day picture rather than the argument, that is what the work actually involves.

Marc Herdes, Almere, 4 September 2026. Running companies since 1999; this page sells nothing.