Do's and don'ts in an MVP

Focus on one key value prop and build around that. Keep it lean. MVP is essentially the second phase of validation - it doesn't need to be perfect.

Great story to illustrate the kind of scrappiness that can be done in MVPs -- quote from the founder of Buffer:

"I not only launched the product with paid plans from day 1, but I also didn’t fully implement the payment system. When someone upgraded to a paid plan, I would email them personally as soon as I received the email from Paypal. I didn’t do this to avoid the work, I did it because I had no idea whether it would be 4 days or 4 months before the first payment for Buffer. It would be a waste of programming effort to implement a slick payment system without validation with a few paying customers."

Focus your MVP on validating the crux of your solution for the pain point you're trying to solve.

Ps. I write a newsletter that dives into topics like this (and has an upcoming article on this exact topic) that you might find helpful -- check it out if interested https://www.bentherebuildingthat.com/

Ha I'm starting a whole newsletter dedicated to this question. In case it's helpful .. https://pitfalls.substack.com/

Being able to ask the correct questions. Not being afraid of asking any questions. Iterating the first two steps.

Don't be scared to fail. Because of this problem I launched later than I should have. Often you can test the idea of your business even without any code. Do you have a blind dating app? Arrange the dates over WhatsApp.

In my case I have Flipchat which is a chat app where you can learn a language by chatting with friends. To increase speed we used a code template we bought online. I do think that push notifcations (or emails when you have a website) are very important for apps with a small volume. It is not in the habbit of your users yet to check your app/website often so make sure that when something happens they know about it.

Good luck

Move fast. In the MVP stage, validation is key. The sooner you validate the product, the less risky the venture is. Ideally, you should get the MVP out in about a month or two. That means leveraging as many tools and tricks as you can. The book Rework really helps drive home the "get sh*t done" mentality.

i hope this helps https://railsware.com/blog/build-mvp/ :)

Navigating the terrain of a debut product version is a delicate dance. Jasper Kense's exploration of the do's and don'ts in an MVP is an invaluable guide. Simplifying features proved pivotal for me, ensuring a focused and user-friendly launch. . What strategies worked wonders for your initial idea? Share your insights!

Don't forget to charge from Day 1

Keep your MVP as simple as possible and don't spend too much time and effort on it. I created an Airtable Database as the first (and still current) version of my Business Idea Bank directory (instead of going the route of an actual website even though I could have built one with a no code tool).

Hi there!

I am also experiencing this 'analysis-paralysis' stage of an MVP.

I was literally searching around for fellow struggling techpreneurs who are in the same shoes as me.

i found out about the following redditor who can literally solve (partially?) our problems.

https://www.reddit.com/r/nocode/comments/10pd6el/i_built_a_minimalist_page_builder_to_test_as_many/?sort=new

Not sure if it helps

If it is something totally new (questionable), 1 core function (value generator) will suffice. Otherwise I'd still focus on one core function + some "wow" future to differentiate and don't be like "another SaaS, but cheaper".

In order to make something work online, it is perhaps most important to have social interaction, which is perhaps the hardest to do. https://essentialsclothing.co/hoodies/

I believe that when you are starting on a product, you should first do a psychological study of your customer in regards to the product you are building, some products require a very narrow definition of the problem that the product solves, and some other products have a more blurry vision as to which problems it does crack and its okay, I often hear the word from multiple startups that the product ends up being used in an entirely unthought of way, and that proves that having a vision for the product line and the specific problem it solves is not always achievable, but rather an explicit conceptual design of the product coupled with a deep understanding of your customer audience often times does. Once your product reaches its first usage, comes often a very important decision, depending on how people use my solution, how often is it being used, and what parts of the product are often more used than others, all this mesh of product usage begs a decision that is kind of binary, do I stick with my vision for the product or do I adapt it based on how it is being used? This decision proves to be crucial and is intertwined with the scalability issue. Do I make changes that are so drastic to users but true to my vision, that they flee the solution? or do I adapt to my users and thus lose the vision I had for the product and product growth? Aligning the two with varying percentages proves to be the best solution here but often of times, these solutions depend heavily on the temper of the founder and the personality traits of the creator. At the end I believe that products and businesses are a couple of rational and personal and the dos and don'ts depend heavily on who you are as a person? and what is the identity you still want to instill in your product? and how careful you are to be at your utmost behest for customers' reviews and needs, and how you want to somehow direct your customer to understanding your vision for the product?
Hope this gives you a framework to think about the issue,
Yaelf

I learned the hard way that building features that you like and think that others will do too is definitely a DON'T.

I wasted tons of time and had to remove so much code for www.mapmelon.com when one of the main cores of the app was not truly validated.

I'd also like to discover this what can you do

Write up your business in one short paragraph and find 25 people who say they'll buy it, and 5 people who put money down for it before you have it ready (or even start building it). This accomplishes a few things. First, it makes you articulate in one paragraph what you are building. Second, it makes you locate 25 people who at least say they are willing to buy it, so you now know how to go find more customers. Third, those 25 people you can now treat as advisors and email out weekly/monthly updates on your progress (if they agree). Forth, when 5 people go so far as to put some $ on the table, they really want it, not just saying they will theoretically buy it (it's best if they are 5 people that are new to you, not friends and family).

This is really good questions for people who are running startups and will launch soon. From my experience
As a language model AI, I do not have personal experiences, but here are some general tips for discovering the do's and don'ts of a first version of an idea:

Do's:

1. Start with a problem-solution fit: Identify a real problem faced by your target audience and validate that your solution is the right one for the problem.
2. Focus on the core value proposition: Build the minimum viable product (MVP) that delivers the core value of your idea, this will help you validate your idea quickly.
3. Engage with your target audience: Talk to your potential customers, understand their needs and feedback, and make changes based on that feedback.
4. Iterate, iterate, iterate: Don't be afraid to pivot or make changes to your idea, continuously improve and refine your product based on feedback from your target audience.
5. Build a team: Surround yourself with people who complement your skills and who believe in your vision.

Don'ts:

1. Don't overcomplicate things: Keep it simple and focus on the core value proposition of your idea.
2. Don't ignore customer feedback: Listen to your customers, they are the ones who will determine the success of your idea.
3. Don't be afraid to pivot: If your idea isn't working, don't be afraid to change direction, find a new problem to solve, or a new way to solve the same problem.
4. Don't be discouraged by failures: Every successful entrepreneur has experienced failures, it's part of the process, learn from your failures and keep moving forward.
5. Don't be afraid to ask for help: Seek out mentorship and guidance from those who have successfully navigated the entrepreneurial journey.

Still, it is really important to find between points. For example, you should not ignore customer feedback but if the feedback is not related to your mission statement, then you need to consider that point.

Don't make top-notch design
Do rely on facts and numbers

Don't fall into the trap of thinking you need to do juuust a bit more research. Or tweak the design juuuust a tiny bit more.

Usually that's yourself postponing the actual DOING, because that opens you up to failure.

agree!

I'd say the biggest "Don't"s revolve around time investment & validation. The basic idea is: Validate your app ASAP.

For example:
I built and (in)validated my first app over ~1.5 years.
My second app took ~60 days to (in)validate.
My third and current product will take ~40 days.

It's hard to quit things you've invested time into but as indie hackers, we have to be hyper focused on building real value not writing code.