AI Features That Actually Ship: A Founder's Guide
Cut through the hype. The AI capabilities worth building into your product today, the ones to skip, and the four questions that separate the two.
Most AI features die somewhere between the demo and production. The demo is genuinely impressive. Six weeks later it is behind a feature flag nobody has turned on, because it is slow, or wrong often enough to be untrustworthy, or nobody could work out what it was for.
That failure is almost never technical. It is that the project started from the technology rather than from a decision somebody needed to make faster or better.
Here is the filter we apply before writing any code.
The four questions
1. What decision does this make faster?
Not "what could AI do here" — what does a specific person currently spend time on that this removes? If you cannot name the person and the task, you are building a feature in search of a user.
Good answers sound like: support agents spend forty minutes a day summarising tickets before handover. Bad answers sound like: we should have AI in the product.
2. Does the data exist, and is it any good?
Every AI project is a data project wearing a costume. If the documents are scattered across three systems, half of them out of date, that is the actual work — and it is worth doing whether or not the AI feature ever ships.
3. What happens when it is wrong?
Not if. These systems are wrong sometimes, and a feature designed on the assumption that they are not will fail in public.
The useful question is what the wrong answer costs. Suggesting a slightly odd tag on a support ticket costs nothing. Auto-approving a refund costs money. Design for the failure: suggest rather than act, show the source, and keep a human in the loop wherever being wrong is expensive.
4. How will you know it works?
Pick the measure before you build. A number, with a baseline. Otherwise you will ship it, everyone will say it feels clever, and nobody will be able to tell you whether it earned its keep.
What is genuinely worth building right now
These have a good ratio of value to risk, and we have shipped versions of all of them.
Search that understands intent. Traditional keyword search fails when people do not know your vocabulary. Semantic search over your own content fixes that, and it is one of the most reliable wins available — it either returns better results or it does not, and you can measure which.
Summarising long things. Support threads, documents, call transcripts, meeting notes. Low risk because a human reads the summary immediately and would notice if it were nonsense.
Extracting structure from mess. Pulling fields out of invoices, CVs, emails, forms. Enormously valuable, easy to validate, and it replaces work everybody hates.
Drafting, never sending. First-draft replies, product descriptions, listing copy. The person stays in control, so a mediocre draft costs seconds rather than credibility.
Classification and routing. Tagging tickets, prioritising leads, flagging anomalies. Easy to measure against what your team already does by hand.
What to skip for now
A general chatbot on your marketing site. Almost always a worse experience than clear navigation and a contact form that works. If people cannot find your pricing, fix the page.
Anything that acts without review where being wrong costs money, trust or compliance.
Custom model training, unless you have exhausted prompting and retrieval and can point at the specific gap. It is a large commitment and it is rarely the bottleneck.
"AI-powered" as a feature. Users do not want AI. They want the thing done. The best implementations are the ones nobody notices.
The honest counsel
Sometimes the right answer is a database query and a rules engine you can read. That is a real recommendation, not a cop-out — a rules engine is cheaper to run, easier to debug, and does not surprise you at three in the morning.
We say this to clients regularly, and it costs us work. It also means that when we do say a project needs a model, that is worth something.
How to start, if you are starting
Pick the smallest useful thing. One task, one measurable outcome, four weeks, behind a flag, in front of ten real users.
Instrument it properly: log every input and output, cost per call, latency, and whether the user accepted the result. Then look at the numbers honestly. Half the time the answer is "this is not worth it", and finding that out in four weeks is a success, not a failure.
If you want a second opinion on whether your AI idea is worth building — including the version where we tell you it is not — describe what you are trying to do.