Prototype and MVP development
Find out whether people want your idea before you pay to build all of it.
We build a working prototype or MVP of the one part your idea depends on, put it in front of real people within weeks, and give you a clear record of what they did and what to build next.
Available on its own, or as part of The Prototype Sprint.
In practice
What this actually is
A prototype is a working-enough version of an idea that people can click through and react to, built in weeks rather than months. You use it to find out whether the thing is worth building before you commit the budget to building it.
What we do
- Concept definition
- What exactly is being tested, and what answer would change your mind.
- Clickable prototype
- Screens somebody can actually move through, not a slide deck.
- User testing
- Put in front of real people, with what they did written down.
- Technical feasibility
- Whether the hard part is possible, checked before it is promised.
- Commercial testing
- Whether anybody will pay, and roughly what for.
- Investor and demo material
- Something to show in a room, rather than describe.
- Findings and recommendation
- What we learned, and whether we would build it.
- Scope for version one
- If it goes ahead, the smallest useful build and what it costs to own.
Make the idea easier to decide on
Something people can see, use and respond to.
A tangible version of the idea - something to test with, demonstrate, argue about, and make a properly informed decision on.
Let us explore itWhat actually kills a new product
The best-known number in this field is that most startups fail because they build something the market did not need. It has been quoted for over a decade, and when the research was redone with several times more data it did not soften - poor product-market fit came out as the largest single cause of failure by a clear margin, ahead of timing and ahead of unit economics.
And this is the part that should be encouraging rather than grim. "Nobody wanted it" is not a verdict you have to wait for the launch to receive. It is knowable beforehand, cheaply, by putting something in front of real people and watching what they do - and yet most startups scale before they have validated anything at all. Most of the risk in a new product is concentrated in one or two assumptions, and both can usually be tested in weeks for a fraction of the build.
A prototype is not a small version of the product. It is an instrument for answering a specific question, and it is allowed to be crude everywhere the question does not live. That distinction is the whole discipline, and it is why a good prototype is usually finished before a founder expects and looks worse than they were hoping.
43%
Of failed startups died of poor product-market fit - the largest single cause when the research was rerun across 431 failures.
70%
Ran out of money, which reads as the cause and is the symptom. The capital went into building the wrong thing well.
70%
Of startups scale before they have validated anything, which is the most expensive order to do it in. The cheapest step in the process is the one most often skipped.
The discipline
A prototype answers one question. These four decide which
Work through them in order and the scope writes itself. Skip them and you build a small version of everything, which answers nothing and costs more than it should.
The risk
What would sink this
- The assumption everything rests on
- What you believe about the customer
- What you believe about the money
- Which of these is least proven
This holds it up
The smallest test
The cheapest honest answer
- What must be real
- What can be faked convincingly
- What is out entirely
- How quickly it can be in front of someone
This holds it up
The build
Real enough to be used
- A working flow, not a slide deck
- Convincing where it is seen
- Fast to change
- Instrumented from the start
They see this
The verdict
You decide with evidence
- What people did, not what they said
- Where they stopped
- Whether anyone tried to pay
- Build, change, or stop
They see this
The verdict has to be allowed to be no. A prototype that cannot fail is not a test, it is a demonstration - and a demonstration is what you commission when you have already decided, which is a fine thing to want but a different and more expensive product.
Measurement
How you will know it is working
MVP development South Africa is measured on whether it answered the question, not on what got built. These are the signals we watch.
What we report on
- Whether people completed the core flow without being helped through it
- Where they stopped, named by step
- Whether anybody came back unprompted
- Whether anybody tried to pay, or asked when they could
- A clear verdict on the original question - proceed, change, or stop
Before you ask
The questions that come up first
How long does a prototype take?
MVP development South Africa founders buy from us is usually a few weeks rather than a few months, and if the answer is longer than that the scope has drifted from a question into a product. The length is set by how much has to be genuinely working before the test is honest, which is the conversation we have at the start.
What if the answer is no?
Then it is the cheapest no you will ever buy, and you have it before the real money is committed. We will give you that answer plainly, along with what was learned and whether a different version of the idea is worth testing. A prototype that is not allowed to fail is not a test.
Can the prototype become the real product?
Sometimes parts of it, and that is a bonus rather than the plan. Prototype code is built to move fast and be discarded, which is exactly what makes it cheap. We will tell you honestly what is worth carrying forward once we know the answer, rather than pretending upfront that none of it will be rewritten.
How is this different from just building the thing?
A prototype answers one question, cheaply, before the answer costs you a build. A full build assumes the question is already settled. If you have one assumption keeping you up at night - whether anyone will use it, whether the workflow holds, whether the integration is even possible - test that first. If you already know, skip this and build.