A first product should do one important job before it tries to do ten. We help you define the user, the workflow and the release boundary, then build and test against agreed acceptance criteria.
Deciding what goes in the first release
Must-have now
The workflow a first user needs to get value, and nothing that can wait. Every feature on this list has a reason tied to that user.
Later, on purpose
Features that are useful but not needed for launch go on a written list for the next release, so they are parked rather than forgotten.
Accounts, roles and data where needed
Sign-up, permissions, storage and integrations are included when the core workflow needs them, not by default.
Acceptance criteria
Each feature has agreed checks that decide when it is finished, written before development starts.
First users and feedback
Who the first users are
We agree who gets the first release, such as a pilot customer or a waitlist, so the scope fits the people who will use it.
How feedback comes back
In-app feedback, analytics events or scheduled calls, decided up front, so the second release is based on evidence.
What you get at the end
The working product
Deployed and tested against the acceptance criteria.
Access and documentation
Admin access, environment notes and a walkthrough, so another developer can pick it up.
What expands an MVP
These are the usual reasons a first release grows. Each one is a decision you can make on purpose.
More than one user type at launch
Each role adds screens, permissions and tests.
Payments and billing
Subscriptions, invoicing and refunds add integration and testing work.
Integrations
Every outside system connected at launch adds build and test time.
Native mobile apps
A responsive web app is usually enough for a first release; separate app-store apps are a larger project.
From first call to handover
01 Scope call
We define the user, the core workflow and the release boundary.
02 Written proposal
Features, exclusions, acceptance criteria, price and milestones.
03 Build in sprints
Two-week sprints with a working build to review at each milestone.
04 Launch to first users
Deployment, handover and the feedback plan agreed in scope.
What we build it with
Define your first release
Bring the idea and who it is for. We will help you decide what goes in version one and what waits.
Discuss your MVP