AI product features
Most AI features fail for the same reason: the model was the starting point rather than the problem. The first useful thing I'll do is tell you whether your feature needs a model at all. Often it doesn't, and that's a cheaper answer than building it and finding out.
Who it's for
- Products where a model could remove real user effort
- Teams who have tried an AI feature and found nobody uses it
- Founders who need the AI story to be real rather than decorative
What you get
- A short assessment of whether the feature warrants a model
- Interaction design for the feature, including the failure states
- Server-side implementation with the key never exposed to the browser
- Rate limiting, spend caps and abuse protection
- Evaluation approach so you can tell whether it's getting better or worse
How it runs
- 1
Decide whether it needs a model
Rules, search or a better default often beat a model. This step is short and sometimes ends the project, which is a good outcome.
- 2
Design for being wrong
The design problem in AI features is what happens when the output is bad. That gets designed first, not last.
- 3
Build it server-side
Keys stay on the server. Rate limits, turn caps and spend caps go in from the first commit, not after the first bill.
- 4
Measure it
A way to judge output quality that isn't vibes, so the feature can be improved deliberately.
Questions
Anthropic and OpenAI APIs mostly. The choice follows the task rather than the brand.