Subscription Fatigue: How It Affects The SaaS Business Model

This newsletter issue is brought to you by:

It’s no secret: customers are tired of subscriptions.

But is this revenue model that bad for them? Or is it just misplaced annoyance because “everything is a subscription“ nowadays?

I believe it’s the latter and companies like 37signals shouting against subscriptions (and SaaS) from their pedestal isn’t helping anyone understand where the problem really lies: it’s not in the legitimate SaaS products that deserve to bill on a subscription basis; it’s the companies that have no business employing this revenue model that are causing all the damage.

Yet it’s the SaaS industry that gets to suffer the most because many SaaS products depend on this model to exist.

Lifetime Deals are cool for an initial injection of capital, but that’s unsustainable if your product heavily relies on the infrastructure that you have to maintain, upgrade, and pay for on a regular basis.

However, there are legitimate alternatives to subscriptions that we’re going to cover in this issue.

So let’s dive in!

Fuelling subscription hate

I was on Twitter a few days ago and saw this:

Of course if you simply let yourself get influenced by how this was phrased, you may feel the same until you peel back the onion a bit.

I don’t see any dark patterns here. It’s just proper pricing based on the cost/benefit ratio.

So I replied with the following:

Now on that same initial post, I had another discussion:

Taking it a step further

And that’s what I want to riff on here for a bit by tearing down the once.com website to show you the hypocrisy in their claims because people seem to fall for their cute statements.

Don’t get me wrong, I respect both Jason Fried and David Heinemeier Hansson for all their contributions in:

• Remote work

• Project management

• SaaS

• MVC Pattern in software development

• High quality code (I watched all DHH’s videos where he showcased Basecamp’s codebase and it was beautiful)

• 3-person teams

• 6-week development cycles

They’ve been around for a long time and I picked up quite a few lessons from their journey.

But their push toward one-time payment is packaged as the savior of software when this has not only existed before the SaaS revolution, but even during it as a concept called “on-premise installation.“

Not every company is offering it because of the extra complication that it adds on both the seller and the buyer.

SaaS is about a level of convenience that didn’t exist in the past.

But did you really own it? Every company had their own complicated (and expensive) license and most software was geared toward Enterprise. The “little guy“ didn’t even dream of having access to the tools we have nowadays thanks to SaaS.

But even B2C software that was available: I don’t remember having the right to edit the source of Photoshop or Dreamweaver, for example. We had to buy whatever version was available, get updates for bugfixes, and that’s it. Until the next major version where you had to pay again to purchase.

Doesn’t sound that once to me.

You completely depended on the software company to ship updates and there was no way for you to influence them because the money was already in their bank accounts!

Also, I remember very well how at some point they were even trying to prevent you from using the same license on multiple computers to restrict “key-sharing“.

But to do that, they had to spend extra development effort on things that didn’t make the software product better.

The barrier to entry was also very high and not many companies were making meaningful revenue.

Without SaaS, it’s unlikely we would have seen products like Figma and Canva.

This is like saying that nobody should rent a house because you can buy it. That’s as ridiculous as it is flawed thinking.

What if you can’t or don’t want to pay hundreds or thousands of dollars right now for every single tool you use?

Really, do add up all the one-time costs + infrastructure + DevOps hours you’ll either have to spend or pay someone to take care of the uptime and maintenance and upgrades and security for you.

Now what if you don’t have a DevOps specialist? You need to spend time hiring a good one.

Take all of that into account and then compare to the yearly SaaS subscriptions you’re paying, so you could truly look at a legitimate, apples to apples comparison.

No matter how much they’re trying to claim that only the “landlords“ benefitted from the subscription model (though they’re referring to it as SaaS, which is weird to me because they’re complaining against the revenue model of subscriptions rather than the business model itself), customers of SaaS products like myself and many other indie makers, solo founders, bootstrapped teams, SMEs, and even larger companies have also benefitted immensely.

It’s not a one-sided benefit. It goes both ways. Just like in a landlord-tenant relationship since we’re using this analogy.

If you as a vendor don’t deliver updates and improvements (this completely destroys the argument that “every month you pay for essentially the same thing you had last month“), I will churn. But if I paid once, the vendor doesn’t care what my experience is like!

So for nearly two decades, we ALL benefitted from the SaaS business model and it resulted in an explosive growth and democratization of software.

It’s not without problems, sure, but is anything in the world perfect?

Seems they’re completely ignoring the little guys here. We don’t all have IT departments and infrastructure, nor do we want to deal with all that.

Heck, I don’t even want to imagine what it would be like having to self-host 20+ tools!

And since when do we listen to the whims of one department? As a business, we need to figure out what makes sense: whether it’s paying someone else to handle a non-critical, but still important aspect of the company or taking care of the infrastructure on-premise, it shouldn’t be simply because someone is selling you on it; it should be because the Math + required effort makes sense, assuming it doesn’t take focus away from the important stuff.

