I've sat through a lot of conversations where someone says "we need to build an MVP" and means three completely different things. Sometimes they mean: we need to prove this concept works technically. Sometimes: we need something to show investors. Sometimes: we need to ship a product to paying customers.
These are very different things. The code you write, the decisions you make, and the time you spend change dramatically depending on which one you actually need.
The definitions that actually matter
Proof of Concept (POC): Demonstrates that something is technically feasible. The audience is typically internal — your team, a technical co-founder, a potential investor who needs to see that the idea can work. A POC doesn't need to scale, handle edge cases, or be deployable to real users. It just needs to prove the core mechanism works.
Typical output: A working demo, often hardcoded, with no real backend, no auth, no production infrastructure.
Prototype: A high-fidelity mockup or limited interactive demo of what the product experience will feel like. Not necessarily functional — often a Figma prototype or a partially-working UI with simulated data. The audience is typically early users or investors who need to see the experience, not the technical implementation.
Typical output: Clickable Figma, or a frontend-only app with mocked APIs, no real data layer.
Minimum Viable Product (MVP): A real product that does one thing well enough for real users to pay for (or at least use meaningfully). It has auth, real data, real workflows. Not polished — but complete enough for the core user journey to work end-to-end.
Typical output: Deployed application, real users, real data, real feedback loop.
Why the confusion matters
The problem with conflating these is that you end up building the wrong thing for your actual goal.
If you need to validate investor interest, you need a prototype or a POC — something that communicates the vision quickly. Building a full MVP to impress investors is usually overkill; they're making a bet on the vision and the team, not the codebase.
If you need to validate market demand, you need an MVP — something real users can actually use and tell you whether it solves their problem. A prototype won't give you this signal. Users know it's a mock. Their feedback is imagined, not actual.
If you need to prove technical feasibility to a potential hire or co-founder, you need a POC. It can be rough. It just needs to show that the hard part is solvable.
A quick diagnostic
| Your goal | What you need |
|---|---|
| Show investors the vision | Prototype or polished POC |
| Validate technical feasibility | POC |
| Get first real users | MVP |
| Test pricing / willingness to pay | MVP or a pre-sell landing page |
| Get product-market fit feedback | MVP |
| Hire a technical co-founder | POC (show them something real) |
The MVP trap most founders fall into
The most common mistake is building an MVP that's too big. "Minimum" gets interpreted as "everything we plan to build, but fast" rather than "the smallest thing that tests our riskiest assumption."
The right question is: what is the riskiest assumption in our business, and what's the smallest thing we can build to test it?
If your riskiest assumption is "users will pay for X," your MVP just needs to let users try X. It doesn't need user profiles, notifications, team workspaces, an admin panel, or export functionality.
Every feature beyond the core assumption test is a bet. You're betting that users will love the core enough to care about the extras. Often they don't — because the core assumption was wrong and you need to pivot. If you've already built six features around a flawed core assumption, the pivot is expensive.
What we typically build for each stage
POC requests tend to look like: "Can you build a working demo of core mechanism that I can show at a pitch next week?" The output is usually a single screen or a few screens, hardcoded, no real backend, but visually polished enough to communicate the idea.
Prototype requests tend to look like: "We have a Figma file and we need it to feel real for a user interview." We build the frontend with mocked data — it looks and feels like the product, but nothing writes to a real database.
MVP requests are the most involved: real auth, real data model, real user flows, deployed to a subdomain. This is where framework choices matter. Vue + Nuxt + Firebase or Supabase is our default because it's the fastest path from zero to a deployed, scalable-enough MVP.
If you're trying to figure out which stage you're at and what you actually need to build next, drop us a message. That's a conversation worth having before you write a line of code.