I’ve been running ReviewNB as a bootstrapped business since 2018 & have also heard hundreds of stories of other successful bootstrapped products in the past few years. In this post, I’m going to highlight some common themes that seem to work well for bootstrapped companies.
Caveats
The ideas in this post are mainly applicable for,
- Software products built by technical founders
- Where the goal is to quickly get to $10k+ MRR & then grow over time to several million in ARR
- This is not a good advice if you intend to build a unicorn. That’d require a different playbook.
Okay, let’s dive in.
Build on a platform / ecosystem
If this is your first business & assuming you’ve limited resources then building on an existing platform can be a blessing. These can be more formally defined platforms like Shopify, Salesforce, GitHub, Slack, Heroku, iOS App Store etc. But it can also be a popular platform (say Amazon, Etsy) that does not formally define integration hooks.
The benefits of building on a platform are –
- You get a solid ready-made distribution channel (via the platform’s app registry)
- Billing, payment processing etc. is taken care of
- Your target market is naturally more focused (e.g. “people with shopify store”) which helps in effective marketing
The downside is, there’s always the platform risk (e.g. platform owner building this feature directly into the platform) but I believe it’s still worth the risk, especially early on in your entrepreneurial journey, given all the benefits you get.
Fit into the workflow
Many 1st time entrepreneurs think of a problem & build a good solution for it. But they don’t spend too much time thinking about how the solution would fit into the user’s existing workflow. Expecting people to change their daily workflow is one of the hardest things. It’s not impossible but it requires a lot of education, training & retraining. As a small business, you do not want to take on that mantle.
The best way around it is to think of the tools & processes that they’re already following in their daily work & see if we can integrate our solution at the right point & the right time.
E.g. If your expectation is “Before you approve this code review, you’ve got to look at this code quality score” then make that quality score available in the same Pull request UI. Highlight it in a way that they cannot miss it. Expecting them to go to a new UI & run some code scans to see the quality score is adding too much friction in the process. And that friction is going to lead to poor adoption of your tool.
Market size does not matter, direction does
It’s easily possible to build a $1M ARR business in a fairly niche market. I’d actually argue that it’s probably easier than achieving the same outcome in larger market because,
- Niche markets are usually underserved by large companies or well funded startups
- You can effectively target your marketing to a small niche (vs. large diverse audience)
Being said that, you don’t want to pick a market that’s shrinking because you’re building for the next 2-3-5-10 years. E.g. you could build a tool for Enterprises to manage their on-prem infrastructure but with cloud adoption that market is going to continuously be shrinking. You can still build a decent business in a shrinking market but the upside is capped & you are constantly swimming against the tide.
In contrast, if you start with a small but growing market, your business would actually grow with the market & your upside keeps expanding.
Align pricing with Usage Pattern
Recurring revenue is the holy grail for businesses these days. But before bolting the pricing model on your product, please make sure that the usage is in alignment with the pricing model. E.g. if it’s a performance review software that we’re going to use once a year then it’s odd to be paying a monthly subscription for it. Might as well only offer an annual option.
I see a lot of ad-hoc usage tools (e.g. load testing software) that are forcing themselves into monthly recurring subscriptions. My suggestion is, either try to be creative with your pricing model (e.g. usage based) or if you’re dead set on offering monthly subscription then build a service that is actually used each month.
Avoid Critical Services
If you’re building a critical service (e.g. incidence management) then you’ll need to offer much more in terms of 24*7 support, 99.9999…. SLA and what not. Again, it’s not impossible to offer these but you do not want to take that on as a small business (pick your battles wisely). It’s not just about offering these things, you also have to convince the CIO of a mid-size company that you’ve got this, that you’re better at it than the incumbent in this space. Selling this is going to be an uphill battle.
I’d say focus on building non-critical software. E.g. Project management, invoicing, HR, productivity tools yada yada. If any of this is down for an hour or two, it’s annoying but not catastrophic for anyone. Non-critical software is easier to sell & support.
Solve A Niche Problem
You do not want to start in a space where X number of features is a table stakes. E.g. Look at Email marketing software – being able to handle scale, offer superior deliverability, provide private IPs are table stakes at this point. Once you’ve got ALL that, you get into building differentiated features like automated rule based campaigns & what not.
I suggest you’d rather start with a more niche problem e.g. churn analytics for Businesses on Stripe. Something where you’re not spending months building table stakes to compete with large companies or well funded startups.
Summary
If you’re interested in building a bootstrapped business, then hopefully some of the thoughts in this post would help you narrow down the idea. Goes without saying that consider all these as just a rule of thumb & you might very well build a successful business by breaking one or more of these.
In any case, if you’ve the itch to build something, give it a shot, there’s no better time than here & now. Seriously, with all the tools at our disposal today, it’s not very difficult to build a decent SaaS business even for a small team of 1 or 2 developers.
That’s all I have for now. If you enjoyed reading this, you might also like this talk by Jason Cohen. Adios!
Amit Rathi 