I think the only time when you don't regret building MVP is when your project fails.
Because I'm going through this feeling. I'm in process of rewriting our codebase, making it much polished.
What do you think?
Taking 3 months to rewrite something that is gaining traction is way better then taking 3 months to code something you're not even sure you can sell yet.
Also, a software product is never perfect. You'll learn a new trick with that framework and you will no longer like the codebase that you once thought was the perfect code.
exactly this^
You should not have to regret putting out a MVP. If you do perhaps you spent too much time or effort on it, and it is not actually the simplest version to validate your idea. For example, I am an app developer. I always thought you need a bare bone app that includes the core feature. But actually no, an MVP could be a landing page with a simple signup form, or even just a survey that helps validating your idea. I had to learn this the hard way though...
Very well articulated @hkanaktas
This is so true.
I don't think you should regret it. If you have to rewrite, that means you have traction, you have users - looks pretty good to me:) 100x better than writing MVP and then abandoning it, because no one was using it.
Hey man @usamakhalid you should not regret
Every little step is part of your success. Let's try to celebrate failure soon, learn from it and grow strong.
I've been doing small MVPs (recently VenturesList), get real feedback from visitors and iterate.
Awesome π will have a look into it.
Which payment gateway are you using?
Paddle
If you do have an MVP, you should have a product that does have some "viable" features.
Some business user/ potential customer should have been involved in defining the viable features, so in theory, it should be almost impossible to fail unexpectedly ...
Only do this if it is gaining traction.
Yeah it is gaining traction.
An MVP does not mean write shit code, I never understand why people think MVP's should be spaghetti code. An MVP is just the bare minimum valuable thing you need to build to prove your idea. What you should do is write down all the specs you think are needed and ask yourself the question: "Is this really needed to do X?" tagging each feature in MoSCoW is a great way.
Besides that think simple, I work at a startup for food pickup at stations. We had a feature request: Restaurants want to have dine in. One of the devs spend days building new screens, database migrations etc. My solution? Add a fucking toggle at the checkout screen asking: "Dine in?"
Why? Because it solves the problem, only once this feature really takes of we should start spending our time!
It turns into a spaghetti code π most of the times when you're building something relatively complex with a very minimal budget. Maybe it's my niche or I'm just unlucky.
IMO if what you're building is too complex to code nicely in a relatively short time, either it's not an MVP or you probably don't know your tools well enough to code fast enough.
People spit out MVPs in literally a day or two. That's extreme. A week or two sounds ideal to me. The first time I forced myself to go simple -which was actually this week- it took a very relaxed 5 days to put together a functional product.