Hardik Agravat
Barely a client conversation goes by right now without someone asking whether they should add an AI feature to their product. It's rarely framed as a specific problem to solve — it's framed as a fear of being left behind. Our job in that conversation is usually to slow things down and find the actual problem before recommending a solution, AI or otherwise.
The question we ask before anything else
The first question is simple: what specific, recurring task is currently slow, expensive, or error-prone enough that solving it would clearly move a business metric? If the honest answer is “nothing specific, we just want to have an AI feature,” that's a strong signal to wait. AI features built to check a marketing box tend to be underused by real customers and expensive to maintain, and they rarely justify themselves once the initial novelty wears off.
Where the case gets real is when there's a genuinely repetitive, pattern-based task currently costing real time or money — sorting and prioritizing support tickets, extracting structured data from unstructured documents, generating a first-draft summary of a long document a human then reviews. Those are tasks where AI's specific strength — finding patterns in messy, high-volume data — maps directly onto a real cost center, and where even an imperfect AI-assisted first pass genuinely saves time downstream.
What we check before building it
Data availability is the next filter, and it's the one that kills more AI feature ideas than anything else. A useful AI feature needs a reasonable volume of relevant, reasonably clean historical data to work from — a support ticket categorization feature needs a real archive of past tickets and how they were actually categorized. A client with a great idea but no historical data to build on is looking at a much longer, more expensive project than they expect, often starting with months of manual data collection before the AI feature can even be trained meaningfully.
We also push clients to think through the failure case upfront, not after launch. What happens when the AI feature gets it wrong — and it will, some percentage of the time, for any real-world feature? A recommendation engine that's occasionally off is low-stakes. An AI feature making decisions about a customer's account status or eligibility needs a human review step built in from day one, not bolted on after the first embarrassing mistake goes public.
Where this usually lands
More often than not, this conversation ends with the client either scoping a much smaller, more specific AI feature than they originally imagined, or deciding a well-designed rules-based system solves their actual problem just as well without the added complexity and ongoing cost of a machine learning model. Both are good outcomes. The bad outcome is building an AI feature because it felt necessary, discovering six months later that a simpler tool would have done the job, and having spent the budget that could have solved the actual problem in the meantime.
