Minimum
The smallest scope that can test the core assumption. Every extra feature delays the answer and costs money before you know whether it is needed.
MVP DEVELOPMENT
Not a prototype to throw away, and not a two-year platform you do not need yet. Just the smallest product that can teach you something real.
WHAT AN MVP IS
All three words matter. The common alternative is maximum, fragile, and half-finished: too big to ship quickly and too unstable to learn from.
The smallest scope that can test the core assumption. Every extra feature delays the answer and costs money before you know whether it is needed.
A product that genuinely works: users finish the task, data persists, and it survives more than a scripted demo.
Real software that people can use unsupervised, not a clickable prototype or a feature list waiting for another team.
SCOPING
The features required to test the core assumption. Usually smaller than founders expect.
Genuinely valuable work that can wait until real users have shown what they need.
Features that feel essential in planning but rarely matter once people use the product.
WHAT I BUILD
The build is deliberately small, but it is still a product people can use and your next developer can continue.
A direct conversation about what is essential, what is later, and what should not be built yet.
Focused product design around the version one journey rather than a speculative design library.
Front end, backend, database, authentication, and payments where the model needs them.
Enough visibility to see what people are actually doing after launch.
A production-ready first release, complete codebase, documentation, and ownership for your team.
DEBT YOU CAN LIVE WITH
Acceptable shortcuts
Shortcuts that become rewrites
AFTER LAUNCH
You receive a working release, the full codebase, and documentation written for whoever takes it forward. The next step may be a new hire, a second project, or the useful discovery that the original assumption was wrong.
All three outcomes are valid. A focused MVP makes the third one inexpensive, and makes the first two much easier to act on.
“The point of version one is a useful answer, not a large codebase.”
The operating principle
COMMON QUESTIONS
The commercial and product decisions to settle before the feature list starts growing.
Typically six to twelve weeks depending on the scope. A two-week quote usually leaves out the work that makes it viable.
It is scope-dependent and fixed before work begins. Changes are repriced before they happen.
No. You keep your equity.
Yes. That scoping work is one of the most valuable parts of the engagement.
That becomes a new project, with a fast start because the product and codebase are already familiar.
Usually web, unless the product truly depends on the phone. Web is faster to build, change, and launch.
Tell me the assumption you are testing. I will show you the smallest thing that can test it and what that build should cost.