AI adoption without a rewrite
Successful adoption starts with one narrow, measurable feature behind a flag, chosen where errors are cheap and feedback is fast. Keeping the model behind an interface, measuring against a baseline and being willing to remove the feature keeps the risk proportionate to the evidence.
The two common failures are opposite and equally expensive. One is the rewrite — reorganising the product around AI before knowing what it is good for. The other is the demo that never ships, impressive in a meeting and never quite finished.
What works is smaller and duller than either.
Choose where errors are cheap
The first feature should sit where a wrong answer costs one edit, not one incident. Drafting rather than sending. Suggesting a tag rather than applying it. Summarising rather than deciding.
This is not timidity; it is how you learn what the model is reliable at in your domain without paying for the lesson.
Frequency beats impressiveness
A modest improvement to something people do forty times a day teaches you more, and earns more, than a remarkable improvement to something they do monthly. You need feedback volume to know whether it is working.
Ship it behind a flag
With a flag you can enable it for a few accounts, watch real usage, and turn it off in a second if it misbehaves. Without one, every problem becomes a deployment.
And record a baseline before it goes live — how long the task takes now, how often it is done correctly now. Without a before, there is no after, only opinions.
Keep the provider swappable
Put the model behind your own small interface from the first day. Not an abstraction framework — a thin layer of your own that holds the prompt, the call and the parsing.
Models improve and prices change on someone else's schedule. The teams who switch easily are the ones who never scattered provider-specific calls through their codebase.
Be willing to delete it
Some features will not earn their cost. A feature nobody uses still has to be maintained, still consumes budget, still appears in every security review.
Deciding the success criterion before launch — and honouring it — is what keeps a portfolio of AI features healthy instead of accumulating. The ability to remove something is what makes it safe to try it.
Frequently asked questions
What makes a good first feature?
Something narrow, frequent and forgiving: drafting, summarising, tagging, extracting. The user sees the output before it does anything, the value is obvious within a week, and a mistake costs one edit.
Should we build our own infrastructure first?
No. Build the feature with the simplest thing that works and learn what you actually need. Infrastructure built before the first real use case tends to solve problems you turned out not to have.
