- US based business, Boston. Taxes are higher, rent is higher (when you needed rent). Salaries are higher (if you want good people). As the founder, I wanted my company to have great benefits and healthcare. That cost (and I'm not kidding here) reduced our revenue considerably. This is why I'm a huge fan of a single payer option in the US that takes healthcare off corporations.
- B2B business with SMB's, average customer ARR was about $3K. E-commerce integration product, so it was a bit of a lift on the technical side with many nuances between integrations.
- Support ended up being about 75% of our labor costs.
This is otherwise known as a "lifestyle business". It's the north star for most people and should be but it's not easy.
If you build a $500K a year SaaS business and have very little overhead, you can probably take $200K of that revenue as income and have a good work-life balance that's very comfortable. I know, I was able to do this without taking VC and bootstrapping 100% on credit cards and my own cash. However, there's an inflection point that happens with this sort of business IF you're not careful -- or it becomes more successful / or becomes a death spiral.
If we're speaking of a true SaaS model. It can work. But there's "gotchas".
I did well with this and but eventually sold the business for about 3X and went back to work for another company. But for about 7 solid years as we gained customers and got to that $500-700K, it became very hard to keep it a "balance" as with every 10 customers we added, the more of my time was spent at work and not as much at home. As we added customers, my "balance" was diminished, so I had to hire people, which then cut my income considerably. In the end, I realized it was better to sell the business and take the profit I could to pay off my cards and get something out of it before it killed me. I used to tell people who used to say, "wow, must be great having a business like that!" I used to tell them, "Yes, it's amazing 100 hour work week!".
It became more of a "job" and less of a "lifestyle" as the customer count increased. This could have been anecdotal to my business and product, but I have to believe that it won't matter as that size annual revenue demands a bit more of a sophisticated product type. Unless you've hit lightning in a bottle and have a very "light work" product that you're selling and have cracked the code of hitting $500K and having to do barely anything, more power to you... But I don't think there's a lot of those out there and a lot to be created.
I just find that with most SaaS businesses I've been involved with and built, the product is solving business problems that aren't usually a "set it and forget it" kind of product to meet those requirements and just sit back and collect money... I find that most SaaS businesses in that range of revenue are complicated and warrant a higher degree of overhead.
The real challenge is, "little overhead" to be able to create an income and survive. Support, service and development is expensive and requires more than one person. Good support is important to retain your customers to keep that $500K coming in, and that really is the problem because having just 10-20 customers paying you $500K is far riskier than having 1000 customers paying you $500K.
Churn is dangerous in SaaS products that are high cost with smaller customer bases. One or two customers leaving could give you a pretty good dent in your revenue, thus causing you to cut income. So the trick is mitigating churn by having a product that's priced at a point that you can gain a larger customer base so that churn isn't going to radically impact your revenue.
But both strategies are going to require support and service and that costs quite a bit of money and can gravely cut your income that has to be passed to engineers/developers who can improve and maintain the product. I had to hire really good support people and some engineers because as we grew that revenue, the product became more complicated and support and service was more demanding (I had about 400 customers). I eventually had to cut my income to pass that to people who could take on more because I couldn't do everything.
So there is a law of diminishing returns with this sort of business strategy.
It can work, but you have to really strategize, have a product strategy that can generate a good sized customer base but requires very little maintenance, development, support and service.
But I call this the "holy grail" SaaS business -- they simply don't exist -- or if they do, they are rare birds.
Just be prepared to understand the issues if you do have some success and are lucky enough to grown a SaaS business to $500K+
Just don't be surprised when you feel like you've succeeded but feel like you're failing.
Authors bio is exactly what is wrong with software development today. Too many people who've made money at FANG companies who now think they are experts in the field because they got lucky and was hired at a time when their stock price and options accelerated based on NOTHING they did...got wealthy and have convinced themselves (and others in the industry) that they actually should be thought leaders. Insane shit going on right now...
Bottom line: 10 years of non-coding experience in the industry (Sun & Intel), then about 5 years experience (assuming) development/coding and he's now a "serial entrepreneur" offering best practices advice for code reviews, architectural reviews... no mention of any product, technology or coding (where's the public Github account with demonstrable experience?) that he's actually delivered or maintained. I see a guy with 15 years of experience that got lucky with his options and is blathering on to boost his LinkedIn profile.
One thing for certain, he titled his article as something provocative to get the click-bait going and using "Moneyball" certainly caught my eye and made me curious. But after reading this article, it's fraught with problems and demonstrates the lack of experience and using very limited anecdotal evidence to apply to a field that's complex and not a single article solution, which I have to say, with less than 5 years of coding and development experience, he shouldn't be considered an "expert" that gives advice on this process -- he should still be listening to people and understanding how the SDLC process works because he's clearly missed that course at Standford -- He clearly didn't pay attention to Steven Blank...
Look, I know people with 20,30 (including me) years of experience in this field that would read this article and would point out, what you're reading is not only what inexperience is, but also what someone who's been too involved in the money and investment side of the business sees. If I had a manager in my team present these ideas to me and how they wanted to operate with 1:1's for example, I'd get them out of the company because they would be creating a culture of pointing fingers.
Also, as a side note, when I saw the title, I immediately assumed "outsourcing" article because the premise of Moneyball (Bill Bean / Bill James theory) is to use cheaper labor to get better results by doing things that can still get performance and wins without having to play the game the way in which the rest of the teams were, completely undermining the norms and trying to get better performance with less. This is a poorly titled article, the premise has nothing to do with the Bill James theory.
Lastly, I don't want to be totally negative,he had one good point in the article. Using time estimates for story pointing is a bad thing. His example of measuring complexity was a bit too vague and nuanced, but it was a better example of estimating to get to a valid burn down. But a broken clock is correct twice a day...
I would point to Jim Jordan and all the other Republicans after January 6th who didn't honor a subpoena and toss them in the trash. Nobody in our government honors them, why should we in the private sector? What's going to happen, they going to raid offices and get a bunch of PC's and books?
You described the early part of my career in software to a T.
I worked for a mini-computer company in the 1980's that ported Oracle (I'm thinking the version stamp was 22.1 when I was there from 1986-1990). It was one GIANT mess of standard "C" with makefiles that were in some ways larger and more complex than some of the actual kernel code it was building!