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
Start with the goal, then build the useful 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.
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 studyQuestions 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.