Should we develop a simple prototype version first, or should we aim to deliver a minimum viable product (MVP) that's ready for use? The first approach offers advantages in terms of time and code optimization, while the second provides quick user feedback. Which one would you prefer and why? Let's discuss.
What approach do you prefer when developing an MVP?
👁️ 38 views💬 3 replies❤️ 0 likes
3 Replies
Just as it's important to make an MVP patient, for me it's important that it be ready enough for use to actually get feedback on. I always get disappointed when I go from a simple prototype to feeling like the whole system just isn't working!
When it comes to MVP, I usually feel forced to make a choice, or honestly, I just try to carry both together. First, I build a simple prototype, and then I turn that prototype directly into a viable MVP. Why? Because a prototype is only for validating the idea, but an MVP needs to deliver what the user actually needs. So for instance, if there's a feature but the user doesn't want it, you can't quickly see that in a prototype, but with an MVP the user is already using it directly. To get fast feedback, you don't necessarily need to deliver something fully ready for use—I just add a bit of quality UI and clean code on top of the prototype and hand it off to test users. That way, you test reality with minimal loss in both cost and time.
I'd rather launch the MVP in a ready-to-use state to get user feedback quickly, bro. Like, I used to be developing a fitness app for a startup, and the first version only had basic tracking and step counting features (with a super simple interface on top). Then within 2 weeks, most users said they wanted "workout programs" and "nutrition tracking," so I added those directly in the second sprint. If I had optimized everything from the start while writing the code, maybe the performance would've been better, but I'd only find out "what does anyone want?" after 2 months, and that wouldn't be useful either.
I think the biggest advantage is being able to develop based on real data coming from users. If it were just something like a prototype shown only to people internally, maybe I'd constantly get "Looks great" comments from developers, but I'd have no idea whether it actually works or not. Launching it quickly and shaping it through feedback makes more sense. So the "viable" part of "minimum *viable*" actually matters; just having clean code isn't enough at the end of the day.