Service
AI applications*
A demo and a product are not the same thing. I build the second one: retrieval over your own material, agents that take real actions, and the guardrails, fallbacks and cost controls that keep it working once strangers start using it.
Typical timeline
2 to 10 weeks
Pricing
Fixed per project
Reviews
5.0 from 148
Based in
Islamabad, Pakistan
Getting an LLM to do something impressive once is easy. Getting it to do the same thing correctly for a thousand different users, at a cost you can predict, is the actual work.
Most AI projects stall in the same place. The prototype answers well on the five examples someone tried in a notebook. Then it meets real inputs: a scanned PDF, a forwarded email thread with three replies quoted inside it, a question the documents do not answer. It invents something confident and wrong, the token bill climbs, and nobody can tell whether a prompt change made things better or worse.
I build the layer around the model that turns it into software: retrieval so answers come from your material, structure so output is checkable, fallbacks so a slow model never takes the page down, and a way to measure whether a change helped.
Timelines assume the content or data already exists in some usable form. If step one is cleaning up a decade of documents, that gets scoped separately and honestly.
| Project | Scale | Typical timeline | Notes |
|---|---|---|---|
| Assistant over your own docs | One content source, one interface | 2 to 4 weeks | Retrieval, citations and a chat or search interface. The most common starting point and the fastest to prove value. |
| Document to draft tool | Mixed input formats, branded output | 3 to 6 weeks | Takes a document or thread in, extracts the fields that matter, and writes a finished output in your voice with a review step before anything is sent. |
| Agent that performs operations | Touches live business data | 5 to 10 weeks | Creates, updates and deletes real records through defined tools. The guardrails and the permission model are most of the work here, not the prompting. |
| Multi tenant AI platform | Several organisations, isolated data | Scoped case by case | Row level isolation so one tenant can never reach another, even if a prompt tries. This needs a proper look before anyone quotes it. |
01
A look at what you have
You tell me what you are building and what is in the way. I ask questions until I understand it, then tell you whether the project makes sense. This part is free and sometimes ends with me saying no.
02
A written scope and a number
Deliverables, timeline and price in writing before anything starts. The number does not move unless the scope does, and scope changes get quoted separately.
03
Build in the open
You get working builds you can click through, pushed regularly. No long silence followed by a surprise, so feedback lands while it is still cheap to act on.
04
Hand it over properly
A repository you own, documentation that gets a new developer running locally, and a recorded walkthrough of the deploy. Then a support window, because launch is when the real problems show up.
5.0
Average rating
148
Client reviews
23
Countries
31%
Came back
Every review is written by the client and shown unedited. You can read them all here or check them against the source.
Which model do you use?
Whichever fits the job and the budget, and I keep the choice swappable. I have shipped on the Claude API, OpenAI models and Groq, and the right answer usually varies by task inside one product. Classification and extraction often run fine on a small fast model, while drafting in a specific voice needs a stronger one. Locking a product to a single provider is a risk, so the integration sits behind an interface you can change later.
How do you stop it making things up?
Three things, in order of how much they help. Retrieval, so answers come from your documents rather than the model recalling something plausible. Structured output validated against a schema, so a malformed or invented field fails instead of getting saved. Then a review step in the interface for anything a human should confirm before it leaves the building. No system is perfect, and a product that pretends otherwise is the one that gets you in trouble.
How do you control the cost?
A budget per request, set before the feature ships. Caching for anything repeated, smaller models where a big one is not earning its keep, and retrieval that sends the relevant passages instead of stuffing whole documents into context. I also log token spend per feature so you can see which part of the product is expensive, which is usually not the part people assume.
What happens to our data?
That gets decided before anything is built, because it drives the architecture. Which provider processes what, whether anything is retained, what stays inside your own infrastructure. If your data cannot leave a particular jurisdiction or environment, say so at the start and the design accounts for it. Retrofitting that later usually means rebuilding.
Do we need to fine tune a model?
Almost never, and I will usually argue against it. Retrieval plus good prompting gets you most of the way for a fraction of the cost and none of the maintenance. Fine tuning makes sense for narrow, high volume, stable tasks where you already have clean labelled examples and have measured that prompting is not enough. That is a much smaller set of projects than the amount of talk about it suggests.
What happens when the model changes underneath us?
Providers deprecate versions and behaviour shifts between releases. That is why the evaluation set matters: a fixed group of real cases with expected outcomes that you can rerun against a new model in an afternoon and see what moved. Without one, every upgrade is a gamble. With one, it is a decision.
Can you work on an AI feature inside our existing product?
Yes, and a good share of my work is exactly that. I read the codebase, work to its conventions, and add the feature rather than arriving with an opinion about rewriting everything. I will tell you honestly if something in the existing architecture makes the feature much harder than it needs to be.
Worth reading before you hire anyone for AI work, because the gap between a demo and a product is where most of the budget goes.
Open to new work
Tell me what you are trying to build.
If I am the right person you will get a scope and a number in writing. If I am not, I will say so and point you somewhere better.