One of my biggest mistakes as an independent builder is easy to repeat: I imagine the finished company before I have proved the first useful action.
It is the same clarity problem that pushed me to rebuild Cozon DigitalWorld around one clear niche: when everything is treated as important, it becomes difficult for people to understand the main value.
A marketplace idea quickly becomes listings, payments, delivery, referrals, verification, reviews, advertising, messaging and a mobile app. Each feature sounds reasonable by itself. Together, they can keep the product unfinished for months.
I have learned that an MVP is not a weak version of a large platform. It is the smallest complete version of one valuable journey.
I start with one sentence
Before opening my code editor, I try to complete this sentence:
This product helps this specific person do this specific job without this current difficulty.
If I cannot make the sentence clear, the product is probably still too broad.
For a local marketplace, the first job may be helping a buyer discover a nearby seller and contact them. That does not automatically require a custom chat system, built-in delivery network and wallet on day one.
The sentence gives me a boundary. A feature belongs in the first version only if the main journey fails without it.
I map the shortest complete journey
Next, I write the steps a real user must complete.
For example:
A seller creates a basic profile.
The seller publishes an item or service.
A buyer searches or browses.
The buyer views enough information to decide whether to make contact.
The buyer contacts the seller through a familiar channel.
This is a complete journey. It creates a result that I can observe.
A referral leaderboard may help growth later, but the marketplace can still prove its value without it. A custom messaging system may give me more control later, but WhatsApp may be enough to test whether buyers want to contact sellers at all.
I separate needs from impressive features
I place features into three groups:
Required now: without it, the core journey cannot be completed safely.
Useful later: it improves a journey that users have already shown they want.
Interesting, but unproven: it sounds exciting, but I do not yet have evidence that it solves an important problem.
Security and trust do not automatically go into the “later” group. A basic first version still needs appropriate authentication, input validation, privacy information and a way to handle abuse. Small scope should reduce unnecessary features, not basic responsibility.
I use manual work deliberately
Automation feels like progress because it produces more code. Sometimes a manual process teaches me more.
If only a few sellers need approval, I can review them manually before building a complicated verification engine. If users need support, a clear contact channel may be enough before I build a ticketing dashboard.
Manual work becomes a problem when it is unsafe, inconsistent or impossible to manage. Before that point, it can reveal what should eventually be automated.
The goal is not to keep the product manual forever. The goal is to avoid automating assumptions.
I define what success means before launch
“People liked the idea” is difficult to use as product evidence.
I prefer a small measurement connected to the core journey. Depending on the product, that might be:
ten sellers complete a listing without my help;
five buyers contact a seller;
most users finish the main form on a mobile device;
three users return and perform the main action again;
support questions reveal the same missing information.
The number does not need to be huge. It needs to tell me whether the product created its intended value.
I keep a “not now” document
Removing a feature can feel like losing an idea. I avoid that feeling by keeping a simple list of features that are not part of the current version.
Each item includes the problem it may solve and the evidence that would justify building it.
For example:
Build internal messaging when users regularly fail to complete conversations through the existing contact method, or when safety and moderation require communication to remain on the platform.
That is more useful than writing “add chat later.” It explains the condition that should bring the feature back.
My final scope test
Before development continues, I ask five questions:
Who is the first version for?
What is the one result they should achieve?
What is the shortest safe path to that result?
Which features can be handled manually or postponed?
What evidence will tell me whether to continue, change direction or stop?
Reducing scope does not reduce ambition. It gives ambition a realistic starting point.
I would rather release one complete journey, watch real people use it and learn from the result than spend months building ten connected systems around a guess.
Reducing the first version also limits unnecessary spending. That matters when, as I explained in The Financial Anxiety of Building Products Before They Make Money, financial pressure starts trying to write the product roadmap.