Opinion 30 June 2026

What we would tell you not to build

We turn down work most months. Not out of principle, but because some projects have a predictable ending and it is cheaper to say so before the invoice than after it.

Hugo Cardellach 4 min read

Saying no is part of the job

A consultant who agrees with everything is a supplier taking orders. We are hired for the opinion, so here are the six we give most often.

Every one of these has been requested by a company that could afford it. That is exactly why the advice matters.

1. The custom platform to replace five tools

It starts as a frustration with integration and ends as a software company you did not mean to found. Somebody has to maintain it in 2029, and that somebody is you.

The cheaper version is a thin layer that moves data between the tools you have, plus deleting the one nobody actually uses. We have never seen the bespoke rebuild beat that on a three year view.

2. The dashboard with 40 metrics

Executive dashboards fail because they answer questions nobody asked. Forty numbers with no decision attached is a wall, not a report.

Build the version with four numbers and a threshold. Something arrives in your inbox at 07:00 only when a number crosses a line. That gets read for years.

If a report does not change what somebody does that day, it is not a report. It is a habit.

3. The chatbot on a quiet website

A chat widget on a site with 200 monthly visitors will handle perhaps six conversations, two of them from suppliers. The build cost never comes back.

Volume is what makes conversational systems pay. Under a few hundred real enquiries a month, spend the money on answering the enquiries you already get faster.

4. Automating a process nobody has agreed on

Two people do it two ways, both are convinced theirs is correct, and the automation quietly picks a winner. Now you have a system enforcing a decision that was never made.

Spend the week on the process instead. Sometimes the answer is a better process and no software, which is a legitimate outcome even though nobody can invoice much for it.

5. The six month build with nothing live

Long projects are not more thorough. They just delay the moment you find out what was wrong with the plan.

Four to five weeks from the first conversation to something in production is a normal shape for us. There are one week systems, and there are three month ones. What we will not do is spend half a year building against assumptions nobody has tested in the business.

6. AI where a rule would do

Putting a language model on a task with fixed rules costs money per execution and adds uncertainty you did not have before. It also breaks in ways that are annoying to explain to a client.

Models belong on judgement: reading unstructured text, drafting in your voice, summarising. Everything else runs better as plain logic.

The pattern behind all six

Each one is a solution shopping for a problem, and they share a symptom. Nobody can say which number moves.

4Questions before we build
2 daysFrom audit to written plan
5 wksTo the first system live
1Owner named inside the company

Before anything gets built we answer four things in writing.

  1. What number moves, and what is it today?
  2. Which tool is the person already working in when this happens?
  3. What happens when it goes wrong, and who sees that?
  4. Who owns this in six months, by name?

If the four answers do not exist, no amount of engineering will rescue the project.

What we say yes to

Work with a measurable number, a named owner and a live date inside about five weeks. Systems that live inside tools your team already opens. Anything where a small change to how money arrives is worth more than a large change to how work is filed.

That list is shorter than our capability, deliberately. Turning down the wrong project is the cheapest advice we give, and it is the reason clients come back with the right one.

7. The integration nobody asked for

Two tools connected because it felt untidy that they were not. Nobody was retyping anything, and no decision was waiting on it.

Every integration is one more thing that can break at 03:00. Build the ones that remove human work, not the ones that make an architecture diagram look finished.

How to test your own idea

Describe the project in one sentence to somebody in your company who does the work, without naming a tool. Then watch their face.

A practical question about their week means it is real. Sounds interesting means it belongs on this list.

What happens when a client insists

We write the objection down, price the work honestly, then build it properly. Clients are adults, and sometimes they know something about their business that we do not.

Twice last year a client was right and we were wrong. Both times the reason was the same: something about how their customers behave that never showed up in a process map.

What we will not do is pretend we agreed. That written note costs nothing, and it turns the review six months later into a conversation rather than an argument.

What to do with this

Five things you can do tomorrow.

  1. Take your biggest planned project and answer the four questions in writing. Notice which one is hard.
  2. Cut your dashboard to four numbers with a threshold on each.
  3. For any process two people do differently, hold a 30 minute meeting before you build anything.
  4. Set a live date five weeks out. If the plan cannot survive that, the scope is the problem.
  5. Ask your supplier what they would tell you not to build. The answer tells you a lot.
AI & Operations Audit

Want this done on your company, with your numbers?

The audit is $150, and it comes off your first service in full. You get a written plan in two working days: the processes that cost you, ranked by return, with a KPI on each one.