Insights / Article / AI Prototyping and MVP Development
ArticleFrom prototype to MVP: what changes
A prototype shows that something can work. An MVP must work reliably for real users, with proper security, real integrations, named owners and monitoring from day one.
A successful prototype is a good day. The idea works, users like it and the sponsor wants more. The temptation is to give the prototype to more people and call it a product. That is where many promising projects stumble.
A prototype shows that something can work. A minimum viable product, or MVP, must work reliably for real users doing real work, every day. The gap between the two is not mainly about features. It is about security, integration, support and evidence. This article sets out what changes, so you can plan and budget for it honestly.
Different questions, different standards
A prototype answers one question: does this approach deliver value? To answer it quickly, teams take sensible shortcuts. They use sample data, a handful of test accounts, manual steps behind the scenes and a single developer who knows how everything fits together. None of that is wrong for a prototype.
An MVP answers a different question: will people use this, in their normal work, at a quality and cost we can sustain? To answer that, every shortcut must be either removed or consciously accepted. The table stakes rise because the consequences of failure rise. A prototype that breaks is an inconvenience. An MVP that breaks stops someone doing their job, or worse, exposes data it should not.
A useful rule of thumb
Expect moving from prototype to MVP to take more effort than building the prototype did. If the plan assumes otherwise, look for what has been left out.
Security and access
Prototypes often run on shared logins or a single service account. An MVP needs proper sign-in, ideally through the organisation’s existing identity system such as Microsoft Entra ID or Google Workspace, so that people use the credentials they already have and leavers lose access automatically.
Permissions matter just as much. Who can see which records? Can a regional manager see other regions’ customers? Can a user export data? Where an AI model is involved, check what data is sent to it, where that data is processed and whether it is retained. Your data protection lead should review the design before launch, not after a complaint.
Test these controls with real roles before launch. Ask a colleague from each user group to sign in and try to see something they should not. It is a quick exercise and it regularly catches permission rules that looked right on paper but behave differently in practice.
- Single sign-on through the organisation’s identity provider.
- Role-based permissions that mirror existing access rules in source systems.
- Encryption of data in transit and at rest.
- A clear record of what personal data is processed, where and for how long.
- Audit logs showing who did what, and when.
Integration and support
The prototype may have worked from a spreadsheet export refreshed by hand each Monday. An MVP must connect to the real systems: the ERP, the CRM, the document store. That means agreeing data flows with the owners of those systems, handling errors gracefully and deciding what happens when a source system is unavailable.
Support is the part most often forgotten. When a user hits a problem at nine on a Tuesday morning, who do they call? Name a product owner who is accountable for the MVP’s direction, a technical owner who keeps it running and a support route that users already know, such as the existing IT service desk. Write a short guide for the service desk so the first call does not end in confusion.
Agree what level of service the MVP needs. A tool used for a weekly planning task can tolerate a day of downtime; one used to quote customers in real time cannot. Being explicit about this shapes hosting choices, backup arrangements and how quickly the technical owner must respond, and it avoids paying for resilience the MVP does not need.
Monitoring and feedback
From the first day of the MVP, track three things: use, quality and feedback. Use tells you whether people are adopting it. Quality tells you whether it is doing the job well. Feedback tells you why.
For use, measure active users, frequency and the tasks they complete. For quality, measure the same success measures agreed for the prototype, now at greater scale, plus technical measures such as response time and error rates. For AI features, sample outputs regularly and have a knowledgeable person review them, because model quality can drift as inputs change.
Feedback should be easy to give. A simple thumbs up or down with an optional comment, built into the tool, will gather far more than a survey sent a month later. Review it weekly and tell users what you changed as a result. Nothing builds trust faster.
What can stay simple
An MVP is still minimal. It does not need every feature users have asked for, a polished design system or support for every edge case. Choose the smallest set of capabilities that lets a defined group of users do their real work, and make that set reliable. It is far better to serve thirty people well than three hundred people badly.
Limit the rollout deliberately. Start with one team or one site, learn for four to eight weeks and widen access only when use and quality measures are holding up.
Choose the first group carefully. They should do the work the MVP supports every week, be willing to give honest feedback and include at least one person who was not involved in the prototype. Their experience is the best evidence you will get about whether a wider rollout will succeed.
The prototype took six weeks. Getting it ready for the whole team took twelve, and almost none of that was new features. It was sign-in, integrations and support.
Technology director, logistics client
Planning the transition
Before committing, write a short transition plan covering each area above: security and access, integration, support, monitoring and the rollout group. Estimate effort for each, identify owners and agree success measures for the MVP phase. Present that to the sponsor alongside the prototype results. A clear-eyed plan at this point prevents the most common outcome of all: a good idea that never quite becomes part of how the organisation works.
Source: Intelliversal analysis.
