A proof of concept tests whether something is technically possible. A prototype tests whether a design works for users. An MVP tests whether people will actually use and pay for the product. They answer different questions, cost different amounts, and are built for different audiences — and using the words interchangeably is one of the more expensive vocabulary problems in software, because it produces quotes and expectations that do not match.
What is a proof of concept?
A proof of concept answers a single technical question: can this be done at all?
It is built for engineers and technical stakeholders, not users. It is usually ugly, often a script rather than an application, and deliberately narrow. It has no user interface worth the name, no error handling, no security posture, and no future — a PoC is a thing you throw away once it has answered its question.
You need one when your product depends on a technical assumption that nobody has verified. Can we extract structured data from these documents accurately enough to be useful? Can this model run fast enough on hardware the client will actually buy? Can we integrate with this legacy system at all, given what its API does?
If the honest answer is "we're fairly confident it works, we just haven't tried" — that is exactly when a PoC earns its cost, because the alternative is discovering the answer halfway through a full build.
Cost: typically days, not weeks. It is the cheapest artefact here, and skipping it when you needed one is among the most expensive mistakes available.
What is a prototype?
A prototype answers a design question: does this make sense to the people who will use it?
It is built for users and stakeholders, and it usually does not work. A clickable Figma flow is a prototype. So is a fake interface wired to hardcoded data. The point is to put something in front of a human early enough that changing it is still cheap.
You need one when the interaction model is genuinely uncertain, when you are asking users to change how they work, or when you need to align stakeholders on what is being built before anyone writes code. Prototypes are also the most persuasive artefact for raising money or getting internal sign-off, precisely because they look real.
What a prototype cannot tell you is whether people will use the thing sustainably or pay for it. Users are consistently enthusiastic about prototypes and inconsistent about products. Enthusiasm in a usability session is not demand.
Cost: typically days to a couple of weeks, mostly design rather than engineering.
What is an MVP?
An MVP answers a market question: will people actually use this, and will they pay?
It is built for real users doing real work, and unlike the other two, it has to genuinely work. Real data, real accounts, real failure handling, real security. It is small — one user type, one workflow, deliberately incomplete — but the part that exists is production software, because you cannot learn anything trustworthy from users who are pretending.
That is the distinction people miss. An MVP is not a rough version of a product. It is a narrow version of a product, built properly. Roughness in the wrong places (data loss, security holes, broken payments) does not teach you about demand; it teaches you that your software is broken.
Cost: in Australia, typically $9,000 to $15,000 AUD for a scoped build from a small senior team, and $2,000 to $6,000 for narrower single-workflow products. We break the drivers down in what an MVP actually costs.
Which one do you actually need?
Work backwards from what you are most unsure about.
| Your biggest uncertainty | Build | Rough cost |
|---|---|---|
| "Is this technically possible?" | Proof of concept | Days |
| "Will people understand and want to use it?" | Prototype | Days to 2 weeks |
| "Will people use it for real and pay?" | MVP | $2K–$15K AUD |
| "How do we scale what's already working?" | None of these — a product roadmap | — |
Most founders overestimate technical risk and underestimate market risk. They ask for a proof of concept when the technology is well understood and the real question is whether anyone wants it. If your product is a CRUD application over a familiar domain with standard integrations, the technical risk is close to zero and a PoC teaches you nothing you did not know.
The sequence is not compulsory either. Plenty of products go straight to a small MVP because the technology is proven and the interaction model is conventional. Others need a PoC first because everything downstream depends on one unresolved technical question. Running all three in order, by default, is a way to spend three budgets before learning the one thing that mattered.
Which of these can qualify as R&D?
This is where the distinction stops being semantic and starts having financial consequences.
The R&D Tax Incentive distinguishes core R&D activities — experimental work whose outcome cannot be known in advance, conducted to generate new knowledge — from supporting activities directly related to them. Companies with aggregated turnover under $20 million can claim a 43.5% refundable tax offset on eligible expenditure.
Read against those definitions, the three artefacts look very different:
A proof of concept is often the most likely to qualify, because it is by definition an experiment against an unknown outcome. That is close to the shape the program describes — provided you documented the hypothesis, what you tried, and what happened, at the time.
A prototype is usually design work, not experimental technical work. It typically does not qualify on its own.
An MVP is mixed. The novel parts may qualify; the conventional parts almost certainly do not. Claiming an entire MVP build as R&D is a common error and an unhelpful one, because it invites scrutiny of the portions that were genuinely eligible.
Two things apply regardless: register within 10 months of the end of the income year, and remember that eligibility is decided by AusIndustry and the ATO on your registered R&D advisor's assessment — never by your development agency. We go deeper in funding your MVP with the R&D Tax Incentive.
The practical takeaway
Before commissioning anything, write down the single question you most need answered. If it is technical, build a proof of concept. If it is about usability or alignment, build a prototype. If it is about demand, build an MVP — narrow, real, and in front of users quickly.
And whichever you build, keep the record of what was uncertain and what you learned. It is the raw material of both your next decision and, potentially, your R&D claim.
That framing is where our MVP development engagements start: what is the riskiest assumption, and what is the smallest real thing that tests it.
Not sure which one you need?
If you have an idea and are not certain whether it needs a proof of concept, a prototype or a real MVP, that is a useful conversation to have before you spend anything. Book a discovery call and we will work out which question matters most and what it would actually take to answer it.
Sources
- ATO, Rates of R&D tax incentive offset
- ATO, Refundable and non-refundable offsets
- business.gov.au, Overview of the R&D Tax Incentive — core vs supporting R&D activities, registration deadline
Cost ranges reflect Zatersio's own fixed-scope pricing, not an industry survey. This article is general information, not tax advice — R&D eligibility is determined by AusIndustry and the ATO.
