AI Integration Services
AI added to your existing product, designed for the times it gets it wrong.
What is AI integrations?
AI integration means adding model driven features to software you already run, deciding where they genuinely help, how the interface behaves while waiting, and what a user can do when the output is wrong.
Calling a model from existing software is a small job. Deciding where it belongs, and designing for the times it is wrong, is the actual work.
Two things change once AI is in a live product. Responses are slow compared with ordinary software, so an interface that felt instant now waits. And output is sometimes wrong in ways that look completely confident.
A feature with no recovery path for a wrong answer will damage trust in the whole product, not just in that feature. That is the design question worth spending time on.
Where we will not put a model
Duara adds AI features to existing products from Nairobi, for software companies and for businesses running systems they built or commissioned.
We will not put AI into a flow where a wrong answer has no recovery path. If a user cannot see, question or undo the output, the feature is a liability regardless of how well it performs in testing.
Who this is for
- You want AI features in an existing product
- A previous AI feature confused users
- The interface now waits where it used to be instant
- Nobody has decided what happens when output is wrong
Industries we serve
- Software companies
- Fintech
- E-commerce platforms
- Property technology
- Healthcare technology
- Education technology
Problems this solves
These are product design problems rather than model problems, which is why they get underestimated.
- No recovery when output is wrong. A confident wrong answer reaches the user with no way to question or undo it, and trust in the whole product drops.
- Interfaces that now wait. Model responses are slow relative to ordinary software, and an interface designed for instant results feels broken.
- Unclear what is machine generated. Users cannot tell which parts came from a model, so they either over trust everything or dismiss all of it.
- Features added because AI is expected. Something is built to say the product has AI, and it solves no problem the user actually had.
What we deliver
AI features placed where they genuinely help, with interface behaviour designed for latency, output clearly attributable, and a defined recovery path when the answer is wrong.
AI features built into your existing product
Interface behaviour designed for model latency
Clear indication of what is machine generated
A recovery path for wrong or unhelpful output
Fallback when the model is unavailable
Measurement of whether the feature is used
Features
- Recovery paths as a requirement. A user must be able to see, question or undo model output, or we would not build the feature.
- Latency designed for. Streaming, progress and optimistic states are planned in, because an interface that used to be instant now waits.
- Machine output is labelled. Users are told what came from a model, since hiding it damages trust more than disclosing it ever does.
- Placed where it helps. We will say when a proposed feature solves no real problem, rather than building AI for its own sake.
- Usage measured after launch. Whether the feature is actually used is reported, which is the only honest test of whether it was worth building.
Benefits
- Features people use. Placing AI against a real problem is the difference between a used feature and a demonstrated one.
- Trust survives mistakes. A visible recovery path means a wrong answer is an inconvenience rather than a reason to distrust the product.
- The product still feels fast. Designing for latency keeps the experience acceptable even when the model is not quick.
- You learn what to build next. Usage data after launch tells you which direction is worth extending.
Technologies we use
- Feature placement. Deciding where model output genuinely improves a flow rather than decorating it.
- Streaming and progressive display. Showing output as it arrives so the interface does not sit blank.
- Attribution and disclosure. Making clear which content is machine generated within the interface.
- Recovery and correction. Letting users reject, edit or escalate output rather than accepting it silently.
- Usage instrumentation. Measuring whether the feature is used and where users abandon it.
Latency is the constraint that reshapes the interface. A model taking three seconds is normal and an interface that blocks for three seconds is not, so the design has to absorb the difference.
How the process works, step by step
An AI feature usually takes four to eight weeks, including a period measuring whether anybody uses it.
-
Step 1
Free product review
We look at your product and where model output would genuinely help rather than decorate.
-
Step 2
Failure design
What happens when output is wrong is designed before the feature itself is built.
-
Step 3
Prototype in the real flow
The feature is tested inside the actual interface, since latency and disclosure only reveal themselves in context.
-
Step 4
Released to a subset
It goes to a portion of users first, so problems appear before everybody sees them.
-
Step 5
Measured honestly
Usage is reported after launch, including where the feature is being ignored.
Quality assurance and how we work
The commitments attached to putting AI in front of your users.
- No feature without a recovery path. If a user cannot see, question or undo the output, the feature is a liability however well it tests.
- We disclose machine generated output. Hiding it damages trust far more than disclosing it, and users work it out regardless.
- We will say when AI is the wrong answer. Where a proposed feature solves no problem the user has, we say so rather than building it because AI is expected.
- We report usage after launch. Whether people actually use the feature is the only honest test, and we report it even when the answer is unflattering.
- Latency is designed for, not discovered. Interface behaviour under a slow response is planned before build rather than patched after complaints.
Frequently asked questions about AI integrations
What is the hard part of adding AI?
Not the model call. Deciding where it belongs and designing for the times it is wrong is the actual work.
What if the output is wrong?
The user must be able to see, question or undo it. Without that recovery path we would not build the feature.
Why insist on that before building?
Because a confident wrong answer with no recovery damages trust in the whole product, not just in that one feature.
Will users know it is AI?
Yes. We disclose machine generated output, because hiding it damages trust more than disclosing it and users work it out anyway.
Our product feels slow now, why?
Models are slow relative to ordinary software. An interface designed for instant results has to be reworked to absorb the wait.
How do you handle that?
Streaming, progress states and optimistic display, planned before build rather than patched after complaints.
What if the model is unavailable?
The product degrades gracefully rather than failing. The feature becomes unavailable while everything else keeps working.
Will you tell us if a feature is a bad idea?
Yes. Where a proposal solves no problem your users have, we say so rather than building AI for its own sake.
How do we know the feature is being used?
Usage is measured after launch and reported honestly, including where the feature is being ignored.
How long does a feature take?
Four to eight weeks, including the period spent measuring whether anybody uses it.
Can you work with our existing codebase?
Yes. This is ordinary product work in your stack rather than a separate system bolted alongside.
Do you release to everybody at once?
No. A subset first, so problems appear before your whole user base sees them.
Can users correct the output?
Where it makes sense, yes, and corrections are worth capturing since they show where the feature is weakest.
What about user data going to a model?
We scope exactly what is sent and can strip fields that do not need to go, which is a decision worth making deliberately.
Does this need our own AI API?
Not necessarily, though a gateway helps once you have more than one feature calling models.
Can it work offline?
Generally no, and where your users have poor connectivity that is a real design constraint we would raise early.
Will it increase our running costs?
Yes, and we estimate that before building, from your expected usage rather than a favourable example.
Can it handle Swahili content?
Yes, though quality varies by task and we test on your actual content rather than assuming.
Who owns the code?
You do. It is written into your product and documented like any other feature.
What does an AI feature cost to build?
Feature complexity and interface work determine it, quoted after the product review.
Glossary of terms
Terms used when adding AI to a product.
- Latency
- The delay between a request and a response, which is far higher for models than for ordinary software.
- Streaming
- Displaying output as it is generated rather than waiting for the whole response.
- Recovery path
- The way a user rejects, corrects or escalates output that is wrong.
- Disclosure
- Telling the user which content was machine generated.
- Graceful degradation
- The product remaining usable when the AI feature is unavailable.
- Feature adoption
- The proportion of users who actually use a feature after it ships.
Related services in AI Development
Talk to us about AI integrations
Name the place in your product where a user is stuck or waiting. That is where an AI feature is worth trying first.
Start your project