Adding AI to an existing web app is usually an integration, not a rebuild. Pick one clear task, connect Claude or OpenAI through the backend, add a controlled UI, log outputs, and manage API cost. Most first AI features should start small and prove value quickly, then grow only once the value is real.
I work as an AI integration engineer, and most of the requests I get are exactly this: a product already exists, it works, and the owner wants one smart feature added without tearing anything down. The good news is that you rarely need to. Below is the way I actually approach it.
Why it is integration, not a rebuild
When people think about AI, they often imagine starting over. That instinct is wrong for most existing apps. Your database, auth, billing, and UI are assets. An AI feature is a new capability that sits on top of what you already have, usually as one or two new backend endpoints and a small piece of UI.
The model itself lives somewhere else. You are calling an API — Claude or OpenAI — and getting text or structured data back. That means the integration surface is small and well understood: a request out, a response in, and your own logic deciding what to do with it. You do not change your stack to add AI. You add a thin layer to your stack.
This framing matters because it keeps scope honest. If someone tells you that adding AI requires rewriting your backend or migrating your database, be sceptical. The first version of an AI feature should touch as little of your existing code as possible.
Pick one task
The single biggest reason AI projects stall is that they try to do everything. "Add AI to the app" is not a task. "Draft a first-pass reply to a support message" is a task. "Summarise this document into five bullet points" is a task. "Extract the make, model, and year from a messy listing title" is a task.
Choose one job that is:
- Narrow — a single input produces a single, checkable output.
- Tolerant of imperfection — a human reviews or can correct the result, at least at first.
- Genuinely useful — it removes real work, not just a demo.
I push hard on this with every client. One task, shipped and used, teaches you more than five half-built ideas. It also gives you a clean way to measure whether the feature is worth keeping. If the first task does not earn its place, you have spent days, not months, finding that out.
Wiring Claude or OpenAI on the backend
The API call belongs on your server, never in the browser. Two reasons: your API key must stay secret, and you want a place to enforce limits, validate input, and log what happened. The shape is the same regardless of framework — your backend receives a request from your UI, builds a prompt, calls the model, and returns a cleaned result.
A minimal server-side call looks like this:
// Runs on your server only — the API key never reaches the browser.
const res = await fetch('https://api.anthropic.com/v1/messages', {
method: 'POST',
headers: {
'x-api-key': process.env.ANTHROPIC_API_KEY,
'anthropic-version': '2023-06-01',
'content-type': 'application/json',
},
body: JSON.stringify({
model: 'claude-sonnet-4-5',
max_tokens: 400,
messages: [{ role: 'user', content: userPrompt }],
}),
})
const data = await res.json()
const output = data.content?.[0]?.text ?? ''
A few things I always do at this layer. I keep the model name and limits in config, not scattered through the code, so swapping models or capping length is a one-line change. I set a sensible max_tokens so a single call cannot run away. And when I need structured data rather than prose, I ask the model to return JSON and then parse and validate it before trusting it — never assume the output is well-formed.
I deliberately keep these examples generic. Whatever your framework, the integration shape is the same: one server endpoint that owns the model call and hands back something your UI can use safely.
The UI layer
The interface should make the AI feel like a helpful suggestion, not an unaccountable decision. The pattern I reach for most is draft, then confirm. The model produces a draft — a reply, a summary, a set of tags — and the user accepts, edits, or rejects it. Nothing the model produces goes live without a human step, at least in the first version.
Practically, that means a few small things in the UI: a clear loading state, because model calls take a second or two; a way to show the output as editable rather than final; and graceful handling when a call fails or returns nothing useful. AI calls fail more often than a normal database query, so the UI has to treat an empty or errored response as a normal path, not an exception.
I also make the AI part visually distinct and labelled. People trust a feature more when they know which parts are generated and can see exactly where their own control begins.
Logging, guardrails, and cost control
This is the part that separates a demo from something you can run in production. Three concerns, all manageable.
Logging. Store the input, the output, the model used, token counts, and latency for every call. When something looks wrong later, you need to see what the model actually received and returned. Logs are also how you tune prompts — you cannot improve what you cannot inspect.
Guardrails. Validate input before it reaches the model and validate output before you use it. Cap input length. Reject obviously bad requests early. If you expect JSON, parse it and fall back cleanly when parsing fails. Add a simple rate limit per user so one person cannot rack up a large bill or hammer the API.
Cost control. Every call costs money, and costs scale with usage. Keep prompts tight, set token limits, and cache results where the same input recurs. For a first feature I often add a per-user or per-day call cap so spend is predictable while you learn real usage. Once you have a few weeks of logs, you can right-size all of this with confidence.
Where I would start on a real app
The clearest example from my own work is CarVendors, a UK used-car marketplace I built solo across frontend, backend, and DevOps — vendor dashboards, search and filtering, reviews, and a data import and scraper pipeline for vehicle listings. It is a working product, and it is exactly the kind of existing app people ask to add AI to.
I want to be precise: CarVendors shipped without AI features. But it is a good illustration of where a first AI task would belong. The import pipeline already pulls in listings that arrive messy — inconsistent titles, free-text descriptions, missing fields. A tight, well-scoped first AI task would be extracting and normalising structured data from those raw listings: make, model, year, and key specs pulled out reliably and handed back as JSON for a human to confirm. Narrow input, checkable output, real time saved on data cleanup. That is the shape of a good first feature — bolted onto an existing pipeline, logged, cost-capped, reviewed before anything goes live.
FAQ
Do I need to rebuild my app to add AI?
Almost never. For a first feature you add a backend endpoint that calls Claude or OpenAI and a small UI to use it. Your existing database, auth, and pages stay as they are. A rebuild is a separate decision and rarely the right starting point.
Which model should I use, Claude or OpenAI?
Either works for most first features. I keep the model name in config so it is easy to switch and compare on your actual task. Pick one, ship the feature, and let your logs tell you whether a different model does the job better or cheaper.
How do I stop AI costs from getting out of control?
Cap token limits per call, add a per-user or per-day rate limit, cache repeated inputs, and log token counts from day one. Start small, watch the numbers for a couple of weeks, then adjust. Predictable spend comes from limits and logging, not from guessing.
Next step
If you have a working product and one clear job you want AI to handle, that is the ideal starting point — narrow, measurable, and low-risk. Take a look at my AI integration and automation service to see how I scope, wire, and ship a first AI feature into an existing app, then send me the one task you have in mind.
Related: CarVendors case study · Services overview