What I Actually Build When a Client Says "Add AI to the Product"

"Add AI to the product" is the brief I get most often now, and it is almost never one feature. Underneath it is usually one of four different jobs: a chat or search box that streams an answer instead of showing a spinner, a design-to-code step that drafts a component from Figma instead of from scratch, an internal tool that reads something messy (a screenshot, a PDF, a spreadsheet) instead of forcing someone to retype it, or a genuine multimodal feature where the input isn’t text at all. Naming which one it actually is decides the whole build.

I’d rather spend the first call sorting the brief into these four than start with a model comparison spreadsheet. The model is rarely the hard part. The plumbing around it - state while tokens stream in, a Figma file an agent can actually parse, a queue for the screenshots an internal bot has to process - is where the weeks go.

1. Streaming UI with the Vercel AI SDK

A chat box that answers all at once, after a five-second wait, feels broken even when the model is fast - people read the first sentence while it’s still typing, not after. The Vercel AI SDK’s useChat and useCompletion hooks handle the token stream, but the part clients actually judge is what happens around it: a stop button that really cancels the request, a regenerate that doesn’t duplicate the last message, and a UI that doesn’t jump when a code block or a table streams in mid-sentence.

The failure mode I see most in existing builds isn’t the streaming itself - it’s state. A React component that re-renders the whole message list on every token, a loading flag that never resets after an aborted request, an input that stays disabled after an error. None of that shows up in a demo with one happy-path message; all of it shows up after a user’s tenth message of the day.

2. Figma-to-Code via MCP, and where the human still has to look

An MCP server that exposes a Figma file lets Cursor or Claude read the actual layout - frame names, spacing tokens, component variants - instead of guessing from a screenshot. That gets a first draft of a component to a reasonable state fast: correct structure, roughly correct spacing, real class names instead of placeholders.

It does not get responsive breakpoints, accessibility, or the states a designer never drew - hover, disabled, empty, loading - right without a person checking. I treat the MCP output as a fast first draft, not a merge-ready PR: the time it saves is in typing out the boilerplate, not in the review.

3. AI-powered internal tools and where multimodal actually pays off

The AI feature with the best ROI I build is rarely customer-facing. An internal tool that reads a supplier’s PDF invoice and fills the fields a bookkeeper used to retype, or one that looks at a screenshot of a bug report and drafts the ticket - lower stakes than a public chatbot, higher volume than most people expect, and nobody minds a rough edge because it’s saving their own time.

That’s also where multimodal AI - a model reading an image or a PDF instead of only text - earns its cost. Adding image input to a customer-facing feature "because it’s possible" is usually not worth the added failure surface. Adding it to a form an employee fills out forty times a day, replacing a document they’d otherwise retype, pays for itself in the first month.

Conclusion: name the feature before you name the model

"Add AI to the product" only turns into a plan once it is one of these: a chat that streams properly, a design step that drafts instead of replacing a developer, an internal tool automating a specific retyping job, or a real multimodal input. I build all four, wired with the Vercel AI SDK, MCP, and whichever model fits the job rather than whichever is loudest that month. Write through the form with what the AI is actually supposed to read or say, and I’ll tell you which of these four it is.