Three questions before you put AI in your product
This is the framework I use on every AI decision review. Three questions, in order. If an AI feature survives all three, it earns its place in your product. Most don’t, and knowing that before you build is the cheapest engineering you’ll ever buy.
What does each AI interaction cost at scale, and does your pricing survive your own success?
A feature that costs pennies in the demo can bleed a margin dry at ten thousand users, because the cost ships with every use. I model the per-interaction cost against each pricing tier before anything gets built. In the edtech product on my home page, that math is why AI powers only the features whose tier covers their cost, and stays out of the rest.
Could a simpler system deliver 90% of the value at 10% of the cost?
Most “AI features” compete with a lookup table, a rules engine, or a decent search index. If the simple version gets you most of the way, ship it first and let real usage argue for the upgrade. In the edtech case, we deferred retrieval infrastructure, not because we couldn’t build it, but because the numbers said “not yet.”
What do you actually lose by waiting six months, and what do you lose by not waiting?
Waiting has a price. Sometimes it’s real (a competitor compounding on data you don’t have), and often it’s imaginary, because the thing you’d build today gets cheaper and better while you wait. I make both costs explicit, with numbers, so the decision is a trade instead of a fear response. Deferring is a decision with a review date, not a rejection.
Put the three questions to work
One week, fixed scope. You get a written decision memo you can act on, with or without me.