Adding AI Features to Your Product with Claude or GPT

I build web apps and AI features solo, no agency layer in between. Across 40+ projects one pattern keeps repeating. An owner reads about the latest AI models, decides the product needs «AI,» and asks for a chat window in the corner. Often that chat window is the wrong feature. It’s the most visible AI thing, so it’s the first thing people reach for, and it’s usually the one that moves no metric at all.

This guide is about the other side of that. When you’re adding AI features to your product, the real question isn’t «how do we bolt on a model.» It’s «which chore is expensive enough, boring enough, or slow enough that an AI call earns its token cost.» I’ll walk through the features that actually move numbers, how to scope one, how to choose between models like Claude Haiku and Sonnet, what tokens really cost, and the traps that eat budgets.

Which AI features actually move metrics (and which are hype)?

Three shapes of AI feature reliably earn their keep. They share a trait: each removes a step a human currently does by hand.

• RAG assistant (a chat that looks up the answer in your own documents first) answers from your content instead of guessing. Support docs, a knowledge base, product manuals. The value is cutting «where is that in the docs» down to one question. I built one on pgvector plus Claude Sonnet: visitor questions run a retrieval over indexed docs, the model answers grounded in the matched chunks, and it cites the source. When a chat goes quiet it can hand the transcript to a human over Telegram. It takes the repeat questions off your team.
• Voice into structure turns a messy spoken brain-dump into clean data. This is the one people underrate. Talking is fast. Typing structured input is slow and annoying.
• Vision, or read-a-photo, lets the user point a camera and the product extract meaning: a receipt into line items, a room into a furniture list, a selfie into an outfit score (my app Roast My Style does this). Vision removes the «type it all in» step entirely.

The hype features tend to be the generic chat bubble («ask me anything» with no grounding, which hallucinates and erodes trust), the summarize-everything button nobody clicks, and «AI-powered» slapped on a filter that was always a simple rule. If you can’t name the chore it removes, it’s decoration.

Which AI feature is worth building?

How do I scope one AI feature before building it?

Scoping is where budgets are saved. Before I write a line of integration code, I answer five questions in writing. If any answer comes out fuzzy, the feature isn’t ready to build.

1. What chore does it kill? Name the exact manual step. «User types 12 tasks by hand every morning» is a chore. «Make it smarter» is not.
2. What’s the input and the output schema? Voice in, JSON tasks out. Photo in, line-items out. If you can’t draw the output shape, the model can’t hit it.
3. How do you check the answer is good? A grounded citation, a confidence score, a human confirm-step. If nobody can check the AI's answer, it's a liability.
4. What happens when it’s wrong? It will be wrong sometimes. Does the user get a cheap undo, a fallback path, a human handoff? Design the failure before the success.
5. What’s the cost ceiling per action? Multiply tokens per call by expected daily calls. If a single voice command would cost more than the feature earns, stop here.

Working with one developer helps here. I do the scoping and the code, so the «which chore, which schema, which failure path» conversation happens once, with the person actually writing the prompt. If you’re weighing that tradeoff, I broke it down in hiring a solo full-stack and AI developer vs an agency.

Voice into tasks: a real example (Lunelo on Claude Haiku)

The cleanest example of «AI removes a real chore» in my own work is Lunelo, my AI day planner built on Claude Haiku. The chore it kills: nobody wants to type out their whole day as separate structured tasks. So Lunelo lets you talk. You dictate a stream of thought («I need to call the dentist, finish the deck by Thursday, and buy groceries») and Claude Haiku breaks it into concrete task cards with subtask, priority, category, and deadline. It splits the list, removes duplicates and shows the first small step to start on.

The pipeline runs in two stages, and the model choice matters at each one. Whisper on web, or native iOS recognition, handles transcription: voice to raw text. Then Haiku does the structuring: text to a clean JSON array of tasks. I deliberately did not reach for the biggest model here. Task-splitting is a well-scoped transform with a fixed output schema, so Haiku clears the bar at a fraction of the cost and latency. That matters because this runs every single time someone opens the app. It ships as iOS and PWA. I wrote up the build in more depth in how I built the Lunelo AI planner (Russian).

The lesson that transfers to any product: the flashy part is the voice, but the value is the structure. Voice is just the input method that makes structuring worth doing.

Claude Haiku vs Sonnet vs GPT: how do I pick a model?

Default to the cheapest, fastest model and only climb when it actually fails your quality bar. Most owners start at the top of the range because it «sounds safer,» then wonder why the token bill is ugly and responses are slow. Start at the bottom and earn your way up.

My rule of thumb: if the task has a fixed output schema, start with Haiku. Extraction, classification, structuring. Small models handle these well and cost much less than the top tier. Reserve Sonnet for when the model has to reason over content and produce a grounded, cited answer, like a RAG assistant. Reserve the top tier for genuine multi-step reasoning, which almost no consumer product feature actually needs.

