Build enough to learn something real.
A first release should answer one business question. We help you pick that question, build the smallest complete product that answers it, and read the result with you.
Start with the question.
Will patients book online instead of phoning the front desk? Will a sales team keep stock figures current if the tool sits in front of them? Will people pay for a report they currently assemble by hand? An MVP exists to answer something like that, and a working product answers it far better than a long feature list.
So before talking scope, we ask which assumption the release needs to test. If every feature on the list is called essential, the question probably isn't settled yet, and we work through priorities with you before anyone starts building.
One question, one complete path, and an agreed way to read the result.
Small scope still means finished work.
An MVP cuts features. It keeps the parts that make software safe to put in front of paying customers.
Where the line usually falls.
Reserve and pay for one service
Picture a business testing whether customers will book online. Release one needs a complete booking, payment and staff-confirmation flow for a single service. Packages, a full catalogue and loyalty points can wait. Our page on booking platforms covers the wider build.
One spreadsheet, not ten
Take an operations team running orders from a shared sheet. The MVP moves that one sheet into an application with proper records and roles. Cross-department reporting comes after people trust the new system.
Build one side properly
Two-sided products rarely launch both sides in full. Often suppliers are onboarded by hand at first while the buyer side is built properly, so the test is whether buyers act.
One task with checkable answers
If the idea rests on AI, the first release runs it on one task where your team can check the output, and a person reviews results before customers see them.
Once people are using it.
Watch what users actually do
Before launch we agree what to measure: sign-ups, completed tasks, where people drop off, what they ask support. The product records enough to answer the question you set.
Review the evidence together
We compare what happened with what you expected. Sometimes the answer is plain; sometimes it points to a better question.
Decide the next release
Build on it, change direction or stop. The parked list from the first scope becomes the starting point, re-ranked by what you learned. Our guide to planning your first product has more on this sorting.
Is an MVP a throwaway prototype?
It can be, though most of ours are production software with a small scope, built to be extended. We agree the intended life of the first version at the start, because a clickable prototype and a release paying customers depend on are built and priced differently.
Investors want to see more than one feature. What then?
Designs and a clickable prototype can show where the product is heading without building all of it. Keep the vision in design and the working release honest. Product design covers that work.
Can you keep improving it after launch?
Yes. Usage and feedback go into a continuing roadmap, and we can host and support the product while it grows.
What should your MVP prove?
Tell us the assumption on WhatsApp or by email and we will help you size the smallest useful release.