From MVP to production: building AI products that businesses can actually use

A prototype proves that a model can produce a plausible answer on a friendly example. A business needs something narrower and sturdier: one job, completed by a real user, with a record of what happened and a person responsible when it goes wrong. That is the distance between an MVP and a product you can put in front of customers or staff.

Cut the product, not the foundations

The first release should do one workflow well. Extra audiences, extra roles and extra integrations can wait. What should not wait is the skeleton those later features will stand on: an account, permission to see only your own data, the core path from start to outcome, and an environment you can deploy again next week.

This is the bias of our SaaS and MVP work. Small in surface area. Serious about the parts you would otherwise rebuild immediately.

Treat model behaviour as a product decision

Before the build, write down the cost of a wrong answer. A clumsy summary on an internal note is not the same risk as a wrong figure sent to a customer. The higher the cost, the more the first release should draft and wait, rather than act.

• Collect a set of real examples, including messy ones and ones the product should refuse.
• Decide the output shape. Free text is harder to test than a defined set of fields.
• Show the suggestion in the workflow and record whether a person accepted it.
• Keep the non-AI path. Users need a way to finish the job when the model fails.

Production is an operating state

Shipping is not only a deployment. Someone needs to know where the logs are, how to turn the feature off, and what “working” means next month. For an AI feature that includes the ordinary application health and a look at the examples that failed review. You do not need a research lab. You need a short habit.

Security belongs in that habit. Secrets stay on the server. The model receives the minimum context. A prompt is not a place to hide a key, and a model reply is not a place to hide an authorisation check. None of this is a guarantee that a model will behave. It is the minimum that lets you notice and limit the damage when it does not.

What the second release is for

Use the first users to choose the next slice. Where did they edit the draft every time? Which step did they skip? Which integration did they actually ask for once they had the core path? Those answers are more useful than the roadmap written before anyone logged in.

Widen the agent, the automation or the data only after the narrow version has been used. Adding tools because the framework allows it is how a small product becomes an untestable one.

A brief you can hand to an engineering partner

If you are ready to talk to a studio, bring the user, the job, what already exists, and what a wrong answer would cost. You do not need a technical design. You do need to be willing to leave features out. That is the conversation we expect on Start a Project, and it is the same standard described in what AI-first product engineering is.