How to Actually Build an MVP
Most guides on MVP development are long on theory and short on specifics. This one is different. Here's the actual process we use when building MVPs for startups — from the first conversation to a live product in users' hands. Not what the textbooks say. What works.
Step 1: Define the One Thing You're Testing
Before any design or code work, you need to identify the single most important assumption your product is built on. This is harder than it sounds, because most founders have many assumptions operating simultaneously.
A useful exercise: finish this sentence — "Our product will succeed if and only if [one thing is true]." For most products, that one thing is something about user behaviour: will people pay for this? Will they use it frequently enough? Will enough of them trust a new platform with their data or their money?
The MVP you build should be designed specifically to test that one thing. Everything else is secondary.
Step 2: Define the Minimum Feature Set
Once you know what you're testing, the question becomes: what is the fewest number of features that lets us run a real test with real users?
List every feature you've thought of for the product. Then go through the list and ask: does this feature directly enable us to test our core assumption? If yes, it stays. If no, it goes in the "phase 2" list. You will be surprised how short the must-have list is when you're honest about this.
A common mistake is confusing "needed to launch" with "needed to test." Authentication, a way to receive payment, the core user flow, and a way to communicate with users — those are needed to test. The profile customisation, the settings page, the referral system, the admin analytics dashboard — those are not.
Step 3: User Flow Mapping
Before you open a design tool or write a line of code, map every screen and every interaction in the product on paper or a whiteboard. User arrives → what do they see? What can they do? What happens next?
This exercise consistently surfaces requirements that weren't obvious from the feature list alone. It also reveals screens that seem necessary but actually aren't — because you can see the full flow and realise that the edge case you were planning to handle doesn't apply to the MVP scope.
Map the happy path first — the flow that a user who does everything right will follow. Then map the main failure paths: what happens if the payment fails? What if they enter an invalid email? These aren't edge cases — they're experiences most users will have, and leaving them unhandled produces a bad product, not a lean one.
Step 4: Design (Weeks 1–2)
Design for an MVP should be thorough enough that the user experience is clear and usable — but not so polished that you're spending three weeks perfecting the animation on a button hover state. The goal is clarity, not beauty.
We typically produce wireframes (low-fidelity layout of every screen) in the first week, then one round of visual design that applies the brand identity to the wireframes. We do not do multiple rounds of visual design iteration in MVP projects — not because the design doesn't matter, but because visual polish is the last thing to optimise before you know whether the product is going in the right direction.
Get the design in front of three to five potential users before development starts. Not for approval — for reality checking. Can they understand what the screen is asking them to do? Do they get confused anywhere? These conversations take two hours and save two weeks of rework.
Step 5: Development (Weeks 3–10, Depending on Scope)
Development runs in two-week sprints. At the end of every sprint, there's a working build on a staging environment that you can test on your phone or laptop. This is not optional — it's how you catch problems when they're still small.
The Tech Stack for Most MVPs
For web applications and web-plus-mobile products, we use Next.js (React) for the frontend, Node.js for the backend, MongoDB or PostgreSQL for the database, and deploy on AWS or DigitalOcean. This stack is fast to build with, has an excellent developer ecosystem, scales well once you start getting real users, and is easy to hand off to future developers.
For mobile-first products, we use React Native — one codebase for iOS and Android. This is faster and cheaper than building native iOS and Android separately, and the quality is indistinguishable from native for most product types.
What Gets Built in What Order
Backend and API first — the data model, authentication, and core business logic. These decisions are hard to change later, so getting them right early is worth the focus. Frontend second, building from the most critical flow to the least critical. Testing and QA throughout, not just at the end.
Step 6: Beta Testing (2 Weeks)
Before you launch publicly, give the product to ten to twenty real users who represent your target audience. Not friends. Not colleagues. People who actually have the problem you're solving.
Watch them use it, or conduct structured user testing sessions. The bugs and UX issues that emerge in the first two hours of real user testing will surprise you — they always do. Two weeks of beta testing before launch will save you from the experience of launching to crickets because the onboarding flow is confusing or the payment isn't working for a specific bank.
Step 7: Launch and Measure
Launch does not mean "release to the public and see what happens." Launch means: define the metrics that will tell you whether your core assumption is true or false, set up the analytics to measure those metrics, acquire your first users through a specific channel, and then measure.
For most B2B MVPs, the signal you're looking for is paying customers. Not sign-ups. Not positive feedback. Paying customers. For consumer products, it's often retention — do people come back? For marketplaces, it's activity on both sides. Be honest with yourself about what constitutes a true validation versus a comforting signal.
Realistic MVP Timelines
- Simple web app MVP (5–8 core flows, basic auth, no complex integrations): 8–12 weeks
- Medium web app MVP (multi-role, payments, third-party integrations): 12–20 weeks
- Mobile MVP in React Native (both platforms): 10–16 weeks
- Marketplace MVP (buyer + seller sides, basic transactions): 16–24 weeks
Anyone quoting significantly below these timelines is either scoping a simpler product than what you described or planning to take shortcuts on testing and QA. Ask them to show you a comparable product they've built in the quoted timeline.
The Most Common MVP Mistakes
- Building too much — adding features "while we're at it" is how MVPs become six-month projects. Scope discipline is everything.
- Not testing with real users before launch — founders who skip beta testing are gambling on their own assumptions about usability.
- Treating positive feedback as validation — people are polite. "This looks great!" is not the same as "I would pay for this." Test with real purchasing decisions wherever possible.
- Not defining success metrics before launch — if you don't know what you're measuring before you launch, you'll interpret whatever happens as success.
- Building a product for investors, not users — an MVP that impresses investors but doesn't teach you anything about real users is not an MVP. It's a demo.