Most AI features fail for the same two reasons: nobody defined the job the model is doing, and nobody designed what happens when it is wrong. I frame the task, build a prototype that runs against a real model within days, and test it with real people on real work — so the decision to ship rests on behaviour, not on a demo.
“It demos beautifully. In real use, people stop trusting it.”
A model that is right most of the time is a design problem, not an engineering one. The work is deciding which task it takes on, showing people how sure it is, and making the correction cheaper than the mistake. That gets designed, tested and evidenced — not prompted.
AI made building cheap, which makes deciding the expensive part. Three steps, usually four to six weeks, and at the end you know whether it holds.
Name the task the model takes on, the person it serves and what a wrong answer costs. Features without that definition are the ones quietly switched off six months after launch.
Build it running against a real model within days, not as a clickable picture. You see the latency, the empty states and the wrong answers while changing them is still cheap.
Design the wrong answer: disclosure, correction, fallback, review. Then test with real people on their own work and decide on what they did, not on what they said.
We start with the task, not the technology. Which decision or piece of work is the model taking over, for whom, how often, and what does it cost when it gets it wrong? Then the fit gets checked: is there data, is the output checkable, and is a model actually better here than a rule, a search field or a shorter form? Half the candidates drop out at this stage — which is the cheapest place to lose them.
Then it gets built for real: a working prototype wired to an actual model and actual data, inside days. Not a picture of an answer, but the answer the model gives — with its latency, its empty states and its confident nonsense. That is the only version worth testing, because behaviour is what people react to, and no static screen can show it.
Last comes the part most teams skip: designing for being wrong. How sure is the model, and does the interface say so? Can someone correct it in one step? What happens when it has nothing, or when it is unavailable? Who reviews the cases that matter? Then five people do their own work with it, and the recommendation comes out of what they did.
Not a proof of concept that impresses a steering committee and then stalls. A defined task, a prototype that runs, and recorded evidence of real people using it: enough to build on, or enough to stop.
Project, four to six weeks
This is for teams where AI is already on the roadmap — and the question has moved from whether to where, and at what risk.
Three workshops in, the list still holds features rather than tasks, and every estimate depends on which one you pick.
You get a framed use case with criteria you can decide against.
Investors and first customers react to behaviour. A deck describing the model is the one thing that cannot be evaluated.
You get a running prototype in days, and sessions that show it holds.
It performs in the demo, and nobody can say what happens when it is wrong — so it stays a pilot.
You get designed failure paths and evidence that satisfies review.
That the model is part of how the product works, not a panel bolted onto the side. The interface has to handle output that is probabilistic: sometimes right, sometimes nearly right, occasionally confidently wrong. Designing for that — confidence, correction, fallback — is what separates an AI-native product from a product with a chat window.
No, and using it that way is how teams end up confidently wrong. A model summarises twenty interviews faster than I can and will invent a theme nobody mentioned. I use it for transcription, clustering and first passes; the evidence still comes from real people doing real tasks, and the judgment stays with a person who can be held to it.
A working prototype against a real model usually takes days rather than weeks, because building is no longer the slow part. Framing the task properly and testing it with real people is what the four to six weeks are for.
I design with them in mind rather than around them: what data the model sees, what is logged, whether output is labelled as machine-generated, and whether a person can contest it. The legal classification of a specific system needs counsel — my part is making sure the design does not make that answer harder.
Then that is the result, and a cheap one. A search field, a rule or a shorter form beats a model more often than the current market suggests. Finding that out in week two is worth considerably more than discovering it after a year of maintenance.
A free 30-minute call. No pitch, no pressure — just an honest look at the task you have in mind and whether a model is the right thing to put on it.