MVP. Minimum Viable Product. One of the most talked-about and most misunderstood ideas in the startup world.
"Let's build an MVP" usually collapses into one of two mistakes. Either you cram in so many features that you've built a mini product (not really an MVP, more of an MBP: Maximum Bloated Product), or you strip it back so far that nobody wants to use the thing.
At AppDuce we build our own products with the MVP approach, and everything here comes from doing that rather than from a textbook.
What MVP is not
A few misconceptions worth clearing up first.
An MVP is not a half-baked product. "Minimum" doesn't mean "low quality." You build less, but what you do build should work properly. An app with terrible UX isn't an MVP, it's just a bad product.
An MVP is not the final product. Shipping one doesn't mean you're done. It's a starting point, a learning tool, a way to collect data from real users.
An MVP isn't always an app. Sometimes it's a landing page. Sometimes a Google Form. Sometimes a process you run by hand. Anything that tests demand before you write code counts.
The real definition
An MVP is a product built with the minimum effort needed to test a hypothesis.
That word, hypothesis, is the whole point. Before you build anything, you need an assumption to check. "Will people pay for solution Y to problem X?" That's the question you're after, and an MVP is the cheapest way to get an answer.
Step-by-step MVP process
Step 1: Clarify the problem
Before "what are we building?" comes "whose problem are we solving?"
A quick test: describe the problem in one sentence. If it isn't as clear and specific as "people struggle with X," it isn't defined well enough yet.
Bad example: "People have trouble organizing their lives." Good example: "EV drivers in Turkey can't find the nearest compatible charging station."
Step 2: Identify target users
"Everyone" can't be your user. Who's the first group?
The way to narrow it: find the people who feel the problem most sharply. For Şarj Asistanı, our first users were EV owners driving between cities, not the ones charging at home overnight but the ones hunting for a charger on the road.
Step 3: Define core value proposition
What exactly does your app promise the user? One thing. Not two, not three. One.
Şarj Asistanı's core promise: "Find the nearest charging station in seconds." No filtering in the first version, no route planning. Just pins on a map. That was it.
Step 4: Ruthlessly cut features
Brainstorm every feature you can think of and write them all down. Then run each one through a single test.
For every feature, ask: does the core promise still work without it?
If the answer is yes, that feature is out of the MVP. Only what's essential to the core promise makes it into version one.
A typical MVP has 3 to 5 features. Much more than that and it isn't an MVP anymore.
Step 5: Build (fast)
MVP development should take 2 to 6 weeks, and app development cost scales right along with that timeline. If you're pushing past three months, either the scope is too big or you're not really building an MVP.
Be pragmatic about the tech:
- Cross-platform? React Native + Expo
- Quick backend? Firebase or Supabase
- Use a pre-built UI kit instead of designing from scratch
- Skip automation for now and handle by hand whatever you can
Step 6: Get it to real users
Don't leave the MVP sitting in a drawer. Ship it. Not to everyone, though, just to a small, targeted group.
Where to find them:
- Relevant Reddit and forum communities
- Direct messages to your target audience on LinkedIn
- Niche Facebook and Telegram groups
- Product Hunt, Indie Hackers
- Your own network (but only the people who are actual target users)
Step 7: Measure and learn
From week one, keep an eye on these:
- Acquisition: how many downloaded or signed up?
- Activation: how many reached the first moment of value? (Found their first charging station, created their first task, and so on.)
- Retention: how many came back a week later?
- Qualitative feedback: what are they telling you? What do they want? What are they complaining about?
Watch behavior, not headcount. 50 people downloading and using it every day beats 1,000 who download it and never come back.
MVP traps
The "one more feature" trap. "If we just add this, it'll be so much better." That sentence has killed more MVPs than anything else. Every added feature stretches the timeline, a longer timeline drains motivation, and the learning you were after gets pushed further out.
The perfectionism trap. Button color, font choice, animation speed: none of it matters at the MVP stage. Does the product work? Does the user find value in it? That's what counts.
The "a competitor already does it" trap. A competitor existing is proof that demand exists. You can come at it from another angle, serve a different audience, build a better experience. That's opportunity, not a reason to quit.
The scaling trap. At the MVP stage, don't sit around asking "what if we get a million users?" Find your first 100. Scaling is a good problem, and it doesn't need solving before you're anywhere near it.
Real-world MVP examples
Dropbox: the first MVP was just a video. No product behind it. The video asked, "would you use something like this?" and 75,000 people signed up for the waitlist. Then they built it.
Airbnb: the founders rented out their own apartment. No platform, no site. They took photos and posted them on Craigslist to see whether anyone actually wanted this.
Şarj Asistanı (us): pins on a map. No filtering, no routes, no accounts. 200 downloads in the first week with zero marketing. The problem was real.
What happens after MVP?
An MVP tells you one of three things:
- The problem is real and the solution is right. Keep going. Add features based on what users tell you.
- The problem is real but the solution is wrong. Pivot. Try a different solution.
- The problem isn't real. Stop. Move on to a different problem.
The third is the hardest to swallow and the most valuable thing you can learn. Finding it out in four to six weeks, instead of after months on the wrong problem, is a huge win.
In short
An MVP isn't a product strategy. It's a learning strategy. The goal isn't to ship something perfect, it's to gather real data from real users in the least time possible.
Build less, build the right thing, ship it fast, and learn faster.
We've taken plenty of first steps ourselves, every one of them on our own products, and we write down what we learn along the way.