Hypothesis and cut list
We write what you are testing, what success looks like, and what is explicitly out of v0. The cut list is a contract, not a suggestion.
Rapid MVP Development
Rapid MVP development is focused design and build of the smallest credible product that generates meaningful learning, delivered with controlled scope.
Part of Creation. For founders and product leads who need evidence in market, not a feature graveyard. Read What an MVP design partner actually does.
The growth risk on MVPs is scope: "minimum" becomes a second product. We hold one priority journey tied to a hypothesis. Studios that sell MVP well (ustwo's pilot language, regional peers like VentureDive) name the learning goal and the cut list upfront. Same discipline here.
Scope creep kills learning
An MVP that tries to be v1 ships late, costs more than planned, and still does not answer the question you raised capital to answer. Stakeholders add "just one more thing." Integrations multiply. The team cannot tell whether the wedge failed or the build was too fat to test.
We design and build for a decision: double down, pivot, or stop, with evidence, not hope.
Who it's for
- Founders with a validated wedge and early capital who need a credible pilot fast
- Product leaders who must show traction before the next funding or board cycle
- Teams where speed to learning is the advantage. And honesty about what is out matters more than a demo deck
- Orgs coming out of Research & Discovery with a hypothesis ready to test in market
Problems that inflate MVPs
- "MVP" secretly means full v1 with every stakeholder wishlist
- No written hypothesis, success is undefined until after launch
- Platform chosen for hype, not fit, lock-in discovered too late
- Happy-path UI only. First real user hits an error nobody designed
- No analytics or success criteria, learning is anecdotal
- Build path ignores migration when the hypothesis wins
Prototype vs PoC vs MVP
We agree which one you need before we build:
- Prototype: demonstrates an idea or interaction; not necessarily production-ready - Proof of concept: tests technical feasibility; may not be user-facing - MVP: real users get value; you get learning tied to a metric or decision
Confusing these is how "two-week MVP" becomes a quarter-long build.
What we tackle
Single priority journey
One path from entry to value. Designed with empty, loading, error, and success states, not a screen gallery. Depth on when the journey is dense.
→ Learn more about Single priority journeyPlatform honesty
Custom, low-code, or no-code on the lightest fit stack — with ownership, constraints discovery, and migration notes. We recommend custom when the platform is the wrong bet.
Analytics and launch plan
Instrumentation for the hypothesis, a launch checklist, and who owns post-launch review. Learning without measurement is storytelling.
Post-launch recommendation
What to build next, what to kill, and whether to migrate stack. So the MVP is a stage, not a dead end.
What you buy
- Written hypothesis and scope cut list
- Functional spec and UI for one priority journey (states included)
- Build on the lightest honest platform
- Analytics hooks for the metrics that matter to the decision
- Launch plan and post-launch recommendation memo
- Typical sizing as a focused sprint or short project once scope is clear, see Rates
How it works
1. Cut: hypothesis, success criteria, and what is explicitly out. *Deliverable: scope thesis + cut list.* 2. Design the journey: wires, UI, states for the one path that tests the wedge. *Deliverable: functional spec, hi-fi UI, state notes.* 3. Build light: implement on chosen stack; instrument the hypothesis. *Deliverable: working product + analytics plan.* 4. Launch & decide: ship, review evidence, recommend next stage. *Deliverable: retro memo, double down, pivot, migrate, or stop.*
Many focused MVP slices run over weeks once scope is clear. Duration tracks integrations, unknowns, and build path.
Engagement shapes
- MVP sprint: one journey, tight cut list, ship to learn (often weeks)
- Research → MVP: Research & Discovery first when the wedge is still fuzzy
- MVP → product: phased Product & Interface Design when the hypothesis wins
- Audit first: UX Audit + AI Readiness when you are modernizing before adding scope
- Platform-first MVP: constraints discovery, shortlist, exit/migration notes when the stack choice is the risk
Where it leads
- Hypothesis wins → Product & Interface Design, Design Systems
- Platform outgrows no-code → custom build or Legacy UX Modernization path documented at MVP stage
- Wedge wrong → stop with evidence; cheaper than a year of building the wrong thing
Fit / not for
For learning-sized products with a named hypothesis. Not for "MVP" that secretly means full v1. Not for demos with no plan to put real users on the product.
Platform honesty (no-code & low-code)
- Constraints discovery — data model, auth, compliance, integrations, and who owns the build after launch
- Platform shortlist — fit vs fashion with tradeoffs in plain language
- Exit notes and migration triggers — what would force a move to custom, and what to preserve when you leave
- No-code and low-code are a build path inside Rapid MVP — not a separate philosophy page
Frequently asked questions
What is a minimum viable product (MVP)?
An MVP is the smallest real, usable product that delivers value to users and generates meaningful learning. Its job is evidence, not completeness.
How do you keep an MVP from becoming a full build?
By locking scope to one priority journey tied to a hypothesis. And holding that line. Anything that does not test the hypothesis waits until after launch. The cut list is written and signed before build starts.
How long does an MVP engagement take?
Many focused MVP slices run over weeks once scope is clear. Duration tracks integrations, unknowns, and build path. We estimate with visible assumptions, see [Rates](/rates).
Do you always use no-code?
No. We pick the lightest fit, no-code, low-code, or custom: with ownership and migration in mind. Fashion is not a strategy.
Do we need research before an MVP?
Not always: but if the wedge is still argued in meetings, [Research & Discovery](/services/clarity/research-discovery) is cheaper than building the wrong journey. We will tell you which door fits on a scoping call.
What happens after launch?
We recommend a structured review against the hypothesis: what to double down on, pivot, or stop. The MVP is a decision tool, not a throwaway demo.
Can you design and build, or only design?
Both. Most MVP engagements include a working build on the honest stack. Handoff-only is possible when you have eng capacity and want specs first.
How is this different from Rapid Prototyping?
A prototype demonstrates; an MVP serves real users and generates learning you can act on. We clarify which you need before quoting.
Scope an MVP
Bring the hypothesis, the one journey that tests it, and what you will measure. We will tell you if the scope fits a sprint or needs a cut.
Book a project call