AI product development — services — Ahsan Mahmood
Shipping AI features into real products — retrieval, agents and the plumbing that keeps them affordable.
A product where a model does part of the work — with the part it gets wrong designed for, rather than hoped against.
What does the feature do on the day the model is wrong?
Most AI features have no answer, because they were designed as though that day would not arrive. A model is a component that is sometimes confidently wrong, and the interface in front of it usually assumes otherwise.
The demo always works, because somebody chose which demo to show.
What arrives afterwards is the answer nobody can check, the request that spends money every time somebody clicks it, and the response that streams on while the person who asked has already moved on.
Those are not edge cases. They are the ordinary week.
There is a fourth that only shows up later. A feature people stop trusting is a feature they stop opening, and nobody files a bug report about that.
The constraint that shapes this work is that a model call costs money on every use.
A row in a database is effectively free once it exists. A generated answer is a purchase, repeated. It scales with the number of people who like your product.
So the budget is a design input rather than something checked afterwards.
Every feature gets a quota per user, and that quota is a value an administrator can change rather than a number buried in code. Raising a limit should not need a release.
Model choice follows the task rather than a reputation. A smaller one that is right about a narrow thing is usually the better purchase.
The second constraint is older than the project. Nothing runs on a server that has to be kept alive, so calls go through the project's own backend where there is one and a small edge function where there is not.
The provider key never reaches the browser.
What an engagement of this shape covers is the same everywhere it is bought.
Model selection sized to the task. Prompt and context design, which is mostly deciding what the model is allowed to see. Streaming responses with a cancel path, because an answer somebody has stopped reading should stop being paid for.
A visible failure state when the model is wrong. And cost and quota bounded per user.
Context design decides the quality. A model given the right three paragraphs beats a larger model given the whole database. It also costs less per call, which is the rare case where the cheaper answer is the better one.
The failure state is the one people argue about. A product that never shows the model being wrong has decided its users will not notice, and they do, usually at the moment they were about to trust it with something.
ContentSynergy AI and LearnQuest AI are published on this site and each has its own page. My name is Ahsan Mahmood, and the person who chooses the model is the person who has to explain the invoice.
Prompt work is version-controlled like anything else. A prompt that changed on a Tuesday and made the output worse is only findable if that change sits in the history beside every other change.
The costs are unusual, because most of them are things the product has to admit out loud.
A bounded quota means a user can reach a wall, and that wall has to be explained on screen rather than met as a broken button.
Showing a failure state means the interface says the answer may be wrong, which demos worse and ships better. That order is deliberate.
A cancel path means the interface holds a half-finished answer and has to decide what it is worth. A smaller model chosen for cost is worse at the things outside its task, and that is a trade you should hear on the scoping call rather than infer later from a support thread.
There is a cost in patience too. Bounding a feature properly takes longer than letting it run unbounded, and the reward is an invoice that surprises nobody.
None of this makes the feature slower to build than the demo was. It makes it more expensive to finish, and the gap between those two numbers is why so many AI features stop at the demo.
The exclusions hold across the catalogue. Visual design as a standalone deliverable. Native iOS. Blockchain work. Copywriting and content.
Two more belong to this service in particular. I will not promise accuracy, because accuracy belongs to a model somebody else trains and it moves when they change it.
And I will not build a feature whose only safeguard is that the model is usually right, because the whole point of the failure state is that usually is not a plan.
Thirty days of bug fixes at no charge, and after that nothing is automatic.
The provider's pricing and the model's behaviour belong to somebody else, and neither is a thing I can hold still for you.
from $800
How long it takes
Small features 1–2 weeks, an MVP 4–8 weeks, a full production app 8–16 weeks. Those are ranges I have hit on work of that shape before. The scoping call settles which part of the work the model is actually doing, because a feature that assists a person is a different size from one the product depends on.
Every engagement of this shape covers
- Model selection sized to the task
- Prompt and context design
- Streaming responses with a cancel path
- A visible failure state when the model is wrong
- Cost and quota bounded per user
Built with
- OpenAI
- TypeScript
- Streaming
What happens when the model gets it wrong?
The interface says so, and that visible failure state is one of the fixed deliverables. A product that never shows the model being wrong has decided its users will not notice, and they do — usually at the point they were about to trust it with something. How the wrong answer is presented is designed before the feature is built, not after the first complaint.
What will an AI feature cost to run once it is live?
Whatever the quota you set allows, because every feature gets a quota per user and the model is sized to the task rather than to its reputation. A model call is a purchase repeated on every use, so the budget is a design input from the start. The quota is an administrator field rather than a number in the code, so changing it does not need a release.
Which model do you use?
Whichever is smallest for the task, argued on the scoping call and written down. OpenAI is the default provider, with TypeScript and streaming on the client. A smaller model that is right about a narrow thing is usually a better purchase than a larger one asked to do everything.
Where does the provider key live?
On the server side of the line, in the project's own backend where it has one and a small edge function where it does not. A provider key never reaches the browser bundle. That is the same rule every service on this site follows, not a rule invented for this one.
Can a user stop a long answer?
Yes, because streaming responses ship with a cancel path. An answer somebody has stopped reading should stop being paid for. The interface also has to decide what a half-finished answer is worth keeping, and that gets decided deliberately rather than by accident.
How much does building an AI feature cost?
$800 USD is the floor for a small, well-defined feature. Everything above that comes from a scoping call, in writing, before any work starts. What moves the number here is how much of the work the model is actually doing, because a feature that assists a person needs one honest failure state while a feature the product depends on needs a quota, a cancel path and a designed way of being wrong in public.
https://aoneahsan.com/services/ai-product-development