AI product development

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.