Blog
An approach for a 4-week MVP
Speed and a narrow scope decide whether an idea gets tested or stays on a slide. A minimum viable product has to be real enough to use, and small enough to finish. At JKAP we build that kind of MVP on a four-week clock: research, design, build, and a launch that produces evidence.
The team behind that work has nearly two decades of combined technical and project experience. The point of the four weeks is a product people can try, and a decision about what to build next.
Why four weeks
A traditional build often takes six to twelve months before a user sees anything useful. Learning waits, and the cost is already sunk.
Four weeks is long enough for research, UX, engineering, and a test, and short enough that the team cannot hide extra features inside the plan. The same window is used for SaaS and AI products when the goal is a working slice, not a full release.
Principles we do not trade
Validate before the build grows
Interviews, a clear problem, and a market check come before extra code.
Ship the smallest useful set
Features that do not change the user's outcome wait.
Learn faster than you add
The MVP is an experiment with a success measure, not a thin version 1.0.
Keep users in the loop
Interviews, prototype tests, and live use decide the next change.
Leave a path to scale
The architecture should be able to grow, so the MVP is not thrown away.
Four weeks, four phases
Discover, Design, Build, then Launch and Learn. The work inside each week changes with the product. The sequence is what keeps the stakeholders looking at the same plan.
Week 1 Discover and define
The first week is clarity: the problem, the user, and the scope.
Interviews
Stakeholders and users, focused on the problem and where it shows up.
The market around it
How the problem is being handled today, from public research and the products already in market.
One persona, one journey
The painful steps where this MVP can be useful.
MoSCoW on the feature list
Must, should, could, and won't. Only the musts stay in the four weeks.
A definition of success
Activation, task completion, or time saved. Named before the build starts.
Week 1 ends with a problem statement, a target persona, a short feature list, and an agreed meaning of success.
Week 2 UX, flows, and architecture
The problem becomes a journey and a technical plan.
End-to-end flows
From first touch to the moment of value, in as few steps as the problem allows.
Wireframes
Low to medium fidelity, revised with internal review and a user look.
A feasibility pass
For AI or data products: sources, model approach, and integrations, before coding.
The simplest stack that will hold
APIs, integrations, and where it will run, sized for the MVP and the next step, not a distant platform.
A backlog the team can start
Design and engineering lined up so build work can overlap where it is safe.
By the end of week 2, engineering can move without rewriting the same screens.
Week 3 Build the core
The MVP becomes something a person can click through.
The happy path first
One complete journey working early, before the edges.
Only the week 1 musts
Nice-to-have work stays out of the sprint.
Integrations and analytics
Third-party services and basic measurement, so launch day has data.
Test as it lands
Critical usability and reliability issues are fixed during the build.
A baseline for AI
A first model or an external AI service, enough to prove the value before heavier customization.
Week 3 ends with a product a small group can use from start to finish.
Week 4 Test, launch, and learn
The last week puts the MVP in front of the people it was built for.
Usability tests
Target users completing the key tasks, with the drop-off watched rather than assumed.
Stabilize what blocks them
High-impact bugs and friction, not a new feature list.
A limited rollout
A controlled audience, so the data is real and the risk stays small.
Metrics and a short survey
Behavior and satisfaction, not only a launch announcement.
A report and a roadmap
What to improve, what to scale, and whether to continue, change direction, or stop.
Week 4 ends with a live MVP, assumptions that held or did not, and a direction for the next phase.
What you have after four weeks
A working slice
One problem, one user segment, running in a real environment.
A signal
Evidence the problem is real, and that people use the solution in a way that matters.
A baseline
Usage metrics and event tracking already in place.
A next backlog
The following four to twelve weeks ordered from user feedback, plus a decision to scale, change, or stop before a large build.
That is how a team avoids funding a full product and learning later that the market does not care.
Why speed and focus matter
Most ideas fail for reasons a team can see early: weak validation, too much built too soon, and feedback that never changes the plan. A shorter MVP tests the message and the feature before the cost of a long build is locked in.
A shared four-week outcome also cuts the meetings that debate a hypothetical product. The time goes into the build and into what users actually do.
Pitfalls we leave out
Building before anyone is asked
Features nobody requested are the usual result.
Calling a cheap version 1.0 an MVP
Without a test, it is just a smaller product.
Launching with no measure
Vanity numbers do not say whether the MVP worked.
Engineering for a scale you do not have
The stack should be the simplest one that can test the idea.
Waiting for perfect
The delay removes the reason to do an MVP at all.
When four weeks is the right window
It fits when you need to move and still want a structured test. SaaS products, internal tools, and AI workflows are the usual fit, because one deep slice can be delivered end to end.
A new product line, a new market, or an AI use case can be tried with real users before the investment grows. The value of the four weeks is the decision that follows, not only the speed of the build.