Lean Startup, day 18: Determining The Break-Even Point
In the previous post in this series, Yann explained what a MVP is in general, and what the MVP for misocell would be. Now that we know how much it will cost to get in front of real customers, it's time to do the math, and determine the break-even point. This posts explains in detail how to do the calculation for a SaaS service like misocell, and it's not rocket science.
Once we know how long it takes to reach profitability, we'll know how much we need to invest to get there. Or, since we're launching a new product, how much we may loose if we're wrong. Are we willing to take the chance?
After the demo stage, the financial investment for a startup starts getting serious. As explained in the previous post, misocell requires a minimum of 50k€ in development effort for the MVP. And this doesn't include other investments, like design (can be kept at a minimum for a MVP, but still, you can't really expect people to pay a monthly subscription with a Bootstrap theme these days). This doesn't include running costs either:
- Office space
- Internet, electricity, heating, cleaning
- Marketing and communication
- Paying the support team
- Paying developers to fix bugs and add small features
- Hosting (although using IaaS will keep that to a minimum for the first months)
We don't include customer acquisition costs for now (I'll explain why in the next section).
We make very optimistic guesses for these running costs, based on the idea that we join an incubator. A quick estimate gives us roughly 5k€ per month. Of course the founders don't pay themselves. We consider that we need 2 months to develop the MVP.
An initial investment of 80k€-100k€ for the first year is pretty common for software startups. You should feel uncomfortable if your business is based on a much lower investment: it means your competitors will have an easy way following your path.
Although it's usual to decompose costs between an larger initial investment and lower running costs, the Lean Startup teaches us that we can't stop development until we have found a plan that works. Finding the product-market fit may take a few iterations. So don't cut on development costs after the initial MVP.
We specifically extracted costs that depend on the number of users from the running costs estimate, because these costs are covered month-over-month by customer revenue. This includes customer acquisition costs and data storage costs.
Here are the assumptions we make to calculate customer acquisition costs:
- We can buy well targeted leads through a SEM/Social campaign (probably with the help of a specialized company) at about 1.80€ per user.
- We'll be able to convert 1% of these leads to paying customers
- The average subscription duration will be 1.5 years (18 months).
So the customer acquisition cost is 1.80€/0.01 = 180€. Split up on a monthly basis, this represents 10€ per month per user.
A good rule of thumb is that the acquisition cost of a customer costs between 6 and 12 months of the revenue generated by this customer. In other words, it takes about a year to turn a customer into profit.
We never really talked about the right price tag for misocell. This is a question that usually finds an answer during the demo phase: when you show a convincing product demo to a lead, it's the perfect time to ask for a subscription. If the lead accepts, you know you're too cheap. If the lead refuses, you know you're too expensive. That doesn't leave much room for the perfect price, but you get the picture.
But we didn't do live demos with the prospects we met (a mistake we already pointed), so we have to guess how much they would be willing to pay, based only on benchmarking data. This is far from ideal, and a good way to get things wrong quickly, but let's continue the exercise anyway.
The misocell pivot changed the initial revenue model. Since we're targeting developers now, we can't charge per end user, but per company, regardless of the number of users (à la Trello). We'll fix a limit to the number of API endpoints a developer can connect to, but that's only a safety net to prevent abuses. We don't believe that we can ask developers to pay more for an admin that connects to more endpoints.
However, we know that from a developer's perspective, the ideal price tag for a SaaS product is under 35€ monthly, tax included - whatever the product. This is because spending that little money is a quick decision, without second thought. Spending more requires the approval of a higher rank officer. We know that because we are customers of such SaaS products, and we know the price tags that make us frown. We could ask for more than 35€ monthly, but we probably won't be able to deliver on higher expectations before a year or two.
Also, during our benchmark, we saw a lot of dashboard SaaS tool priced between 20€ and 30€ per month. That's the tools our customers will compare us with. Since we're offering more functionality than these (write support), it makes sense to be a bit more expensive. So let's settle on 35€ per month and per customer - a single subscription plan, to simplify our calculation.
Off these 35€, we must remove taxes, and acquisition costs. We estimate 20% taxes on average. The customer acquisition costs amount to 10€ per month per customer. This gives us an average revenue per user (ARPU) of 18€ per month.
As to how many customers we could get, this somehow depends on the amount we decide to spend on customer acquisition. The customer base is very large - it's an international audience of developers. As long as we consider only a few thousand customers, we don't need to worry about the limits of the customer base.
We decide to ramp up our acquisition investment little by little - because we will learn to spend SEO and SEM money more efficiently over time, and because we will learn to better convert leads to customers over time. Let's consider 25 new customers every month at the beginning. After 3 months, we hope that our newly acquired skills will allow us to double that number, to 50 new customers per month. Then again, +25 new customers per month every 3 months.
The revenue starts once the MVP is shipped, on month 3:
This means that after one year, we'll acquire 100 new customers every month. These numbers include churn, which means that we should actually acquire more customers as time passes to compensate for churn. So the monthly acquisition costs should be higher than 100*18€, but this is not significant.
With an optimistic prediction on costs and revenue, the misocell monthly revenue should cover the monthly expenses after 9 months. At that time, we should have spent about 70k€. But it will take 18 months to start getting profits, and paying ourselves. 18 months is misocell's break-even point.
After that, without growth, misocell will make about 20k€ per month. It's not very much for a software company. To get a rule of thumb, divide that by your own salary plus charges, and you'll see roughly how many people like you the misocell company could afford with that revenue. Yep, that's a small company.
Things never get smoothly in a startup life, and you'd better build your business model on pessimistic predictions. Also, find a few advisors who already own a successful business in the domain you're targeting, and ask them to challenge your calculation. If you have to go to an investor or a banker, all the hypotheses in your business plan had better be much more backed up than the back-of-the-envelope calculation explained here.
There are many ways to reduce costs (e.g. IT for equity) or to increase revenue (e.g subventions). But don't spend too much time ironing out a spreadsheet based on highly uncertain assumptions. Instead, if you're convinced by the rough projections, start delivering the early versions of your product to verify the assumptions.
As for us, we don't need to go much further in this exercise: we know that we need to spend at the very least 70k€ before we can make profits with misocell.
This hard truth often discourages startup founders: your bright idea won't make you rich overnight. Misocell is no exception.
The Lean Startup allows you to deliver fast and iterate quickly to find a plan that works. But lean or agile tactics aren't magic formulas. They can't hide the economic reality: being a software editor requires a significant initial investment, and doesn't bring huge profits immediately. Unless of course you're named Bill or Serguei and live in the 90s.
Marmelab's business model is to sell software development services. Switching to an editor business model implies saying no to existing customers when they ask for our help, and focus only on our product, misocell.
Misocell also means capitalizing on a piece of software (ng-admin) that will require significant investment to keep in sync with the always moving frontend development stack. Some of our developers are already tired of Angular.js, and spend most of their time doing React development. Is Angular.js out-of-date already?
The high uncertainty of the Business to Developer business model, plus the high uncertainty of the misocell product itself, makes the adventure very risky. The risk translates to a probability that I estimate of 60% chances to fail. The potential loss amounts to 70k€.
Also, marmelab currently makes much more than 20k€ on a monthly basis. The high risk isn't balanced by a huge revenue.
After discussing with the marmelab team and my associate, we make the decision to stop the project. It's not that we don't want to take the editor road. It's that we believe we can find better opportunities, with faster return on investment.
The Lean Startup approach helped us to make that decision with minimum loss, and to learn a lot in the process. Even if we're disappointed to put an end to the project, we're confident that it's the right thing to do.
Note: The misocell.io domain name is up for sale. It's got a huge potential (20k€ monthly profit after 18 months!), so be generous on your offers ;)
The Misocell adventure has been a fantastic occasion to test our Lean Startup skills by eating our own dog food. We've learned a lot - and we hope that you could learn a bit, too, by reading this post series.
Failure is a positive value at marmelab. If we fail, it means we've tried. So don't be surprised if we announce a new SaaS project in the future.
Oh, and if you liked this series, please subscribe to the marmelab blog, and share the love with your friends. Long live the Lean Startup!
Thumbnail picture: Ferris Wheel, by Melissa