Where AI actually earns its keep in a software project
Most products don't need an AI feature bolted onto the homepage. They need two or three specific steps done automatically. Here's how we tell the difference.
Every few months a client comes to us wanting "AI in the product" without a specific job for it to do. That's usually the wrong starting point. The products where AI actually sticks — where it keeps getting used six months after launch, not just at the demo — all start from the same place: a specific, repeated, slightly annoying step in someone's workflow.
Start from the task, not the technology
Before we write a line of model-calling code, we ask what a person is doing today that this would replace. Reading fifty support tickets and tagging them by urgency. Reading a contract and pulling out the renewal date. Answering the same five questions about a product over and over. If you can describe the task in one sentence and point to the person currently doing it by hand, you have a real AI feature. If the answer is "make the app smarter," you don't yet.
This matters because it changes how you build. A task-shaped feature has a clear success measure — did the ticket get the right tag, did the renewal date come out correct — which means you can actually test it, catch when it's wrong, and improve it. A vague "smarter app" feature has no such measure, so nobody notices when it's quietly getting things wrong.
The boring parts matter more than the model
The choice of model is rarely the hard part anymore. The hard part is everything around it: what happens when the model is wrong, how a person reviews or overrides its output, what you log so you can debug a bad answer three weeks later, and what it costs to run at your actual volume, not a demo's volume. We spend more engineering time on the fallback path — what the user sees when the AI step fails or isn't confident — than on prompt design.
- A human-reviewable output, not a black box the team has to trust blindly
- A clear fallback when the model is wrong or unavailable
- Logging good enough to debug a specific bad answer after the fact
- A cost model that holds up at real usage, not demo usage
What we tell clients who aren't sure yet
If you're not sure whether a feature is a good AI candidate, write down the task in one sentence, find the person doing it today, and ask how often they get it wrong. If they get it wrong rarely, automating it well is hard and the payoff is small. If they get it wrong often because it's repetitive and they're tired by ticket forty, that's exactly the kind of task where a focused AI step — reviewed by a human, not replacing one — earns its keep fast.
More from the blog
Have a project in mind?
Tell us about your project and we'll get back to you within one business day.
