01/
Existing evidence
What is already known, observed, or assumed, and where the gaps actually are.
MVP Development
A first release shaped around the decision it needs to support.
Start with the decision
An MVP is one possible next test—not the
automatic starting point
Working software is not always the right first test. We compare it against research, a prototype, and a pilot before committing to a build.
TIER01
Research or observation
TIER02
Prototype or technical proof
TIER03
Pilot or manual service
TIER04
MVP or first release
Evidence and decision
Name the product question and the decision
it should inform
The first release should exist to answer a specific question, not to demonstrate general progress.
02/
The riskiest assumption
The one belief that, if wrong, invalidates the release, named explicitly rather than implied.
03/
The first reachable user
Who will actually encounter this release, and under what real conditions.
04/
What the release must prove
The specific decision this evidence should inform, stated before scope is drawn.
Scope boundary
Minimum scope does not remove data, privacy, security,
or legal responsibility
A smaller release still requires proportionate responsibility; "minimum" describes scope, not permission to cut corners.
(001)
Minimum describes scope, not responsibility
A smaller release still requires proportionate privacy, security, accessibility, and data-integrity decisions; "MVP" is not permission to skip them.
(002)
One complete workflow, not a feature list
The release preserves one useful path end to end rather than partial pieces of several.
(003)
Manual work is a legitimate scope choice
Operator-run steps can stand in for automation the first release does not yet need.
(004)
The next decision is planned before launch
Stop, revise, deepen, expand, or continue — the criteria are set before evidence arrives, not after.
Technology decisions
MVP speed &
scale stack
The stack follows the requirement, not the other way round. These are the categories this engagement typically has to decide.
01
Next.js App Router
02
Supabase & PostgreSQL
03
TypeScript
04
TailwindCSS
05
Stripe Billing
06
PostHog Telemetry
Possible scope
Preserve one useful workflow from
trigger to result
The exact scope depends on the decision and evidence needed. None of the following should be assumed automatically.
Assumption and risk rankingTest-form selectionFirst-user and context definitionScope, non-goals, and deferred-work record
Core workflow implementationManual or automated operator work as scopedData, privacy, and security baselineProportionate quality and accessibility
Release audience and environment definitionSupport and operational boundaryRollback and recovery readinessLegal and data-handling review
Measurement plan and event definitionsQualitative evidence collection planDecision criteria for the next stepAccess and documentation handoff
First-release decisions
Choose the least
costly credible test
Every first-release decision trades something specific for something else. The useful choice is the one whose reason is understood.
01
Does the next question actually need code?
A prototype, technical proof, or pilot can sometimes answer the riskiest assumption with less cost and exposure.
02
Automate now or run it manually first?
A manual step can be faster to ship and easier to change while the workflow is still uncertain.
03
Who actually needs to see this first?
A narrow, controlled release usually produces more useful evidence than a broad one at this stage.
04
How much confidence justifies release?
Waiting for certainty can cost more than the risk it avoids; the bar should match the consequence of being wrong.
Inspectable outputs
Leave behind decisions, working artefacts,
evidence, and ownership
Deliverables should make the release's purpose and evidence visible and testable.
01/
Evidence and decision record
The assumption, test form, and decision this release is meant to inform.
02/
Working release
The one complete workflow, built to a quality proportionate to its consequence.
03/
Measurement plan
What will be observed, how, and its limitations, agreed before launch.
04/
Next-decision record
Stop, revise, deepen, expand, or continue, with the criteria that will decide it.
Delivery and engagement
Start with the decision work or carry the
release through engineering
The starting engagement should resolve the riskiest assumption before committing to broader scope.
01
BOUNDED DISCOVERY
Decision and scope definition
A bounded stage to name the assumption, test form, and first release scope.
02
FIXED-SCOPE MILESTONE
Defined first release
A project-shaped engagement to build and ship the scoped MVP.
03
STAGED RELEASES
Staged evidence gathering
Release to a narrow audience first, expanding only as evidence supports it.
04
CONTINUOUS CADENCE
Continuation into ongoing work
What follows a supportive result — a new bounded phase or ongoing product engineering.
Fit and routing
Choose the service that owns
the defining question
MVP Development is the right starting point when stage selection is the defining question. A different service may own the wider need.
01/ ALTERNATIVE
Custom Software Development
Choose this when the requirement is understood and the question is engineering scope, not stage selection.
02/ ALTERNATIVE
SaaS Product Development
Choose this when the product model, not the release stage, is the defining question.
03/ ALTERNATIVE
UI/UX Product Design
Choose this when the next useful test is research or a prototype, not working software.
04/ ALTERNATIVE
Product Modernisation & Improvement
Choose this when the product already exists and needs change, not a first release.
Frequently Asked Questions
MVP Development questions,
answered clearly.
Technical delivery and architecture details. Key decisions regarding code quality, integrations, and handoff rituals.
No. Research, observation, a prototype, technical proof, manual service, pilot, or broader first release may answer the next important question with less cost or exposure.