Building an MVP sounds simple in theory: build the smallest possible thing, ship it, learn from users, iterate. In practice, most MVPs never launch. They get stuck in scope creep, perfectionism, or analysis paralysis.
I've shipped enough MVPs to know what actually works. Here's the process I follow, step by step.
Step 1: Define the core hypothesis
Before you write any code, you need to answer one question: what are you betting on? Every product is a bet that a specific group of people has a specific problem they'll pay to solve. Write that down in one sentence.
If you can't, you're not ready to build. You need more research, more conversations with potential users, more clarity on the problem. Building software is expensive — don't start until you know what you're testing.
Step 2: Identify the critical path
The critical path is the shortest sequence of steps from "user signs up" to "user gets value." Everything else is a distraction.
For a project management tool, the critical path might be: create account, create project, add task, mark task complete. That's four screens. Everything else — team collaboration, notifications, integrations, reporting — is not your MVP.
Map the critical path. Build only that. If a feature isn't on the critical path, it doesn't exist yet.
Step 3: Choose ymy stack deliberately
Your tech stack should be based on what you (or your team) know well, what serves the product's needs, and what you can maintain long-term. This is not the time to try a new framework because it looks interesting on Hacker News.
For most web MVPs, I use Next.js, TypeScript, and PostgreSQL. It's boring. It works. I can move fast because I know the tools cold.
For mobile, the choice between cross-platform (React Native) and native depends on your product. If you need device-specific features, go native. If you need to move fast and serve both platforms, cross-platform saves time and money.
Step 4: Set up the foundation right
This seems counterintuitive for "move fast" mode, but spending a day on proper project setup saves weeks later. That means:
- A clean repo structure with sensible conventions
- CI/CD from day one (push to deploy, not manual deploys)
- Basic error monitoring (you need to know when things break)
- Environment management (dev, staging, production)
Skipping this feels faster in week one. By week four, you're debugging in production because you don't have a staging environment and deploying manually because you never set up CI.
Step 5: Build in sprints with weekly demos
I build in one-week sprints. At the end of every week, there's a working demo. Not a slide deck. Not a Figma mockup. Working software that you can click through.
This keeps everyone honest. It surfaces problems early. It prevents the "I've been building for three months and have nothing to show" situation that kills projects.
Step 6: Ship ugly, then polish
Your MVP does not need to be beautiful. It needs to work. Users will tolerate an ugly interface if the product solves their problem. They will not tolerate a beautiful interface that doesn't work.
I design clean, functional interfaces — not polished ones. The difference matters. Clean means intuitive layout, readable text, clear actions. Polished means custom animations, brand-specific design language, and pixel-perfect everything. Clean takes days. Polished takes weeks.
Ship clean. Polish later, after you know the product works.
Step 7: Launch and measure
Launch means putting the product in front of real users and watching what happens. Not friends and family — actual target users who have the problem you're solving.
Before you launch, define what success looks like. Pick 2–3 metrics that tell you whether the MVP is working:
- Are users completing the critical path?
- Are they coming back?
- Are they willing to pay (or take a concrete action)?
If yes, you have something. If no, you have data to inform the next iteration.
Step 8: Iterate based on data, not opinions
After launch, you'll get feedback. Some of it will be useful. Most of it will be feature requests that have nothing to do with your core hypothesis. Ignore the feature requests. Focus on the data.
Are users dropping off at a specific step? Fix that step. Are they using the product differently than you expected? That's valuable — investigate why. Are they not coming back? That's the biggest signal. Either the problem isn't painful enough, or your solution doesn't solve it well enough.
The timeline
A well-scoped MVP with a focused team typically takes 8–12 weeks from kickoff to launch. That's not 8–12 weeks of building — it's 1–2 weeks of discovery, 1 week of architecture, 5–8 weeks of building, and 1 week of launch prep.
If your MVP is going to take longer than 12 weeks, your scope is too big. Cut features until it fits. The goal is to learn, not to build a complete product.
Common mistakes
Building too much. The most common MVP mistake. If your MVP has more than 5–7 core screens, you're building too much.
Skipping user research. Building based on assumptions instead of conversations with real users. Talk to at least 10 potential users before writing code.
Perfectionism. Spending weeks on edge cases and polish instead of shipping. Your MVP will have bugs. That's fine. Ship it anyway.
No success metrics. Launching without knowing what you're measuring. If you can't define success, you can't tell if you've achieved it.
Going solo when you shouldn't. Building an MVP alone takes 3–5x longer than with a focused team. If you have the budget, invest in a team that's done this before.
The bottom line
An MVP is a learning tool, not a product. Its job is to test your hypothesis as quickly and cheaply as possible. Everything else — features, polish, scale — comes after you've proven that people want what you're building.
If you're ready to build, I can take you from idea to launched MVP in 8–12 weeks. I've done it before, and I know what to skip and what to get right.