When it comes to building an MVP, how long is too long? - **Should there be a time limit for building and shipping an MVP?** From defining "minimum" to advice on when to launch, founders weigh in below. - **Launching a beta test allows you to collect
When it comes to building an MVP, how long is too long?
-
Should there be a time limit for building and shipping an MVP? From defining "minimum" to advice on when to launch, founders weigh in below.
-
Launching a beta test allows you to collect data and feedback from real users, and iterate accordingly. This guide will help you create your most effective beta launch yet!
-
Founder Marko Saric's open source product hit over $1,000,000 in annual revenue. Below, he breaks down the mystery behind open source, including managing the community and preventing your code from being used against you by competitors.
Want to share something with over 100,000 indie hackers? Submit a section for us to include in a future newsletter. —Channing
⏰ MVP: How Long is Too Long?
by Londoner
I've been working on my MVP for almost six months now, and it feels like it's taking forever. I also have a full-time job, so I don't have as much time as I'd like to build my SaaS startup.
Should I just outsource the work to get it finished quickly? What if someone else steals my idea in the meantime?
The "minimum" steps
Sébastien Night had an idea of what his journey would be like when starting out:
Here were the steps I was looking to follow:
- Minimum Announceable Product: Market research, formulating a thesis, and gathering interest.
- Minimum Investable Product: Obtaining proof of concept and seeking capital.
- Minimum Demonstrable Product: Building something that works.
- Minimum Buyable Product: Adding features.
- Minimum Scalable Product: This is basically product-market fit.
- Maximum Value Product: This is when the full vision is realized.
I had this entire construct in my head, but none of it survived in reality. It turned out that we didn't need to raise capital at all, so we went from announcement to proof of concept in six weeks. From there, we opened pre-sales in four weeks, and went from pre-sales to MVP in three months.
Try to follow the steps, but don't be afraid to deviate from them if they aren't working for you at a given stage!
Launch yesterday
Dkanika says that the length of time really depends on what you're building:
You have to control your fear of someone building faster and overtaking you. The fact is that someone with a bigger team and deeper pockets can do this at any stage, even after launch, and crush you. If that's your concern, you should focus on launching as soon as possible.
Another factor to consider, apart from complexity, is what you want to achieve with your MVP. Do you want to just validate an idea? As the acronym states, focus on the minimum viable product. It should be something that does one specific thing extremely well, and it should help you determine whether to devote more time and resources. It seems that six months is quite long for something that could be done quicker and simpler.
Does your product do one core thing or have one unique feature that's central to solving your users' problem? If so, then the best time to launch is yesterday!
Is it actually an MVP?
Allison reminds founders that Michael Seibel of Y Combinator advises that if your MVP takes longer than a month, it's not a MVP:
Instead of jumping to outsourcing, I'd suggest asking yourself these questions:
- Are all the features that you're building essential to your product?
- Are you spending too much time perfecting the UX?
Your MVP doesn't have to be perfect, and you can always build or delegate improvements in a future iteration.
D0utone shares a common saying:
“Startups die of suicide, not murder."
If you feel like you're taking too long, try to limit the scope and publish as soon as possible. That way, you'll learn a lot, and be able to prioritize the functionalities to add later on.
There is no perfect time
Apurva Raj says that some founders take two weeks from idea to MVP, while others can take much longer:
Every founder's journey is unique.
Ideally, yes, the faster you can ship, the better. But, if you're spending money only because you want to have some kind of first player advantage, I'd highly recommend that you reevaluate. It's actually good if others enter in market before you because it's validation for your idea, and you can understand the market better just by observing your competitor. You can then use those learnings to launch a better version of your product!
How long did it take to build and ship your MVP? Let's chat below!
Discuss this story.
📰 In the News
from the Volv newsletter by Priyanka Vazirani
🎙 Twitter is officially adding podcasts to its platform.
🏡 Vacation rentals are now offering fractional ownership.
👀 Jack Dorsey revealed his biggest regret about Twitter.
👜 Vintage Gucci has emerged as the hottest resale brand.
🌱 Physical payment options have a nasty impact on the environment.
Check out Volv for more 9-second news digests.
👨🏫 Tips For an Effective Beta Launch
by Christopher Carrasquillo
We all know that product development is a long, complex process. The sooner we can start testing our product, the better.
Launching a beta test allows us to collect data from real users who are using our product. It helps us identify problems early on, and improve the product before it goes live. How can we make sure we are collecting the right info, using all available resources, and improving the product effectively?
Below, Upenv shares a beta launch guide for founders!
On validation
I've built multiple profitable products, and frequently share what I've learned with my 15K subscribers over at Micro SaaS Ideas. Here are a few quick pointers on what you need to validate your idea. Keep in mind that there is no single way to do this!
Validating a product is not just about validating the technical feasibility, but also validating your reach capability. You should validate how far you can reach to build a waitlist of paying subscribers through your marketing. Sometimes, you don't even have to build the full product or MVP to understand your reach.
Don't work on the below things at this stage:
- Registering a company.
- Outsourcing any dev work.
- Making pitch decks.
- Talking to investors.
- Setting up email for the new domain.
Instead, work on these things:
- Registering a domain: Preferably, look for a dot-com domain. However, if you can't get a good one, remember that Google SEO treats all domain extensions similarly. You can search domain names at InstantDomainSearch, and reference CunningBot for a better combination of words for your name.
- Creating a landing page: Don't spend a lot of time building the world's best landing page. Use any website builder and include a waitlist form using TypeForm, Tally, etc.
- Creating a few graphics using Canva if you want to social share images.
- Submitting your website to BetaList: Keep in mind that BetaList takes six weeks to approve and publish your site.
On launching
Here are a few other places where you can launch your product: BetaPage, StartUpStash, StartUpBase, Launched, LaunchingNext, and SideProjectors. If you have a Facebook presence, join these Facebook Groups: SaaS Mantra, Scaling SaaS Founders, and SaaS Founders Network. Don't spam these groups. Genuinely build relationships.
Talk to your friends, family, and colleagues who might benefit from the product, or will at least talk about your product in their circles. Make use of online communities like Indie Hackers and Reddit. Build a story around what made you pick this idea and what stage you are in, then ask for feedback.
On SEO
Submit your website to the Google Search console, as this helps with SEO. Find out what long-tail keywords are popular in your niche and use those keywords on your homepage. You can also create internal pages with those keywords, and link all pages. Use free tools like UberSuggest to see the keyword stats and competitor stats.
Write a few articles on Medium, DevTo, and other places about your product. These should be long articles (3K-4K words) with a detailed vision on what and why you are building this. If you have a popular competitor, write an article on "How I am building an alternative to XYZ." Having these kinds of articles will help you show your command and authority in the niche.
Build a social media strategy, and use proper hashtags to gain more traction. Experiment with various tactics, including cold outreach and paid ads. Create potentially viral content to get more attention for your product. Once you have some traction and people recognize your product, plan a Product Hunt launch. If executed well, this could give you a good number of waitlist signups.
Wrapping up
Make sure to keep your signups warm. As soon as they sign up, push them for a call. Take notes as you discuss. For every 100 signups, a decent conversion rate should be 3% to 5%. Target the right audience and add a little friction to the form; adding more questions to your form will improve the waitlist quality.
If they are interested in the product, offer a lifetime deal or a good discount, and sign them up for payment. If not, ask them how you can improve it.
This is a long game. Build relations with other founders, support others, and remain active in the communities that you join!
I go into more detail about all of this in my book. Check out Zero To Founder if you're interested!
What are your top tips for a beta launch? Share in the comments below!
Discuss this story.
🌐 Best Around the Web: Posts Submitted to Indie Hackers This Week
📩 Cold emailing: A masterclass. Posted by Vikxo.
📝 Five lessons on pivoting as a startup. Posted by Alessandro.
💸 Don't launch a freemium app. Posted by Toby Hobson.
🤐 Developers, how do you really feel about no-code? Posted by Justin Ferriman.
🪲 Stop apologizing for bugs. Posted by GregariousHermit.
😎 A hack for reaching out to partner with cool companies. Posted by Heleana Grace.
Want a shout-out in next week's Best of Indie Hackers? Submit an article or link post on Indie Hackers whenever you come across something you think other indie hackers will enjoy.
🛠 Marko Saric's Advice on Open Source
by James Fleischmann
Open source projects are a beautiful thing, but to many, they might seem a little intimidating. How do you manage support? How do you prevent your code from being jacked by competitors?
Indie Hackers spoke in detail about this with Marko Saric, founder of open source product, Plausible, which recently hit $1M+ ARR.
Read on for more!
Why did you make Plausible open source?
We open sourced Plausible in order to be as transparent as possible, and to give people more control over their data. We're in the privacy first market, so working on an open source product is a way for us to build trust with our audience.
When you're open source, all of your code is available to the public. People can inspect it, analyze it, and even download it to run on their own machines. This is a whole different level from what proprietary software can offer. With open source software, our audience can determine whether our actions match our words.
The trust and transparency aspects of open source make it a bit easier to build a passionate audience!
Where do you find users?
GitHub is still one of our top sources of traffic and trial signups. All of our development is done in public on GitHub, so we're very active there. All of our website stats are open to the public. Here are our top traffic sources:
What is the downside of open source?
On the negative side, going open source opens you up to serious threats. We launched with what's called a permissive open source license. When we started getting some buzz in different niche communities, we realized that corporations were happy to take advantage of us.
Larger teams took our code and used it to create and sell proprietary tools that directly competed with us. Some corporations wanted to resell our software without wanting to contribute anything back to the project. These were serious threats to the sustainability and longevity of our (at that stage) very young project.
Plausible was our first open source venture that got any traction, so we were surprised by some of these issues, and had to spend time researching and picking a license that better fit our needs. I’m pretty new to the world of open source licensing, so I ended up learning about AGPL only a few days before we officially switched. We haven’t had any other issues with this since we made that switch.
How do you manage your community?
Managing a growing open source community is another challenging aspect. We have many self-hosting users, and self-hosting software is challenging. As we grew, we started getting questions from people asking for our help with installing or maintaining Plausible on their servers.
We tried to help initially, but because people can self-host in so many different ways, it was impossible to handle with our limited resources. Providing great support for people using our managed hosting is so much easier since we do the hosting and maintenance for them.
We could spend all of our time troubleshooting self-hosted installations, but that's not sustainable, so we made our self-hosted option a long-term release. It's released twice a year, rather than changed daily like our managed hosting.
We still get a lot of people asking for help with self-hosting, but at least the expectations have now been set and communicated clearly. We don't feel the pressure to help everyone, and can direct them to our community support forum instead.
Discuss this story.
🐦 The Tweetmaster's Pick
by Tweetmaster Flex
I post the tweets indie hackers share the most. Here's today's pick:
🏁 Enjoy This Newsletter?
Forward it to a friend, and let them know they can subscribe here.
Also, you can submit a section for us to include in a future newsletter.
Special thanks to Jay Avery for editing this issue, to Gabriella Federico for the illustrations, and to Londoner, Priyanka Vazirani, Christopher Carrasquillo, and James Fleischmann for contributing posts. —Channing
