Adding AI to a Product That Already Has Users

The request tends to arrive in the same shape. A board member asks what the AI story is. A competitor ships something with a sparkle icon. A large customer mentions it on a renewal call. Within a week the founder is collecting quotes for a feature nobody has scoped.

Gartner expects 40% of enterprise applications to carry task-specific AI agents by the end of 2026, against under 5% in 2025. That is a fast shift, and it explains the pressure. It does not tell you what to build, and it certainly does not tell you what it costs on top of the product you already run.

We have shipped 315 products since 2017 and a growing share of the work is this exact job rather than a new build. The pattern is consistent enough to write down.

The first decision is not the feature, it is the foundation

Every one of these projects opens with the same fork: retrofit AI into the system you already have, or use the request as the reason to rebuild.

Retrofitting is the right answer far more often than it feels like it should be. A rebuild means re-implementing years of business logic that is usually documented nowhere except in the running code, and the edge cases you will discover are the ones your customers depend on quietly. The rebuild reads cleaner on a whiteboard and it is almost always the slowest route to anything shipping.

The honest exceptions are narrow. If the data the feature depends on is not reachable without a rewrite, or the system has no tests and no observability at all, then adding AI on top makes the underlying problem worse rather than visible. AI amplifies good engineering practice and bad engineering practice in equal measure. A team without tests does not get better output from agents, it gets faster output it cannot verify.

So the first two weeks of a sane project are spent on the boring question of whether your data is reachable, your permissions model is coherent, and your logging would tell you if the feature started giving wrong answers on a Tuesday.

Where the money actually goes

Founders expect the model to be the expensive part. It is close to the cheapest line in the budget, and the gap between expectation and invoice is where most disputes start.

Integration engineering. A feature that only answers questions is a demo. A feature that reads a customer record, updates a deal and books a slot touches 3 APIs, 3 auth flows and 3 distinct ways to fail. Each one costs roughly a week when the API is well behaved.

Data readiness. Retrieval quality is a function of the documents behind it. If 4 versions of your pricing policy exist across Notion, an old PDF and somebody's Google Doc, the assistant will confidently cite all 4. Cleaning that up is real work that almost never appears in a first quote, and for mid-market companies a CRM cleansing project on its own runs $20,000 to $80,000.

Evaluation. You need a set of real questions with known good answers, run automatically on every prompt or model change. Without it, your regression detection is a customer emailing support. Building that harness is 1 to 2 weeks and it is the line item cheap quotes remove first.

Permissions. This is the one specific to products that already have users. Your AI feature must inherit your existing access model exactly. An assistant that can retrieve across tenants because retrieval was bolted on beside your authorisation layer instead of behind it is not a bug you patch later, it is an incident you disclose.

The running cost, and the pattern that keeps it controllable

Inference is usually modest and usually misunderstood. For most applications under 10,000 monthly active users, API costs land between $50 and $500 a month. The number moves on context size and call frequency rather than user count, so a summariser that quietly sends 40 pages of context on every keystroke will cost more than a chat feature with 10 times the traffic.

What you should refuse to do is hard-wire model calls into your core codebase. Scattering API calls through a 4-year-old service is how you end up unable to change provider, unable to see what a feature costs, and unable to answer a customer asking why the output changed.

The pattern that holds up is a thin layer of your own between the product and the models. Everything AI-shaped goes through it: prompt construction, retrieval, model routing, token accounting, caching, retries and logging. Your existing application calls one internal interface and stays otherwise untouched. When prices drop again, or a better model lands, or legal asks which customers had output generated by which version, you change one component and you have an answer.

We covered the equivalent question for standalone agents in AI agent development cost in 2026, and the architecture thinking behind keeping a product changeable is in the architecture decisions that decide whether an MVP scales.

What breaks, and it is rarely the model

On a new product, a weak AI feature is a disappointing launch. On a live product, it spends trust you already earned.

Only 6% of companies say they fully trust agents to run core business processes on their own, and your users arrived with that scepticism pre-installed. One unreliable feature does not stay contained in the user's head. It colours how they read everything else in the product, and the cost surfaces later in support load and renewals rather than in a dashboard you are watching at launch.

The commercial side has moved in the same direction. Buyers now ask how the feature decides, what data it touched, who can see what, and where a human reviews it. Audit trails and explainable behaviour have become deal terms in mid-market procurement. Build the logging and the disclosure in from the start and the security questionnaire is an afternoon. Bolt them on afterwards and it is a quarter.

One more thing that is now non-optional in Europe: if your product is reachable by EU users, transparency duties under Article 50 of the EU AI Act have applied since 2 August 2026, and the marking requirement for generative output in systems already on the market lands on 2 December 2026. What the EU AI Act actually requires you to build walks through the four duties and which one falls on you.

What we charge, and why the shape is different

Our AI integration sprint starts at $5,000 and is scoped for exactly this situation, which is one workflow inside a product that is already live and cannot be taken offline. Full AI-native builds run $15,000 to $35,000 across 6 to 10 weeks and are on the pricing page with the scope spelled out.

Fixed scope is set before anyone signs. If we misjudge the hours, that is ours to absorb. The codebase, the models we selected and the reasons behind those choices transfer to you completely, because a layer you cannot modify without calling us is not an asset you own.

The founders who get value out of this are the ones who pick a narrow workflow, measure whether it helped, and then widen it. The ones who do not are usually the ones who shipped a general assistant to the whole user base in one release and are now reading the support queue.