I know this mostly applies to larger organizations that can afford multiple departments, but still wanted to touch on that a little bit because of the Twitter conversation I linked above where seemingly even indie hackers praise the direction that 37signals is taking.

As we talked about earlier, this was only partially true, but beyond the extra difficulties, I doubt many of us should be left alone to handle our own privacy and security.

I remember how easy it was in the past to hack people. I’m not proud of it, but I “experimented“ with that side, too.

I’ve done my share of hacking: from websites to WiFi connections to taking over computers and servers to make them do anything I wanted (except stealing money although pirating software could technically fall in this category).

I would never recommend beginners or non-technical founders self-host important software without a very skilled DevOps Engineer.

No matter how much they’re trying to yell at the top of their lungs, the post-SaaS era is nowhere near around the corner and it’s not going to be 37signals who leads the way.

The only real danger for SaaS (and software in general) is AI, but it will still take decades until we experience a complete paradigm shift.

This is enough time to create generational wealth with SaaS, so don’t wait too long!

But going back to ONCE, by trying to push this self-hosted model as the only option for software is pretty much attempting to destroy the SaaS solopreneur and indie making movement.

Instead of giving easy access to tools that make it possible for us to build SaaS products independently, we’d have to pay upfront + self-host them, eliminating 80-90% of those who want to build a better life for themselves.

That’s not something I can agree with or support when I specifically want to help people completely change their lives through SaaS!

So let’s now quickly analyze their first product: Campfire. Keep in mind the claims they made, alright?

Reading this, everything sounds super simple! Just one command and the application is up and running. Sweet.

Although you do need an 8-minute video to show you how (and of course it will take you longer than that since you’ll need to rewatch parts or deal with issues that inevitably come up - that’s the self-hosted world for you), but we’ll get back to that shortly.

The product itself seems really nice just like anything else they come up with. Like I said before, I respect the founders and learned so much from them, but I don’t like it when people are making misleading claims.

Now we have to worry about system requirements and whether that’s going to be enough. While you may be thinking that 250 concurrent users is more than enough for you (especially for a small team), running Docker itself properly requires at least 4GB of RAM and ideally 2 vCPUs.

I tried running it on a 2GB machine and would hit “memory segmentation fault“ issues all the time.

And although you can install Campfire without Docker, that means you have to set up your VPS before installing it and if you’ve never had to do something like this before, you’re in for a nice treat.

But don’t worry, this is fixable with a skilled DevOps Engineer! So go ahead and buy Campfire instead of using the free tier of Slack 😆 

Or get rid of the whole Microsoft Office 365, just so you wouldn’t use Teams.

Unless you’re willing to run both, in which case, what’s the point of Campfire, again?

Now we’re going to dive into some FAQs because this is where it gets interesting, so please bear with me just a little longer.

I really love how they come up with analogies because it’s almost good if it wasn’t misleading.

No ongoing fees? How about infrastructure and DevOps or my own time?

No support contracts? How about having to roll up my sleeves (or paying someone else) to fix bugs that you’re going to ignore or take forever to fix? After all, this is software and it’s not going to be perfect.

It’s mine like a jar of peanut butter? So can I just turn around and sell Campfire to someone else like I could with my jar? Oh, I can’t? I thought it was mine…

I love this next one:

Notice this sneaky version jump that may cost extra? It definitely will! They only guarantee free updates to the major version you bought.

So if you want to upgrade to the next version, you have to pay again. Doesn’t sound once to me!

Plus they also need to maintain infrastructure that allows you to get automatic updates and install them or you have to spend time on doing that manually. Sometimes things break during upgrades, especially when you’re not familiar with that codebase and you then have to reach out to support (which is bare bones) for help.

All of this has already been fixed once: it’s called SaaS!

Pushing this approach as the next best thing is like saying we should get rid of computers altogether and go back to pen & paper.

No need to make your life more difficult.

Forget about the comfort of having native phone apps available. PWAs are definitely useful, but they’re not native apps.

All apps I built either for myself or for my clients are PWAs and that definitely helps when you’re starting out, but if you want to use platform-specific features, forget about it if you’re not going full native.

You’re at the mercy of what vendors allow for PWAs, which seems to be getting better, actually.

So this is what they mean by bare bones, got it. Along with saying “bye“ to subscriptions, you’re basically doing the same thing for support when you need help.

And if you touched the code to make changes on your own? You’re f*cked. So much for owning the software like a jar of peanut butter.

But I’m assuming you can pay them an hourly fee to help out, right? 😃 

Wait, isn’t it my software? Why can’t I install it on any machine I want?

This is what I touched on earlier in the article, too. And you certainly can’t resell it without their permission.

Now this, by the way, is an amazing use case for on-premise installation, but the majority of people don't fall in this category.

And last but not least:

If you want to switch to something like Campfire, you have to leave your baggage at home. Sorry, can’t do otherwise.

