Adding AI to software that already exists
LLM integration adds language model capability to software you already run: summarisation, drafting, classification or search inside your existing product. The engineering concerns are latency, cost per call, graceful failure when the provider is unavailable, and not being locked to one vendor.
This is the most common AI work and the least discussed, because it produces a feature rather than a product. A helpdesk that summarises long threads. A CRM that drafts a follow-up. A search box that understands a question rather than matching keywords. The model is a component, and it should be engineered like any other external dependency.
Integrations treat the model as infallible and always available. Calls are made synchronously in the request path, so a slow response becomes a slow page. There is no timeout, so a hanging call hangs the feature. No fallback exists, so a provider outage takes the feature down with it. Costs are unmonitored until an invoice arrives. And prompts are scattered through the codebase as string literals, so nobody can tell what the system actually asks the model.
When this work makes sense
Questions worth asking any supplier
Is the call in the request path? A synchronous model call makes your feature as slow as the provider.
What happens on timeout or outage? Without a fallback the feature simply breaks.
What does each call cost, and is that monitored against a budget?
Are prompts versioned and centralised, or scattered as string literals?
How hard would switching providers be? Vendor lock-in here is avoidable and frequently accepted by accident.
Deliverables
Feature design with latency and cost budgets set before building
Asynchronous handling where the operation is slow, with progressive feedback
Timeouts, retries and a defined fallback when the provider is unavailable
A provider abstraction so switching does not mean rewriting the feature
Prompts versioned and centralised rather than embedded in application code
Cost monitoring with alerting against a budget
Caching where inputs repeat, which is frequently the largest cost saving
An evaluation set so prompt changes can be measured rather than assumed
Built with
Process
The latency and cost budget is set before the feature is designed, because both constrain what is possible. A feature that must respond in under a second cannot use a slow model on a long prompt, and knowing that first changes the design rather than forcing a rewrite after testing. Most disappointing AI features were designed without either number in mind.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Direct API calls, a framework, or a managed service
Direct API integration
Fits: Focused features where you want full control and minimal dependencies
Limits: You build retrieval, caching and abstraction yourself
Framework (LangChain and similar)
Fits: Complex chains and rapid prototyping
Limits: Substantial dependency and abstraction overhead for simple features
Managed AI service
Fits: Standard capabilities where the provider's shape matches yours
Limits: Less control over prompts, cost and data handling
Case studies
No published integration case study.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Which model provider should we use?
It depends on the task, the latency you need, cost at your volume and your data handling requirements. More useful than choosing well now is building so you can change later, provider quality and pricing both move, and an integration welded to one vendor ages badly.
How do we control costs?
Cache repeated inputs, use smaller models where they suffice, keep prompts short, and set a monitored budget with alerts. Caching is usually the biggest single saving, because production traffic contains far more repetition than people expect.
What if the provider has an outage?
Your feature should degrade rather than break, a fallback to a simpler method, a queued retry, or a clear message. Features built without this simply stop working, and the provider's status page is the first anyone hears of it.
Should the call happen while the user waits?
Only if it is fast enough to. For anything slower, run it asynchronously and show progress, or precompute where possible. A synchronous call makes your feature exactly as slow and as available as the provider is that minute.
Where should prompts live?
Centralised and versioned, not scattered as string literals through the codebase. You need to see what the system asks the model, change it without a deployment where sensible, and compare versions when output quality changes.
Can we use an open model on our own infrastructure?
Yes, and it is worth considering for data sensitivity or high volume. The trade is operational: you own the hosting, scaling and updates, and quality varies by task. It is a genuine option rather than a default.
How do we know a prompt change improved things?
An evaluation set with expected outputs, scored before and after. Without it, prompt changes are judged on a handful of examples someone tried, which is how quality quietly regresses while everyone believes it improved.
What happens when the provider changes or retires the model?
Your outputs change, sometimes noticeably, and usually with little warning. This is the risk people underestimate: a prompt tuned against one model version can behave differently on the next. The defences are keeping an evaluation set you can re-run, pinning a version where the provider allows it, and designing so that swapping providers is a configuration change rather than a rewrite.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.