Build for the work. Then choose the technology.

Begin where the friction is

A founder can spend weeks comparing models without speaking to the person who will use the result. A more useful starting point is to observe a task: where information arrives, where decisions stall and where people repair mistakes. The opportunity often appears in those handoffs.

Take a routine enquiry that passes between a customer, an operator and a specialist. Each person may use different language to describe the same problem. Information gets copied, context gets lost and somebody has to ask a question that has already been answered. The visible task is answering an email. The underlying problem may be maintaining context across a sequence of decisions.

Describe the outcome before the interface

A good problem statement says who needs something, under what conditions and why the existing process falls short. It leaves room for more than one solution. A conversational interface might help, but so might a clearer intake form, a shared record or a change in responsibility.

This matters when building with AI because the range of possible interfaces can distract from the outcome. A compelling prototype is valuable as a way to learn. It does not establish that a customer will understand the tool, trust it or return to it when ordinary work becomes difficult.

Before choosing a model, collect a small set of real tasks with permission from the people involved. Remove information that the trial does not need. Include awkward cases, missing context and requests that should be declined. Write down what a useful result would look like for each case.

Build the smallest useful loop

The first version should complete a meaningful loop: information enters, a result is proposed, somebody checks it and the outcome is recorded. A disconnected generation step may look impressive while teaching little about whether the work has improved.

Make it easy for the person using the prototype to reject a suggestion and explain why. Keep the original information available. Where a result leads to an external action, such as a customer promise or a changed record, make the point of responsibility clear. The amount of review should reflect the consequence of the action.

Let the work challenge the idea

A useful trial can end with a decision not to continue. Perhaps the task is too rare, the source information is unreliable or an ordinary software change solves the problem more simply. Those findings improve the builder’s understanding of the business.

The stronger opportunity is the one that survives contact with everyday work. It has a recognisable user, a meaningful outcome and evidence that the new process helps. Choosing technology becomes easier once those things are clear, because the choice is serving a purpose rather than supplying one.