You have a real problem to explore, access to people who can react to a first version, and enough context to choose one useful path.
First working version
Build a first working version.
For founders with an idea, a manual process, or an early product that needs a focused first version.
What this includes
A focused first release, from goal to working path.
Each engagement centers on one clear goal. The output is working software plus enough context to keep making good decisions.
- 01A clear first-version goal
A short written map of the goal, people, and riskiest assumption.
- 02Key screens and the main user path
Clear states and a shared definition of what done means.
- 03Responsive design and core implementation
Implementation carried through the core path, not only the happy screenshot.
- 04Demo rhythm, testing, and handoff
A handoff that explains what shipped and what deliberately did not.
Process and deliverables
Make the next useful step concrete.
The work stays focused on a decision, a path, and the material needed to keep moving.
- 01Clarify the user, problem, and decision the first release should support.
A written artifact keeps the goal and constraints visible.
- 02Map the smallest end-to-end path, including empty, error, and handoff states.
The mapped path makes states and boundaries easier to discuss.
- 03Build, test, and demo the path so the next product decision has evidence.
A clear next-step note records decisions, risks, and ownership.
Is this a fit?
Good work starts with a useful boundary.
You need a broad platform, a long feature catalogue, or a guaranteed market result before learning from real use.
Choose the first evidence
MVP vs prototype: choose the evidence you need.
A prototype, no-code build, freelancer, in-house team, and MVP can each be sensible depending on what you need to learn and who will own the next step.
- PrototypeChoose a prototype when you need to test the flow, language, or visual direction before committing to production behavior. It can answer a narrow question without carrying a complete working path.
- MVPChoose an MVP when a real user should complete the core job in working software and their use will inform what you build next.
- No-code, freelancer, or in-houseNo-code can fit a process that stays inside configurable tools; a freelancer can fit a clearly bounded specialist task; an in-house team can fit an ongoing roadmap with internal ownership.
If you are still deciding what the first release should prove, a Product Clarity Sprint can turn the rough scope into a buildable next decision.
A related build
A first version makes the next decision easier.
A first working version should make learning possible without pretending to prove more than it can. If the path is still uncertain, a Product Clarity Sprint can make the scope more useful before implementation.
Vouch is an example of a focused SaaS workflow carried through collection, approval, and publishing.
Read the Vouch case studyFor a second view on the decision, browse the Reordo decision guides.
Questions founders ask
A few useful answers before we start.
What counts as an MVP?
An MVP is the smallest end-to-end path that lets a specific user complete an important job and gives you a reason to decide what comes next. It is not a collection of unfinished features.
What do you deliver during MVP development?
We deliver a written first-version goal, the core screens and states, a working implementation of the useful path, testing notes, and a handoff that records what shipped and what stayed out of scope.
Should I start with an MVP or a Product Clarity Sprint?
Start with an MVP when the user, problem, and first path are clear enough to build. Choose a Product Clarity Sprint when the scope keeps changing or the next build decision is still unclear.
A useful next step
Tell us what you want to build
Share what you know about the goal, the current product or process, and what you want to improve.