AI MVP and POC: real users in twelve weeks

An MVP is the first version of a product: complete enough for real users to use it with real data, small enough to be built in twelve weeks. At Bonne Idée, it answers a single question: whether the product deserves to go further.

The POC answers the question « Is it technically possible with your data? » The prototype answers « Do people understand it? » The MVP answers « Do people use it? » Confusing them means paying for a full product to answer a question a prototype would have settled.

We write down with you the question the first version has to settle, and we cut everything that does not answer it. We design the user journeys, build in no-code, low-code or code depending on what the product requires, and bring in AI where it adds something. An MVP without AI is built by the same team with the same method. Then the tool goes into real hands, and we look at what users do rather than what they say.

At the end of the twelve weeks, you have a live product, used with real data, and an answer on what comes next. You have not written a specification or hired anyone before getting that answer.

Twelve weeks is the time between the start of scoping and the moment real users have the product in their hands. Here is how they break down on a typical project.

• Weeks 1 and 2: scoping.
• Weeks 3 and 4: the prototype.
• Weeks 5 to 10: three build sprints.
• Weeks 11 and 12: the first users.

This breakdown shifts slightly depending on the product. Two things stay fixed: a usable version every two weeks, and a decision based on what users do.

When the product relies on an AI model, one question comes before all the others: can the model do the task with your data? The POC answers it before you commit to the build.

We take a sample of your real data, test several models on the target task, and measure the share of usable answers. If the result is good, the MVP is built on a verified foundation. If it is not, you find out within a few weeks, and we look for another angle: a narrower task, human review, or a product without AI.

The POC relies on the same benchmark as an LLM integration.

Both are built with the same method, and each fits a different situation.

• The MVP is for when you do not yet know whether the product will be used: a new service, a product to sell, a tool whose use is still a hypothesis. Twelve weeks to find out.
• The business application is for when the use is known and your teams are waiting for the tool: an internal process to equip, access rights to manage, existing data to bring across. Four months for a usable tool.

If in doubt, scoping settles it. A software vendor launching a product almost always starts with an MVP, as we describe for B2B SaaS vendors. An SME equipping an existing process goes straight to the application. If the interface matters as much as the function, UX design from the Digital practice comes in as well.

An MVP can conclude that it is time to stop. What you paid for remains useful: the code, the accounts and the data are in your name, the tested user journeys and the business rules are written down, and the usage data says why.

If you need to convince investors, the MVP brings what a demo does not: real usage data. It does not, however, prove performance under load or acquisition cost at scale, since the first users almost always come from your own network. Presenting it as proof that the product scales backfires on whoever presents it.

If the decision is to go further, you can hand the next phase to us, hand it to another team or hire: everything is documented so that whoever takes over does not have to start with an investigation.

Take a typical situation: an SME that receives orders from its business customers by email and by phone, and wonders whether an online ordering portal would be used.

• The question written down during scoping: will customers who order every week use the portal rather than email, enough to free up the time spent on data entry?
• The prototype shows the ordering journey to a few selected customers, before a single line of code is written.
• The build is limited to that journey, with AI where it is useful: reading an order sent as an attachment and offering it pre-filled.
• The first users are a handful of real customers, and we look at how many come back to order through the portal.

If few come back, the portal does not deserve to be extended, and you found that out in twelve weeks. If they do come back, the next phase is costed on usage data.

We apply this method to our own product, CoBIos, the AI agent we co-built with the Orléans Commercial Court Registry for accounting and law firms.

• The need came from the Registry: teams that spend a large part of the day searching for, checking and citing a text, and for whom an answer without a source is unusable.
• The rule was settled first: answer from the texts, cite the source every time, and say when the answer is not in the sources.
• The product now has four modules that can be deployed separately: sourced search, document checking, follow-ups, and preparation of review files.
• It is now opening to pilot firms: each pilot covers one module and a small team, and what comes next is decided on the time actually saved.

This is the path we propose for your product: a precise question, real users, a decision based on what they do. How firms use CoBIos is set out on the AI for accounting firms page.

An MVP handles real data from the first weeks, and we treat it like the data of a product in production. A data processing agreement (DPA) is signed with the contract, everything is hosted in France by default, or on your own infrastructure when the sensitivity of the data requires it, and no model is trained on your data. The POC is run on a sample you choose, anonymized where necessary.

GDPR, the EU AI Act and what happens when the model gets it wrong are set out on our AI guarantees and data sovereignty page.