Adding AI Features (Claude/GPT) to Your Product: a Practical Guide

I build web apps and AI features solo, no agency layer in between. Across three years and 20-plus shipped projects one pattern keeps repeating. An owner reads about GPT-4 or Claude, decides the product needs «AI,» and asks for a chat window in the corner. Nine times out of ten 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 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. That’s a support-load feature, not a novelty.
• 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 face-photo into a score. 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 just an if-statement. If you can’t name the chore it removes, it’s decoration.

Which AI feature is worth building?

AI feature	Worth it when	Skip it when	Typical model
RAG assistant (answers from your docs)	You have 20+ pages of real content and repeated support questions	Docs are thin or change hourly; a good search bar already works	Sonnet (grounded answers) + embeddings
Voice into structured data	Input is tedious to type and has a clear schema (tasks, notes, orders)	Input is one short field; typing is already fast	Whisper (transcribe) + Haiku (structure)
Vision / image reading	Users would otherwise transcribe from a photo by hand	You don’t control image quality and errors are costly	Sonnet or GPT-4 vision
Classification / routing / tagging	High volume, clear categories, humans currently sort it	Volume is tiny; a rules table is cheaper and auditable	Haiku
Generic «ask me anything» chat	Almost never, unless it’s grounded (then it’s RAG)	It’s ungrounded and just there because «AI is cool»	—

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. AI output that nobody can verify is a liability, not a feature.
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.

This is also the honest advantage of working with a solo builder over an agency. 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 segments, deduplicates, and surfaces the first small step to start on. No manual typing.

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.

Model tier	Best for	Speed	Relative cost
Claude Haiku (small)	Classification, extraction, voice→structure, routing, tagging — anything with a tight schema	Fastest	Lowest
Claude Sonnet (mid)	Grounded RAG answers, reasoning over docs, vision, nuanced writing	Fast	Mid
Top-tier (Opus / GPT-4-class)	Hard multi-step reasoning, agents, code — rarely needed for a product feature	Slower	Highest

My rule of thumb: if the task has a fixed output schema, start with Haiku. Extraction, classification, structuring. Small models are shockingly good at these and 10-20x cheaper 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 honestly, whichever SDK you’ll debug faster. Don’t agonize over it. The tier decision saves you 10x more money 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 chatty feature this alone cuts input cost hard.
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 is often a better answer, not just a cheaper one.
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.

How adding AI features connects to shipping metrics

The reason I open with «which chore» is that a well-scoped AI feature moves the same numbers a good UX change does. When I migrated Club 365, the subscription yoga school, from Tilda to WordPress, conversion rose 46%. Not because of a clever animation, but because friction came out of the path to purchase. AI features earn their place the same way, 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 moves 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 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 can run for cents per active 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 hallucination stops being a risk to your brand.

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 typically days to a couple of weeks, not months, 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. 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.