Adding AI to a product with real users is a different job from building one around it. The schema is already decided.
So is the permission model, so is the latency your users are accustomed to, and so is the support queue that will catch whatever the feature gets wrong.
You are not choosing those constraints. You are integrating into them, which is why most of the work sits at the boundaries rather than in the prompt.
We add AI features to products already in production: retrieval built on your real data and your real access rules, an eval set written before the feature, so regressions are caught by CI instead of by a customer.
We add spend ceilings per user and per tenant, and a flag that turns the whole thing off without a deploy.
Which model you use is the least durable decision here. It will change at least twice before the feature is a year old, and swapping it should be a config change rather than a project.
The question that decides whether any of this works is what happens when the model is confidently wrong in front of a paying customer — and who finds out first, you or them.
When the problem is search rather than generation, a decent index and good ranking answer it for less money, with none of the hallucination surface.
If nobody has decided what to build yet, that conversation is AI consulting, not this page.
Scope
The index has to enforce the same access rules your database does, per tenant and per role, before a single document is chunked. Retrofit that later and you re-index everything you have already shipped.
Retrieval that ignores your permission model is a data-exposure incident wearing a chat interface.
Real questions your users already asked, graded once, then run on every pull request. Without that harness, "the answers got better" is something somebody felt on a Tuesday, and nobody can separate a real ranking improvement from having got used to the output.
Answers carry their sources, and a question the index cannot support gets refused instead of filled in. The expensive failure is not the model admitting it does not know.
It is a fluent, well-cited-looking answer assembled out of the wrong three documents, which nobody catches because it reads exactly like a right one.
Caps per user and per tenant, enforced in code rather than watched on a chart. A cheaper model on the paths where your eval set says quality does not move. Caching where the underlying data is stable enough for it to be safe.
Usage-priced features have an awkward property: your best week and your worst invoice are the same week.
Rolled out behind a flag, traced per request, and killable without a deploy. The first bad week of an AI feature is a support problem before it is an engineering one, and the person who needs that switch is on your side of the handover.
Documented so your team ships the next iteration without us.
Permissions first, retrieval second. The index enforces the same access rules your database does, per tenant and per role, before anything is chunked, because bolting that on afterwards means re-indexing everything you have already shipped.
Then a graded eval set built from real queries out of your support log, so you can tell a genuine ranking improvement from having got used to the answers.
Then a flagged rollout to a subset of users, with per-request traces, and an off switch that does not need a deploy.
The API call is the smallest piece. A RAG implementation starts with deciding what your retrievable unit is, whether a paragraph, a row or a whole ticket thread, because that choice caps how good the answers can get.
Then keeping the index correct as records change and get deleted, and ranking, where most of the accuracy actually lives. Then a refusal path for questions your corpus cannot answer, and an eval harness so none of it quietly degrades after the next change.
Most of the difficulty is in your data, not in the model. If what you are describing runs on a schedule with no human in the conversation, that is AI workflow automation and it is built differently.
Four things you cannot redesign: a data model built for transactions rather than retrieval, a permission system the feature must not leak around, a latency budget your users can already feel, and a support team that absorbs whatever the model gets wrong.
A greenfield build chooses all four. An integration inherits them, which is why the part of the estimate that surprises people is never the model work. It is the indexing, the migration and the access control around it.
Whichever one is cheapest at acceptable quality on your own eval set today, wired so that swapping it is a config change.
That answer will be wrong within a year, which is exactly why the eval set matters: it lets you re-run the decision instead of re-arguing it.
The choices worth a meeting are the ones that outlive the model: whether the feature may answer without a source, whether it may act or only suggest, and what it is allowed to touch when it is wrong.
Ceilings enforced in code, not a dashboard somebody checks on Friday. Caps per user and per tenant.
A cheaper model on the paths where the eval set says quality does not move, and caching where the underlying data is stable enough for it to be safe. Truncation rules so one pathological input cannot drag your whole context window with it.
The bill that arrives is rarely one expensive query. It is a retry loop, an oversized context, or a free-tier user who found the feature entertaining.
You design for it, because it will happen. Answers carry their sources, so a support agent can look at what the model was reading instead of guessing. Questions the index cannot support get refused rather than filled in.
Every request is traced, so "it said something strange" becomes a specific retrieval somebody can open and read. And the people fielding the complaints can switch the feature off themselves, without a deploy and without finding an engineer first.
Yes, in two shapes. Either we build the retrieval layer and the eval harness and hand them over, or we work inside your repository alongside the people who will own it afterwards, which is closer to staff augmentation with a narrower scope boundary.
The second shape usually comes up when a prototype someone built in a week still has not shipped six months later, because a prototype is judged on its best output and a live feature on its worst.
Either way the code is yours, IP assignment is signed before repository access rather than after, and the eval set goes with the handover. It is the part that keeps working once we are gone.
You do, outright. IP assignment is signed before repository access, by everyone who touches the code, and it covers AI-assisted output. Handover includes the runbook and the rollback path. Nothing depends on a licence we control.
Nobody before an NDA. Access is read-only until scope is signed, and you can revoke it at any time. The AI tools used on your code, and what each one retains, are listed on the governance page.
Retainers end on 30 days written notice from either side, with no minimum term. Milestone billing means you never pay ahead of delivered work.
Founder, Provingmark
Thirty minutes, no charge.
Related: AI consulting & implementation · AI workflow automation · AI agents for on-chain systems · Staff augmentation · How we work