Dear founder,
This week I’d like to talk to you about “getting things right enough” in the early stages of running a bootstrapped business. I’ve been talking to a lot of founders who consider themselves perfectionists. They run into the problem of never being ready to release their product over and over again. There is always something more to do, another thing to finish, and they fail to deliver anything at all.
Luckily for you, I am a very lazy person, and I am perfectly fine with shipping something that’s good enough. That’s why I want to talk about the most important thing you will have to do to get your business rolling: shipping your Minimum Viable Product, your MVP.
Two things are paramount for your MVP: scope and timing. You’ll need to figure out what goes in it to make it viable, what doesn’t need to be in it so it can be minimal, and you will have to decide when it’s an excellent time to make it available to your audience.
Scoping your MVP means one thing: finding the core functionality you need to provide and focusing all your efforts on getting your users to experience that. There are few other things your MVP needs, and those would be a way to log in and a way to pay for the product. Anything else is too much.
If you wonder if any particular interface element should make it into your MVP, you probably don’t need it in there. If it were a part of the core functionality, you wouldn’t need to ask yourself this question.
The interface quality of your MVP is determined by what your audience needs to start using the product. For a developer-centric market, an API and a few docs might do the trick, while you might not need much of an interface at all for other customers. In the article, I show the example of EndCrawl and how they validated their product with a Google Doc and a Perl script.
Let’s talk about validation: it is the single purpose of your MVP. If you release your MVP and people start using it, great. If you release it and people don’t use it at all, even better. You just invalidated the assumption you had — time to adjust the MVP and try again.
This is why timing your MVP is so important. If you don’t release your MVP as soon as you can, all learnings from it will be delayed. You’re validating your core functionality, not the final product. So the core functionality is all your MVP needs to allow this kind of validation.
Also, be aware that your initial customers should be early adopters and innovators. You’re not pushing a prototype into the mass market. The kinds of customers you should have checking out your product will be the ones that know what an MVP or a beta version is, and they know what they signed up for. Many early adopters enjoy giving feedback and shaping new products with it. Make this possible by adding a real-time chat or at least a contact form for feedback from day zero.
Ship your MVP with a payment option and a limited trial. You are validating two things: does this solve someone’s problem adequately, AND will they pay for this? Without financial commitment, you will only know half of what you need to turn this into a business. Even if it’s heavily discounted, allow your users to become customers from the start.
If you want to see how EndCrawl and Buffer have successfully released MVPs that validated their business ideas, read the article called The Do’s and Don’ts of the Minimum Viable Product.
Let me quickly tell you a story about validating your MVP. It’s a story of a failed startup that I was part of. We built a tool for photojournalists to upload their data. In a mostly technical team, we had the core functionality down quite quickly, and we released our MVP to the world with barely anything other than the upload functionality, a way to pay for the product, and an authentication system.
In the beginning, it worked well. We had early adopters using the product, and after a week or two, we even had our first subscriber.
And then, nothing. People stopped signing up for the product, and a few months later, we closed down the product. In what I can only call complete ignorance of meaningful marketing and sales, we had validated the product, but not our own processes. We had not found any channels that would allow us to attract enough customers to turn this into a business. We had not found our niche.
This is a cautionary tale: even a validated MVP will not be a guarantee for a successful business. It’s just one part of a greater equation. Don’t fret over your MVP so much that you forget to take care of building a business.
And sometimes, this might mean finding someone who knows how to do this for you.
Bootstrapping in Practice
Many bootstrapped founders start alone. They see a need for a product, they start working on it, and get to a certain point when they consider finding other people to work with.
In the early stage of running a business, there are two options for these solitary founders: find an after-the-fact co-founder or hire early employees. While there are a lot of similarities between these two, I’ve learned a lot about the differences as well.
Today, I want to talk about incentives, ownership, and the unique bootstrapped perspective.
Co-founders are not early employees. Even if you’re adding a co-founder after you’ve already established your business, they are not just there to do some work. You add a co-founder because you lack a critical skill that is required to build the business. Founders build a business; employees run it. That’s why they should own a part of the company.
I’ve recently talked to a founder who had started out alone and decided to add a co-founder later. The person he found was a great find, immediately making the business better from the moment they started working together to see if they would be a good fit. Now their discussions turned to equity, and the advice my fellow founder received was conflicting: some people told him to fight for as much ownership as possible, others suggested a 50/50 split.
I am in the 50/50 camp. Too many times have I been part of a founder team with highly skewed ownership ratios, and it never worked out in everyone’s favor. The times when shares were split almost equally, alignment happened.
If you just read this and thought, “but I bring more to the table than they do,” then you have discovered the problem: as single founders, we believe ourselves to be more important, more capable, and more deserving. Ask yourself, why then would you be looking for a co-founder? If you can’t get the business to where you want it alone, are you truly the most important person? Or is this a team effort, a joined adventure, where each participant deserves an equal share?
I watched the Hobbit movie recently, and even Bilbo Baggins gets 1/14th of the spoils of their journey, contractually determined from the day the company of Dwarves raids his pantry.
If it’s good enough for a Hobbit, it should be good enough for you. Your business can be worth quite a bit, and it might sting to see that you have to share it with a co-founder. But you wouldn’t get anywhere near this value without them. Understanding this levels the playing field, and it allows them to see the business as something they own and have to grow and nourish.
Early employees are not co-founders. Because unlike a founder, an employee does not have skin-in-the-game. An employee exchanges their time for money. A founder exchanges their time for wealth. This has significant consequences for your business.
In many ways, employment is a mercenary culture. There is poaching, scheming, treason, and many more things that you’d expect to find in bandit stories of old, only to encounter them in the courts of law that deal with labor issues. We have established a culture of acceptance around these practices. We teach these behaviors to the people entering “the workforce,” and expect them to regularly join another warband for slightly higher pay and slightly shinier spoils.
That’s why an employee will never have the same kind of outlook on your business. Even if you try to align them to your business goals by giving them minuscule fractions of equity, their loyalties will lie with their mercenary career.
The Psychology of Fractional Shares works against your business.
I’ve been there. I’ve been a co-founder with single-digit ownership in a business, and I’ve been an employee with a sub-single-digit share in the company. In both cases, this didn’t retain me too much. In fact, these were real shares, not even just options. And still, it didn’t make me stick around more. I still think fondly of the time I worked in these businesses, but fractional ownership is not the kind of incentive founders believe it is.
Basecamp’s Jason Fried tweeted about this, stating that this way of pushing employees to work harder isn’t ownership, it’s abusive. While he has received a lot of backlash for this position, I have to agree with the statement.
I agree because an employee is not speculating on the success of your business like an investor or a co-founder would. They’re better off with a paycheck and a bonus. Have you ever fed vegetables to a dog? Trying to bind an employee with stocks has the same effect.
Here’s the thing: maybe co-founders and investors would be better off with a regular payout instead of having to play convoluted percentage games. Profit-sharing is on the rise, and investors in the bootstrapped space have found that sharing your earnings is a much more reliable way of paying back investors.
So, what’s a bootstrapped founder to do? First, understand that your business won’t be “just you” forever, and it won’t be anything at all if you don’t find the right people to join you along the way. Compensate them fairly, aligned with their needs and interest in taking a bet on your business.
What’s better, owning 50% of a company worth 4 million dollars, or owning 100% of a business worth zero?
Links I Found Interesting
When Indie Hackers wasn’t a community yet, it was mainly a list of successful indie startups. A similar list called Profit Hunt was launched this week. If you’re looking for inspiration, check out that list of profitable bootstrapped startups.
Laura Roeder of MeetEdgar wrote about Founder Bias and how it poisons your team. If you know the feeling of “only I can do this job” or want to avoid it in the future, check out the article.
Bootstrapping Success Stories I Noticed
Adam Wathan, the creator of the Tailwind CSS framework, released TailwindUI this week and made $500k within three days. If you want to see why building an audience around Open Source pays off and how you can successfully sell a UI framework for $250 apiece, check out the discussion on Hacker News.
Alexander Isora of Unicorn Platform reported about how he dealt with non-essential features and his customer’s feature requests. The SaaS is growing, and he only adds features when enough customers request them. That is the way to do it.
Rosie Sherry, mentioned in last week’s edition for starting to mentor other bootstrappers, has published a milestone about taking six months to reach 100 newsletter subscribers. Not everything grows fast, and sustainable growth is a good indicator or having something that works for the niche you chose. Realistic goals and disciplined work will get you there.
Thank you for reading this week’s edition of The Bootstrapped Founder. If you like what I wrote about, please forward the newsletter to anyone you think would enjoy it too.
If you want to help me share my thoughts and ideas with the world, please share this episode of the newsletter on Twitter or wherever you like, or reach out on Twitter at @arvidkahl.
See you next week!
Warm Regards from Berlin,
Arvid