Service
AI and LLM integration for existing products
Adding AI features to a working product without destabilising it, inflating its running cost, or shipping something that confidently makes things up.
- Every model output
- Schema-validated
- Cost measured
- Per-request
- Before any prompt change
- Eval set
The problem an AI feature solves
The demo is easy and the product is hard. A prompt that works in a playground becomes a feature that costs more per user than the subscription, invents answers under pressure, and has no way to tell whether a change made it better or worse. The engineering is in the parts that come after the prompt.
How Dawar Mustaqeem builds an AI feature
- 01
Pick the shape of the problem
Retrieval, extraction, classification and generation are different problems with different failure modes. Choosing wrong here is the most expensive mistake available, and it happens before any code.
- 02
Ground it in your data
A retrieval pipeline over your own content — chunking, embeddings, vector search and reranking — so the model answers from your sources instead of its training data.
- 03
Constrain the output
Structured outputs and schema validation, so downstream code receives something it can rely on rather than prose it has to parse and hope about.
- 04
Control the cost
Prompt caching, model routing by task difficulty, and token budgets — decided at design time, because retrofitting cost control usually means rewriting the feature.
- 05
Evaluate changes
A test set and an evaluation harness, so a prompt or model change can be shown to be an improvement instead of assumed to be one.
What an AI feature build includes
- An AI feature integrated into your existing product
- Retrieval grounded in your own content
- Structured, validated outputs
- Cost per request measured and controlled
- An evaluation set so future changes can be judged
Technologies used to build an AI feature
Related work by Dawar Mustaqeem
Common questions about AI & LLM integration
How do you stop an LLM feature from making things up?
Ground it in retrieval so answers come from your sources, constrain outputs to a schema so malformed responses fail loudly rather than silently, and cite the retrieved source back to the user. Hallucination is reduced by architecture, not by prompt wording.
How do you keep running costs under control?
Route easy requests to smaller models, cache prompt prefixes that repeat, and set explicit token budgets per feature. These are design-time decisions — added afterwards, they usually mean rebuilding the feature.
What if our data cannot go to an API?
Then it should not. That is a different engagement — a model running entirely on your own hardware, with no data leaving your boundary.
References for AI & LLM integration
The primary documentation behind the decisions on this page.
Got a project like this?
I'm based in Birmingham, UK and work with clients remotely. Tell me what you're building and I'll tell you honestly whether I'm the right fit.