What a Prototype Actually Is
A prototype is a low-fidelity, rapidly constructed representation of a product idea designed to test a specific hypothesis or demonstrate a concept to stakeholders. It is not production software. It does not need to work reliably under real conditions. It does not need to handle edge cases, errors, or scale. Its only job is to answer the question: is this idea worth pursuing further? Prototypes take many forms. A clickable Figma mockup with no backend is a prototype. A Wizard of Oz experiment where a human manually fulfils requests that will eventually be automated is a prototype. A Python notebook that demonstrates an AI model working on sample data is a prototype. A Notion document with screenshots that simulates a user flow is a prototype. What makes something a prototype is the intent - it is a disposable artefact used to generate insight, not a foundation to build on. The cost and timeline for a prototype should be measured in days, not weeks. If you are spending more than two weeks building a prototype, you have probably started building an MVP without intending to. Good prototyping disciplines include setting a strict time box before you start, defining the single question you are trying to answer, and agreeing in advance that the code or materials are disposable. Founders who get attached to prototype code and try to ship it as a product accumulate technical debt before they have validated that the product is worth building. SpeedMVPs sometimes helps clients build technical proof-of-concept prototypes for AI features in a few days specifically to answer the question of feasibility before committing to a full MVP scope.
What an MVP Actually Is
A Minimum Viable Product is a real product - functional, usable, and deployed to real users - with the minimum set of features needed to validate whether there is genuine market demand. The keyword is viable: it must actually work well enough that users can derive value from it, form an opinion about it, and decide whether to pay for it or recommend it. A broken, unreliable, or confusing product does not validate demand; it validates poor execution. The MVP is not the prototype plus a bit more polish. It is a deliberate product decision about what the minimum core value exchange is between the product and its users. For an AI document analysis tool, the MVP might be: upload a PDF, ask questions about it, get accurate answers. Not: multi-document analysis, version history, team sharing, custom branding, and an API. Those features come after you have validated that people actually want to ask questions about their PDFs and get answers. An MVP should be built with production-quality code, proper security, a real database, and a real deployment environment. It needs to be reliable enough that a user who has a good experience will come back tomorrow and find it working. This is the key distinction from a prototype. The MVP will form the foundation that features are added to, so the technical decisions made during MVP development - framework choice, data model, authentication approach - will compound over time. At SpeedMVPs, our AI MVPs take 2-3 weeks to deliver from 8,000 GBP because we scope tightly to the genuine MVP, build production-quality code, and do not pad the timeline with features that do not serve the core validation hypothesis.
What a Full Product Actually Is
A full product is what the MVP becomes after product-market fit has been validated and the investment in additional features, polish, and scalability is justified by evidence. It includes the breadth of features that serve the full range of target users, the UX refinement that comes from real user feedback, the integrations that enterprise customers require, the performance characteristics needed at scale, and the operational infrastructure to support a growing user base reliably. The full product is not a fixed destination - it is a continuous process of improvement guided by user data, market feedback, and commercial objectives. What distinguishes it from an MVP is the depth of investment justified by validated demand. Building full-product-level features before validation is the definition of building something nobody asked for. The graveyard of venture-funded startups is full of technically sophisticated products that solved problems in ways users did not want, at price points they would not pay, with complexity that onboarding could not overcome. For UK-based enterprise technology products, the full product phase typically involves compliance work that the MVP deferred: formal GDPR data protection impact assessments, Cyber Essentials or ISO 27001 certification, penetration testing, accessibility audits against WCAG 2.2, and integration with enterprise SSO and procurement systems. These are legitimate investments once the product has paying customers; doing them before is expensive gold-plating of an unvalidated hypothesis.
Cost and Timeline Comparisons
Understanding the realistic cost and time investment at each stage helps you allocate runway appropriately and make staged investment decisions. Prototypes, when properly scoped as disposable validation artefacts, should cost between 1,000 GBP and 5,000 GBP and take one to two weeks. If you are using no-code tools like Framer, Figma interactive prototypes, or Glide, the cost can be lower still. A technical AI prototype - one that demonstrates model feasibility on real data - might be a paid engagement of a few days with a specialist. MVPs built by experienced specialists cost between 8,000 GBP and 50,000 GBP depending on scope and complexity. A tightly scoped AI SaaS MVP with authentication, one or two core features, payment integration, and a clean deployment typically falls in the 8,000 to 20,000 GBP range. Broader MVPs with multiple user types, complex data models, and integrations with external systems push toward the higher end. SpeedMVPs delivers AI MVPs in this range in 2-3 weeks because we scope tightly and work with a focused team that knows the patterns. Full products are ongoing investments and the costs scale with the size of the product and team. A funded startup building a full product might spend 200,000 to 500,000 GBP in the first year of post-validation development with a small in-house team or agency. Enterprise software projects can run into millions of pounds. The key principle is that the investment at each stage should be proportional to the confidence level that the product is building toward validated demand - not aspirational feature lists.
Common Mistakes at Each Stage
The most common prototype mistake is scope creep into MVP territory. A founder who sets out to build a clickable mockup ends up integrating a real backend because they want to show investors something more impressive. The prototype becomes half-finished software: too polished to be disposable, too incomplete to be useful. This usually costs more than building a proper MVP would have and answers fewer questions. The most common MVP mistake is building too many features. The word minimum in MVP is doing real work. Teams that add features because they are worried about customer objections, want to match competitor features, or are trying to impress investors inevitably delay launch, add complexity, and dilute the signal from early user feedback. A genuinely minimal product that validates one core hypothesis with ten users is worth more than a feature-rich product that takes six months to launch with no real user validation. The most common full product mistake is premature investment in scalability and enterprise features before the core product has proven retention. Infrastructure that can serve 10 million users is impressive but useless if the product cannot retain 100 users. Compliance certifications that cost 50,000 GBP are premature if the product has not found the customer segment they are intended to unlock. Build for scale and compliance requirements when they become blockers to growth, not in anticipation of theoretical growth.
How AI Changes the Stage Calculus
AI products have slightly different stage dynamics compared to traditional SaaS. The prototype stage matters more for AI products because the feasibility of the core AI feature is genuinely uncertain in a way that traditional CRUD features are not. You should answer the question 'can the AI actually do what we are promising?' before investing in an MVP. A technical proof of concept on your actual data - not curated demo data, but the messy real data your users will bring - is a valuable prototype artefact specific to AI products. The MVP stage for AI products requires more thought about the feedback loop. How will users tell you when the AI is wrong? What is the fallback when the AI fails? How will you measure AI quality improvement over time? These questions should be answered at MVP stage, not deferred to the full product phase. Building an AI MVP without a mechanism to capture user corrections and quality signal is building without the inputs you need to improve the product. The full product phase for AI products often involves model evaluation infrastructure, fine-tuning pipelines, and the regulatory considerations that come with deploying AI in regulated sectors. Under the EU AI Act, high-risk AI systems in employment, credit, healthcare, education, and critical infrastructure contexts have conformity assessment and documentation requirements. If your AI MVP is in one of these categories, the path from MVP to full product includes compliance investment that is worth scoping early.
When to Skip the Prototype Stage
Prototyping is valuable when there is genuine uncertainty about whether the concept works or whether users want it. If you already have strong evidence of demand - an existing user base asking for a feature, a contract signed pending delivery, a well-understood problem in a domain you know deeply - you may be able to skip the prototype and go directly to MVP. The prototype exists to generate evidence; if you already have the evidence, the prototype is a delay. For AI features specifically, skipping the prototype is risky if you have not validated the model's capability on representative data. But if you have already run experiments, have benchmark results on your data, or are using a well-understood model pattern for a well-understood task type, you can move directly to MVP with confidence. The judgment call is about what you already know versus what you still need to discover.
Verdict
The decision about what to build first is a question about what you need to learn next. Build a prototype when you need to answer whether the concept is feasible or whether users want it at all. Build an MVP when you have enough evidence that the concept is worth validating with real users under real conditions. Invest in a full product when paying users have demonstrated that the MVP delivers enough value to justify continued investment. The most expensive mistake is skipping stages. Building a full product before you have validated MVP demand wastes months and six-figure budgets. Building an MVP before you have answered basic feasibility questions with a prototype wastes weeks and five-figure budgets. Each stage answers a specific question with an appropriate level of investment - respect that discipline and you will move much faster toward a product that actually works in the market. At SpeedMVPs, we work with founders at both the prototype and MVP stages. We can help you run a quick technical feasibility study or deliver a complete AI MVP in 2-3 weeks from 8,000 GBP with full code ownership. If you are unsure which stage you are at, that is exactly the conversation to have with us first. Get a free consultation at speedmvps.co.uk