So you’ll have to keep your Slack subscription if you need access to any past conversations. I thought I could switch and get rid of that awful subscription? 🤔 

That’s it with the teardown. I wanted to show you that they’re marketing an ideal, but then reality comes to knock you down.

The problem isn’t with SaaS or in the subscription revenue model itself.

It’s in the misuse of it because of the benefits it provides to companies, so everyone wants a piece of it even when they shouldn’t.

Think of BMW wanting to charge you a subscription for getting heated seats or Mercedes limiting your car’s power without paying them monthly. That’s infuriating because you’re paying for the whole product, not a part of it and you get limited simply because they want a piece of the subscription revenue model.

Another problem I see with subscriptions in the SaaS world that leaves a bad taste in my mouth is per seat (or per user) pricing.

I think this is the worst offender that gets everybody pissed and is what played a large part in the subscription fatigue we’re noticing nowadays.

It’s what we call a “lazy value metric“ in SaaS pricing.

That’s because the easiest way to “capture“ more money from larger companies is by charging based on headcount.

It’s really the same as flaunting how many employees you have as a sign of success when you’re just burning investor funds and are far away from P/M Fit and may have to close your doors down soon.

The only time this is true is when having more people using the product directly correlates with the extra value you’re getting from it.

Think of a payroll software (each employee adds extra overhead, so by eliminating it with this product, I benefit from each person that I have in the system) vs bookkeeping (maybe I want the whole company to have access, but that doesn’t make it more valuable to me - it’s the number of transactions that I or my accountants don’t have to spend time categorizing that makes it valuable).

So we have to stop being lazy when setting prices to avoid further subscription fatigue.

What alternative options are out there?

Now it’s time to talk about alternatives to subscriptions.

On-premise installation

“Hold on a minute! Didn’t you just spend the majority of the article bashing 37signals for their once.com initiative?”

Yup, I did, but this doesn’t mean this approach doesn’t have its place.

It’s only when it’s pushed as the end-all-be-all that is the problem while trying to kill the SaaS business model and the subscription revenue model altogether.

I am pro-choice.

If you really want to self-host and deal with all the extra overhead or you already have both the infrastructure and the team to manage everything without an extra cost, who am I to tell you otherwise?

But neglecting those who can’t do that is a huge mistake.

My suggestion here is to do both of these:

1. Offer your product as a hosted version where you charge either a subscription or one of the other models we’re going to talk about here.

2. Have a self-hosted option with a one-time payment for those that want to go that route.

You not only benefit from both types of customers, but you also won’t use up extra resources while still making a lump sum upfront from the customers that just want the software.

In fact, that’s something I’m definitely going to do with all my products where it makes sense though not in the MVP and not without pre-orders.

This is actually much better than how Lifetime Deals are currently implemented because you don’t have to spend on infrastructure for those that don’t want to pay you for it, but still want your product, so you don’t even need to price that in!

In the past decade, I’ve only seen a limited example of SaaS businesses that take this route, but I think this will change in the future.

Usage-based pricing

Instead of a fixed cost per month based on some value metric, another option is to charge by how much your software is used.

In fact, Stripe recently made an improvement to make this even easier than before.

That’s pretty much how most cloud providers charge for serverless.

And it’s actually how I eventually wanted to price one of my software products that I discontinued (lack of time and resources to give it the love it needs).

Though I am considering to try this model for landingleap.ai instead of subscriptions, but most likely later (I have some ideas about that!).

Credit system

This is almost like usage-based, but billed differently.

Customers can purchase a certain amount of credits (with discounts for larger quantities) or this can be coupled with a subscription where they get a certain number out of the gate, but can buy more.

Many tools implement something like this:

• Subtitle & transcription software (you get minutes, but can buy more)

• Generative AI software (you get a certain amount of uses, but can buy more)

• Automations (you get runs, but can buy more)

• Contact databases (you get email reveals, but can buy more)

This is best for when everyone uses the software differently and has different requirements, but you want to make it simpler on yourself than doing usage-based pricing.

I highly encourage you to try it out!

What do you think?

Now what are your thoughts on this whole 37signals thing? Do you agree with what I said or disagree? Just reply and let me know or post about it on Twitter and tag me.

I’m always happy to wrestle on this topic!

Also if you know more alternatives to subscriptions, please share. I will cover them in a future article and will give you a shoutout!

What you can do for your SaaS

No matter what you think about subscriptions or other revenue models, don’t ignore any one of them.

Here’s an interesting exercise: come up with a pricing strategy for each one of these 4 techniques:

1. Subscription

2. On-premise

3. Usage-based

4. Credit system

Even if you’re not going to end up using them, it will help you organize your thoughts much better and make sure you’ve considered everything.

Then once you’re done, try to combine at least 2 of these techniques into one pricing mechanism.

Bonus points if you test it out to see what your prospects resonate with the most!

That’s exactly what I’m doing for landingleap.ai.

That’s all for today. See you next week!