Software / MVP Development
MVP Development
A first version built to answer a specific question, not a shrunken copy of the product you eventually want. Software, and hardware where the idea depends on it — we have taken our own device from schematic to measured result, so a connected-product MVP does not have to be split across two suppliers.
What an MVP is for
An MVP is an experiment. If it is not designed to be capable of disappointing you, it is not one.
The useful question is never "can this be built" — almost anything can be built. It is whether a specific assumption holds: that people will use it, that the physics works at the range you need, that the integration is possible, that someone will pay. A good MVP is the smallest thing that answers that, and it is designed backwards from the question.
Most MVPs fail on scope rather than engineering. Features accumulate because they are easy to agree to, the build stretches, and by the time it ships it is too expensive to throw away — which is exactly what an experiment must remain cheap enough to do. The discipline is deciding, in advance, what you will not build.
Two kinds we build
Software MVP
A product idea that needs users in front of it
A working application with the one path that matters built properly and everything else deliberately absent. Real data, real accounts, real deployment — because an experiment run on a prototype that cannot handle a real user answers the wrong question.
Connected-device MVP
An idea that only exists once hardware is involved
Sensor, board, firmware, and whatever service sits behind it — enough of each to test the assumption the product rests on. This is the harder case, and the one where being able to change the hardware and the software in the same week matters most.
The second kind is where most agencies stop and most hardware houses have not started. If your idea needs both, splitting it across two suppliers means every uncertainty becomes a negotiation about whose problem it is.
We have done this to ourselves
Wavegrasp is our own MVP, taken the whole way: custom acquisition boards, an eight-channel synchronized microphone array, real-time firmware, direction-of-arrival estimation running on the device, an enclosure modelled around the array, and clock distribution to a second node. It was built to answer one question — whether passive acoustic sensing can locate a low-altitude drone accurately enough to be useful.
The answer so far is measured and published with its limits stated: 1.44° mean absolute bearing error over 197 controlled events, and 2.3° median error against an RTK-GPS-tracked drone at close range. An earlier array geometry was built, characterized, and abandoned when a simpler one measured better. That is what running the experiment properly looks like.
How it runs
- 01
Name the question
What has to be true for this to work, and which single assumption is most likely to be wrong. Everything after this is in service of testing that.
- 02
Agree what is out
The exclusion list is written down and it is longer than the feature list. This is the step that keeps an MVP an MVP.
- 03
Build the thin path
One route through the product, built to a standard that can survive contact with a real user or a real environment — not a demo that works when held correctly.
- 04
Get a result and decide
Put it in front of the thing that will judge it, and treat the outcome as data. Continue, change direction, or stop — all three are successful outcomes for an experiment.
What you get
- Source, hardware files where applicable, and deployment in your accounts and your repositories — not held hostage in ours.
- Documentation written during the build, so the next team is not archaeology-dependent.
- An honest account of what the MVP did and did not establish, including the parts that went badly.
- A view on what it would take to go from here to a real product, and whether the codebase should survive that transition or be thrown away. Sometimes it should be thrown away.
Related
Have an idea that needs testing?
Bring the assumption you are least sure about. You get an honest read on the cheapest way to test it — including when the answer is that you do not need us to find out.
Discuss a project →