Generative AI Integration Services That Survive Real Traffic
Generative AI integration is the work of putting LLM features inside software you already run. Retrieval, chat, drafting, summarisation, classification. InApps handles model choice, the retrieval pipeline, evals, guardrails and the cost model. Senior engineers in Ho Chi Minh City. Your codebase, your cloud account, your data.
Trusted by engineering teams across 15+ countries - from startups to Fortune 500.
Why most generative AI projects stall after the demo
Six things we hear on almost every first call.
The demo answered every question. Then real users asked real ones and it started inventing answers.
Month one's API bill looked fine. Traffic tripled in month three and nobody had modelled it.
The knowledge is spread across four systems. Three of them disagree, and none is marked as the current one.
Legal asked where the prompts go and whether the vendor trains on them. Nobody could answer in writing.
It shipped and it worked. Six months on, a model update quietly made it worse and no test caught it.
Two engineers learned the framework on the job. They are now the only two who can touch the feature.
What generative AI integration actually means
Already have a product? This is the AI work that goes inside it.
Features in your app, not a chatbot bolted to the side
Integration puts LLM capability into software that already exists. Search that understands a question. A draft written from your own records. A ticket summarised before a human opens it. The feature lives in your UI, behind your auth, on your data.
That is the line between integration and generative AI development services. Development starts from an empty repository: new product, new interface, new data layer. Integration works inside a codebase, an auth model and a database that are already in production. We do both. Most enquiries turn out to be the second one, even when the brief says the first.
What we build
The parts that turn a prompt into a feature.
- Retrieval pipeline over your own sources
- Prompt, tool and model routing layer
- Eval suite with a scored baseline
- Caching, rate limits and cost caps
- Traces and a quality dashboard
What stays yours
Everything a lock-in would take.
- The codebase and the repository
- The cloud account and the model keys
- The data, never used to train a model
- Architecture and roadmap decisions
- IP, from the first commit
Six patterns cover most of what clients ask for
Pick one and ship it. A first feature that works beats a platform that is still being scoped.
Retrieval and semantic search
Ask in plain language. Get an answer built from your own documents, with citations a reader can open and check.
Copilots inside your UI
A panel that knows the record on screen. Drafts, explanations, next steps. Scoped to what that user is allowed to see.
Drafting and summarisation
Proposals, replies, release notes, meeting summaries. Written from your templates and your records, not from the open web.
Classification and extraction
Route a ticket. Pull fields off an invoice. Tag a call transcript. Unglamorous work, and usually the fastest payback on the list.
Voice and multimodal
Speech in, speech out. PDFs, scans and photos read as input. Worth it where typing is the actual bottleneck.
Autonomous agents
Multi-step work across tools, with permissions and approval gates. A bigger commitment than a feature, and a different build.
Integrate with us, build in-house, or buy a point tool
All three are reasonable. They fail in different places.
| Criterion | InApps | Build in-house | Off-the-shelf AI tool |
|---|---|---|---|
| First feature in production | 6 to 10 weeks | One to two quarters, plus hiring | Days, if your use case is theirs |
| Grounded in your data | Retrieval across your systems, with citations | Yours to build | Upload-only, or not at all |
| Hallucination control | Eval set scored before launch, re-run on every change | Depends who you hire | Their evals, not yours, and not visible |
| Model choice | Model-agnostic. Switching is config | Yours to control | Locked to the vendor's model |
| Where your data sits | Your cloud account | Your cloud account | Their tenant |
| Cost visibility | Token cost modelled at your volume, then capped | Yours to model | Per seat, used or not |
| After launch | We watch quality and test model upgrades | Your team owns the drift | You take whatever ships |
| What you own at the end | Code, prompts, eval sets, pipeline | Everything | A subscription |
Models, frameworks and infrastructure we build on
Model-agnostic on purpose. Providers change their price and their quality on their own schedule. You should be able to move without a rewrite.
Models
OpenAI, Anthropic Claude and Google Gemini. Open-weight models on your own hardware where data cannot leave the network. Routing sits behind one interface, so a price rise is a config change and an eval re-run.
Frameworks
LangChain and LangGraph for orchestration. Pinecone, pgvector and Elasticsearch for retrieval. Ragas and custom harnesses for evals. We will also tell you when none of them is needed.
Infrastructure
AWS Bedrock, Azure OpenAI and Google Vertex, in your account rather than ours. Traced end to end. Same CI, review and rollback discipline as the rest of your stack.
A retrieval feature is only as good as what it can read. These are the sources we connect to most often. Plain file shares are routine too.
From first call to a feature your users touch
Scope and cost model
One call, then a written scope. What the feature does, which model, and what a run costs at your volume.
Prototype on your data
A working version on real records. Not a slide. You use it yourself before we build anything for production.
Production build
Integrated into your codebase and your auth. Evals scored, guardrails on, QA signed off before anyone outside sees it.
Run and improve
Live, watched, and upgraded when a better model lands. Standard LLMOps: traces, evals and spend in one place. Quality does not get to drift quietly.
Four things standing between the model and your users
Grounding
- Answers built from your documents
- Retrieval scored before the model sees it
- A citation on every claim
Evals
- A test set built from your real questions
- Scored baseline agreed before launch
- Re-run on every prompt or model change
Guardrails
- Refusal on out-of-scope questions
- PII redacted on the way in
- Output schema enforced, not hoped for
Human review
- Approval step wherever a mistake costs money
- Every thumbs-down routed to a person
- Every failure becomes a test case
What actually decides the price of an integration
We do not publish a rate card for this work. The build is rarely the biggest number. Running it usually is. Five things decide it, in the order they tend to matter.
| Cost driver | Cheaper when | Expensive when |
|---|---|---|
| Query volume | Hundreds a day, and a small model handles most of them | Millions a month. Token spend passes the build cost inside year one, then repeats |
| State of your data | One current source the pipeline can read directly | Four sources that disagree. Cleaning them is a project before the feature starts |
| Cost of a wrong answer | A user notices, retries, and nothing was spent | Money moved, or a customer saw it. Evals and approval steps get much heavier |
| Depth of integration | A panel over an API that is documented and has a sandbox | Legacy auth, no test environment, and a UI nobody has opened in three years |
| Regulatory load | Internal tool, no personal data, no external reporting | Personal or financial data, audit trails, residency constraints |
Ask the people who stayed
Every quote below is from a verified review. None of them were written by us.
“Clear expectations, rules that actually hold, delivered on time. And the people are genuinely easy to work with, not just professionally, but as humans.”
Where your data goes, and where it does not
Two questions stop most AI procurement reviews. Does the model provider keep our data, and who owns what you build. Both answered here, in the order legal asks them.
Your data is not training data
We use enterprise API tiers where training on customer content is contractually off. The provider's terms go in the scope document, not in a sales sentence. Where nothing may leave your network, we run open-weight models on your own infrastructure instead.
IP is yours from the first commit
Application code, prompts, retrieval pipelines and eval sets are all assigned to you. No milestone gates the transfer. The work lives in your repository under your access control throughout, and nothing is reused on another account.
ISO/IEC 27001:2022 certified
A certified information security management system audited against the 2022 revision, not a self-attestation. It covers the office, the devices and the network, with the access control, logging and incident response the standard requires.
GDPR for EU and UK work
Personal data is handled to GDPR requirements, with processing terms agreed before onboarding. Personal fields are redacted before a prompt leaves your systems wherever the use case allows. Residency and retention are agreed per engagement, not assumed.
Worth the call, or worth an early no
Generative AI is the wrong answer to plenty of good problems. Here is where we say so.
This works well if
- You have a product in production and one feature you can name.
- The content or records already exist somewhere a pipeline can read.
- You can describe a good answer, and say what a bad one costs.
- You want the code, the prompts and the eval set in your own repository.
- Someone on your side will own the feature after launch.
This is not a fit if
- You want a system that decides and acts across several tools on its own. That is agent work, a different build with different failure modes. Start at AI Agent Development.
- You need the same correct answer every time. No language model gives you that. Deterministic code does, and it is cheaper.
- Your data is scattered and nobody owns it. Fix that first. We will say so on the call rather than in month three.
- AI is in the plan because a board slide asked for it. We will not invent a use case that is not there.
Answered without the hedging
Not sure which one you need?
Send us the feature and the data behind it. We will tell you whether it is an integration, an agent, or something that needs no model at all.
Book a Discovery CallWhat are generative AI integration services?
How is this different from generative AI development services?
How long before the first feature is live?
How do you stop the model making things up?
How do you control LLM cost?
Is our data used to train models?
Which model do you use?
Do you build AI agents as well?
Tell us the feature and the data behind it
No pitch. We come back with a scope, a timeline and a token cost at your real volume. If a language model is the wrong tool for the job, we will say that on the first call.