From building AI to deciding on AI

A year ago, first conversations often started with a build request. Can you make a chatbot? Can you make our documents searchable? Can you automate this workflow?

That work still exists. It is less often the real problem.

Last month I showed a client a standard tool that costs €20 per month. A week later, one user was saving six hours a week with it. What would have felt like a €10,000 custom project twelve months earlier now sat inside a subscription any employee could open.

That is not bad news. It changes the craft.

Building is less scarce

The tools are better, faster, and cheaper. ChatGPT, Claude, Copilot, and vertical tools now solve more standard work than they did two years ago. A good prompt inside an existing product sometimes beats a €15,000 bespoke application.

The complexity has not disappeared. It moved.

Building takes weeks. Deciding which problem to take on, how it fits the existing workflow, who owns it, and how you measure whether it works is at least half the work.

The centre of gravity shifts. Not from building to talking. From building to choosing better.

The question changes

The first question is less often: can you make this?

The better question is: should this be made?

After that come the questions that decide whether a system survives:

• Where is the most manual time?
• Who uses this every week?
• Which data may the system see, and which data is off limits?
• Who maintains it after the first release?
• What is good enough to measure after four weeks?

A tool without those answers quickly becomes a demo. It can work in a screen recording and still disappear from the workflow.

Most companies do not have a tool problem

Many teams think they have a tool problem. They have a decision problem.

Which problem is large enough? Which use case is small enough? Who inside the organisation can carry it? What should you avoid building?

Those questions come before implementation. They decide whether, a year from now, you look back on a system people use daily or a pilot nobody owns anymore.

The best start is narrow. One workflow. One team. One owner. Build for no more than four weeks. Then measure and decide whether to continue.

Advice without a production path is too light

Only advising is easy. Only building is easy too. The hard part sits between the two: make a sharp choice and carry that choice through to a system that runs under real users.

That is why this is no longer pure implementation work. It is decision work with build responsibility.

You say no to a request that is framed badly. You build when the choice holds. And you hand over before the system depends on the builder.