Eight weeks is not a long time. It is long enough to go from a well-defined idea to a working product that real users can interact with — if you are disciplined about what you are building, ruthless about what you are not, and willing to use AI tools the way they are actually meant to be used: as a multiplier on your own judgment, not a replacement for it.
This is not a theoretical framework. It is the process I used to build Kidomo — an AI-powered gamified financial education platform for children — and that I have refined across advisory engagements with founders at different stages. The eight-week timeline is real, not aspirational, provided the conditions are right. I will tell you what those conditions are, and what will break the timeline if they are not met.
Before week 1: the work that makes eight weeks possible.
The founders who fail to hit an eight-week MVP timeline almost always fail in the same place: they start building before they have clarity on what they are building and why.
AI tools are extraordinarily good at generating outputs quickly. They are not good at compensating for an unclear brief. If your problem definition is vague, your AI-assisted build will produce a polished version of your confusion faster than you could have produced it manually. That is not progress.
Before you start the eight-week clock, you need three things defined with enough specificity that you could hand them to someone else and they would build the same thing you have in mind.
One or two sentences describing the specific problem you are solving, for whom, and why existing solutions are inadequate. Not "there is an opportunity in the financial education market" — "parents of 6–12 year olds have no engaging, age-appropriate way to teach their children about money that does not require significant parental time investment, and the tools that exist are either too dry to hold a child's attention or too shallow to build real understanding."
A specific description of the person who has this problem acutely. Not a demographic profile — a behavioural description. What are they doing today instead of using your product? What is the cost of that workaround? What would have to be true for them to change their behaviour?
This is the most important document you will write before week one. It is not a feature list — it is a definition of the smallest product that would genuinely solve the problem for your target user. The discipline of writing it forces you to make the trade-off decisions that will otherwise slow you down every day of the build.
A Minimum Product Definition answers four questions: What is the core user journey — the single path through the product that delivers the value you are promising? What does the product explicitly not do in its first version? What does success look like for a user in their first session? What does success look like for the product at the end of the eight weeks?
Spend a week on these three documents before you start building. The founders who skip this step and go straight to week one spend two of their eight weeks making decisions that should have been made upfront.
Validate before you build.
The most expensive mistake in early-stage product development is building something that solves a problem people do not have, or have but will not pay to solve. AI makes this mistake faster and cheaper to make — which sounds like progress but is not.
Before any code is written, use AI to compress the validation timeline.
A thorough competitive analysis that would previously take a week of manual research can now be compressed into a day. Use AI to map existing solutions, identify their limitations, and surface the positioning gaps your product could occupy. Do not treat AI output as fact — treat it as a starting point for your own verification. The value is in the speed of generating a comprehensive first draft, not in the accuracy of every detail.
Write out the assumptions your business model depends on — the ones that, if wrong, would mean the product does not work. Then use AI as a sparring partner: ask it to argue against each assumption, to identify the evidence that would confirm or refute it, and to surface the assumptions you have not named. This is one of the highest-value uses of AI in early-stage product development and one of the least discussed.
AI cannot do this for you. No tool replaces direct user conversations. Ten conversations with people who have the problem you are solving will tell you more about what to build than any amount of AI-assisted analysis. What AI can do is help you prepare better questions, synthesise your notes faster, and identify patterns across conversations more quickly. Use it for those things.
By the end of week two, you should have confirmed that the problem is real, that your target user is specific enough to find and talk to, and that your Minimum Product Definition reflects what users actually need rather than what you assumed they needed. If the MPD has changed, that is a good sign — it means the validation work did its job.
Build the core journey.
This is where AI tools change the economics of early-stage product development most dramatically.
The combination of AI-assisted development tools — I use Lovable and Claude extensively, alongside other tools depending on the stack — means that a non-engineer founder can now build a functional prototype of a relatively complex product in two weeks. An engineer founder can build it faster. What used to require a technical co-founder or a significant agency budget is now accessible to anyone willing to learn how to direct AI tools effectively.
The key word is direct. AI coding tools are not autonomous builders. They are highly capable executors of well-specified instructions. The quality of what they produce is directly proportional to the quality of the brief you give them — which is why the work done in the pre-week and weeks one and two matters so much.
Your Minimum Product Definition defines one primary user path. Build that path and nothing else in weeks three and four. Every feature that is not on the core journey is a distraction from the goal of having something testable by the end of week four.
AI tools make it easy to add features — easier than it has ever been. The temptation to build the second and third use case while you are in flow is significant. Resist it. The discipline of building only what is necessary to validate the core value proposition is what makes eight weeks possible.
In the early stages, what users experience matters more than how it works underneath. Build the interface — the screens, the flows, the interactions — before you build the infrastructure. This lets you test whether the experience is right before you commit to the architecture that will support it at scale. Changing a flow is cheap. Changing an architecture is not.
Use AI to maintain a running log of the product decisions you are making and the reasoning behind them. This sounds like overhead during a fast build — it is not. It will save significant time in weeks five through eight when you are iterating based on user feedback and need to reconstruct why a decision was made.
By the end of week four, you should have a working prototype of your core user journey. It will not be polished. It will have rough edges. It should be good enough that a real user can navigate it without guidance and experience the core value you are promising.
Test with real users.
The prototype you have at the end of week four is a hypothesis. Weeks five and six are about testing it.
Not friends and family — people who have the problem you are solving and have no social incentive to be kind about your product. How you find them depends on your market, but finding them is your job, not an AI tool's.
The most common mistake in early user testing is over-facilitating. If a user gets stuck, do not tell them what to do — note where they got stuck and why. The friction points in unguided use are your most valuable product signal.
After each session, use AI to help structure your notes, identify patterns across sessions, and generate hypotheses about what the feedback means for the product. The synthesis work that used to take days can now be done in hours, which means you can iterate faster within the two-week testing window.
If every user loves everything, either you have found product-market fit immediately (possible but rare) or your testing conditions are too comfortable (more likely). The feedback that is most valuable is the kind that tells you something you did not want to hear. Take it seriously and act on it quickly.
By the end of week six, you should have a clear picture of what is working, what is not, and what the two or three most important changes are. Not a list of forty improvements — two or three. The discipline of prioritising ruthlessly is what makes the next two weeks productive.
Iterate and stabilise.
The final two weeks are not for adding features. They are for making the core journey work reliably and well, based on what you learned in weeks five and six.
Users will forgive an MVP that does not do everything. They will not forgive one that does not do what it promises reliably. Stability and consistency in the core journey matter more than feature coverage at this stage.
Once the core journey is stable, use AI to generate edge cases — unusual inputs, unexpected user behaviours, failure scenarios — and work through how the product handles them. This is not about building for every edge case; it is about understanding where the product breaks and making conscious decisions about which breaks are acceptable at MVP stage.
Before the MVP goes to a broader audience, instrument it. Define the metrics that will tell you whether the product is working — not vanity metrics, but behavioural signals: completion rates on the core journey, return rates, the specific steps where users drop off. Use AI to help design the measurement framework and interpret early data. You cannot improve what you cannot measure.
The end of eight weeks is not the end of the product development process — it is the beginning. Before you release the MVP to a broader audience, define the three questions you most need to answer with the next wave of data, and the three features or improvements you will build if the answers are what you expect. This keeps the momentum of the eight-week build from dissipating in an unstructured post-launch period.
The conditions that make eight weeks real.
The eight-week timeline is achievable, but it depends on conditions that are worth naming explicitly.
Every day a decision waits for alignment is a day lost. Solo founders move faster than founding teams on the build phase, not because collaboration is bad but because decision latency is the most consistent timeline killer in early product development. If you are a team, define clearly who has final call on product decisions before week one.
Eight weeks of focused work on one MVP is achievable. Eight weeks of split attention across two projects is not. If you are running other commitments in parallel, extend the timeline rather than compromising the focus.
Something will not fit in eight weeks. The discipline to cut it — and to cut it early, before you have invested time building it — is the single biggest determinant of whether the timeline holds. Use your Minimum Product Definition as the reference point every time a new feature is proposed. If it is not on the core journey, it does not belong in the eight weeks.
The tools are available to everyone. The difference between founders who use them effectively and founders who do not is the ability to write a brief that produces useful output — which requires clarity about what you want and enough experience with the tools to know when the output is good enough and when it needs to be redirected. This is a learnable skill, but it takes deliberate practice. If you are new to AI-assisted development, factor in a steeper learning curve in weeks three and four.
What eight weeks produces — and what it does not.
At the end of eight weeks, you should have a working MVP that your core user can use to experience the primary value you are promising. You should have validated that the problem is real, that your solution is directionally right, and that there is a user willing to engage with it.
You will not have a scalable product. You will not have solved every edge case. You will not have built the features that will matter in six months. You will have built the thing you need to build next — which is the information that only a real product in front of real users can generate.
That is what an MVP is for. Eight weeks is enough time to get there, if you are honest about what you are building and disciplined about building only that.