Claude vs GPT itself matters less than the tier. Both vendors offer a small, mid, and large ladder. Pick by whichever has the pricing and latency you want, whichever you can get billing sorted on, and whichever SDK you'll debug faster. Don’t agonize over it. The tier decision usually saves you far more than the vendor decision.

What do tokens actually cost, and how do I keep the bill sane?

A token is roughly three-quarters of a word. You pay for input tokens (your prompt plus the user’s message plus any retrieved docs) and output tokens (the model’s reply), and output usually costs more per token. The bill blows up in two predictable ways: stuffing giant prompts into every call, and calling a top-tier model for a job a small model would nail.

Practical controls I put on every AI feature:

1. Cap output length. Set a max-tokens ceiling to what the task needs. A task-splitter doesn’t need room for an essay.
2. Cache the static prompt. Your system prompt and instructions repeat on every call. Prompt caching means you stop paying full price for the same fixed preamble. On a feature with many short calls, caching noticeably lowers the input bill.
3. Retrieve less, not more, for RAG. Feeding 30 document chunks into every question is lazy and expensive. Retrieve the top few relevant chunks. A tighter context often gives a better answer and costs less.
4. Pick the model per call, not per app. Route the cheap, high-volume calls to Haiku and reserve Sonnet for the calls that truly need it. You don’t have to use one model everywhere.
5. Log token usage from day one. Track tokens per feature so you can see which call is eating the budget before the invoice tells you.

Do the arithmetic before you build: tokens per call, times calls per day, times price per token. If a feature runs on every app-open, like Lunelo’s task-splitter, that multiplier is exactly why I put it on Haiku and not the top tier.

What are the common pitfalls when adding AI features?

The two failures I see most: shipping an ungrounded chat bot that confidently makes things up, and picking a model three tiers too big for the job.

• Ungrounded output. A bot that answers from thin air will invent facts about your product. Ground it in your real content and cite the source. That’s the whole point of RAG.
• No failure path. The model will return something wrong or malformed. Validate the output shape, and give the user a confirm-step or an undo. In Lunelo, tasks are cards you can edit before they land. The AI proposes, the human confirms.
• Over-sized model. Paying Opus prices for a Haiku job. Start small, measure, climb only if quality demands it.
• No cost ceiling. Shipping without knowing the per-action cost. One viral day can turn a fun feature into a scary invoice.
• AI for its own sake. If a rules table or a good search bar solves it, use that. AI you can’t justify by a killed chore is maintenance debt with a marketing sticker.

Will an AI feature move my numbers?

The reason I open with «which chore» is that a well-scoped AI feature can move your numbers the way a good design fix does: by removing a step people hate. AI features earn their place by removing friction from a step the user actually cares about. Voice removes typing. RAG removes hunting through docs. Vision removes transcribing from a photo. The metric can move because the chore is gone.

If you have a product and a chore you think an AI call could kill (a support load, a tedious input, a photo people retype by hand) that’s exactly the scoping conversation worth having. You can see how I’ve approached real builds in the case studies, or tell me about the chore on Telegram or WhatsApp and I’ll tell you honestly whether AI is the cheapest way to kill it.

Frequently asked questions

How much does it cost to add an AI feature to my product?

Two costs: build and run. Build is the integration and scoping work, a fixed one-time figure that depends on feature complexity. Run is tokens, usage-based, driven by your call volume and model tier. A well-scoped feature on a small model like Haiku usually costs little to run per user. The trap is running costs, so I estimate tokens per action before building and cap them.

Do I need Claude or GPT, and which is better for my product?

The tier matters far more than the vendor. Both Claude and GPT offer small, mid, and large models. For extraction and structuring, a small model (Claude Haiku) wins on cost and speed. For grounded answers over your docs, a mid model (Sonnet) fits. Pick the vendor by pricing, latency, and which billing you can set up, then optimize the tier.

Will an AI feature make things up and embarrass me?

Only if it’s ungrounded. A chat bot answering from thin air will invent facts. A RAG assistant answers only from your indexed content and cites the source, so it stays inside what you actually published. Add a confirm-step or human handoff for anything high-stakes. Design the failure path first and a wrong answer becomes a small, fixable problem.

How long does it take to build one AI feature?

A single well-scoped feature, voice-to-structure, a RAG assistant, or image reading, is usually a few days to a couple of weeks, once scoping is clear. Most of the time goes into the schema, the failure path, and testing edge cases, not the model call itself. Fuzzy scope is what stretches timelines, which is why I insist on answering the five scoping questions before writing code.

Can I add AI to an existing site instead of rebuilding?

Usually yes. A RAG chat widget is one embedded snippet over your existing content. AI assistant for your website → Voice or vision features attach to a specific screen. You rarely need a rebuild. You need a clear place for the feature to live and clean access to the content or input it works on. The bigger question is which chore it kills, not what your current stack is.