Here in Germany, physical businesses have even more egregious subscription policies than most "dark" SaaS-es. Think, you do not cancel 3 months before expiration date - congrats, you're now signed up for another year. As a result, ended up writing a small PWA to keep track of my contracts and subscriptions.
I analyzed SaaS billing dark patterns
31–40 of 190 posts
Re: I analyzed SaaS billing dark patterns
#32This is one of my biggest qualms with building SaaS apps on the App Store. You can't do a free trial without requiring an Apple Pay confirmation which will auto-convert. We get lots of negative reviews because of it, but there's no way around it without offering some free version.
Though apple pay does a decent job on the cancelation UI, the free-to-paid notifications (in email) are always a miss. I have seen this in trial subscriptions at home with buyer's remorse later.
Re: I analyzed SaaS billing dark patterns
#33Here in Germany, physical businesses have even more egregious subscription policies than most "dark" SaaS-es. Think, you do not cancel 3 months before expiration date - congrats, you're now signed up for another year. As a result, ended up writing a small PWA to keep track of my contracts and subscriptions.
Whaat! This one is new. You mean subscriptions from your neighborhood store such as milk, bread, newspapers, etc?
Re: I analyzed SaaS billing dark patterns
#34AWS costs are somehow always higher than your estimate. Even when using their little calculator. That's the dark pattern right there.
Re: I analyzed SaaS billing dark patterns
#35Of all the nasty things somebody can do with billing, I'm surprised the author leads with card-upfront trials. "Free trials should not require a credit card." This is opinion presented as fact. This is not a dark pattern. Totally unrestricted free trials are wonderful, you've invested a ton in your product and you want a prospective customer to experience everything. But there are legions of abusers and bad actors of…
I'm sure that when you're analyzing SaaS transactions for a year (full time), you see a lot more data than we more-select-few-who-can-discern do.
Re: I analyzed SaaS billing dark patterns
#36These are far from the worst patterns. I've seen so much awfulness out there. My favorite recent one was a renewal if you don't cancel by a deadline that's months ahead of the actual end of the contract period and it also had a substantial rate increase and all the language that we supposedly agreed to wasn't actually present in the contract we signed. Those terms were in one of those "incorporate by reference" claus…
Does it actually work? Have you tested in in court?
Re: I analyzed SaaS billing dark patterns
#37> Your company needs a CRM, so you sign a year-long contract for, say, 50 seats on your chosen SaaS CRM. Then — yikes! After six months, half your team is laid off. Will the CRM let you adjust and pay for 25 seats for the remainder of their contract? > That’s a big NO. Unused seats? Still gotta pay for ‘em. (It’s called “SaaS waste” for a reason.) You committed to paying for 50 seats for a year. The CRM may have made…
Saas has obscene markups
Re: I analyzed SaaS billing dark patterns
#38Earlier quoted context omitted.
What would you recommend products that host the service and have ongoing upkeep costs to do?
I would recommend the creators ask themselves if their software _really_ needs to be hosted or can it be sold as a one-off (self-host or desktop/mobile).
I don't think you should be downvoted for this, but I do think there are some reasonable responses to it.
First, supporting desktop/mobile software can be hard. Customers have all sorts of weird things on their machines. iOS cuts down on that, but you still lack access for a lot of debugging and that can cost a lot of money. Support is expensive.
Second, I think there's this idea that desktop/mobile software is a one-off. What happens when Apple removes an API that your program used? Do you tell uses "sorry, your $X doesn't entitle you to a working program anymore?" For better or worse, software requires ongoing investment. If software requires ongoing investment, it kinda requires ongoing payment - or operating on the idea that new users will pay for the improvements required by older users. However, that's a dangerous assumption. At some point, there are a lot more older users than there are new users. Many companies tried to operate pension schemes assuming that new workers would pay for older workers retirement benefits. At some point, there are fewer new workers than there are old workers and it collapses.
Software maintenance is important, but it can be hard to price. Do you tell users "you have a license for 2.0, but you'll need to pay $X to upgrade to 3.0...oh, and 2.0 won't be updated to support iOS 14 so you're basically forced to upgrade"? Do we tell creators "if you don't keep this software maintained in pristine condition for the next 20 years, you're being predatory"? That kinda just demands that they do uncompensated work.
Even if software isn't hosted, there are ongoing costs. Some of that can be priced into the initial purchase of the software. Some of it can't be. It's hard to guarantee that software will continue working for 2, 5, 10, 20 years when you have no idea what that might entail in terms of work. 20 years ago, Apple was shipping Mac OS 9. Since then, I may have needed to upgrade my app from Classic to Carbon, from Carbon to Cocoa, from 32-bit to 64-bit, from PowerPC to Intel, and now from Intel to ARM - not to mention the huge number of APIs that have been broken along the way.
Is the right model something like what JetBrains does where you get a perpetual license to the version you bought, but that version might just stop working given changes around it (like OS upgrades or new machines it isn't compatible with)? That doesn't force you to subscribe, but it does mean that you're likely going to need to upgrade. Programming languages move on and you're stuck with an IDE highlighting things as bugs or that won't launch your program because it isn't compatible.
Subscription-based pricing gives creators an incentive to keep investing in their program and it gives customers predictable costs. No one wants to hear "sorry, this won't run on M1 and we're not going to upgrade it for free for you so here's a $X charge that you have no way around given that Apple is abandoning Intel".
Re: I analyzed SaaS billing dark patterns
#39I’m not sure it qualifies as a dark pattern, but I was really frustrated by the Logmein pricing. I was paying a relatively expensive amount for my 100 computers package. Once I went over that threshold I had to convert to the 500 computers package which cost 4x was I was paying. That was true even if I had 101 computers and not 499. I ended up upgrading with a negotiated price but still don’t understand why it’s not…
Not having consumption-based billing is definitely a callout issue and many exploit the simplicity of bundled t-shirt (Small, Medium, Large) SaaS pricing.
Re: I analyzed SaaS billing dark patterns
#40I’m not sure it qualifies as a dark pattern, but I was really frustrated by the Logmein pricing. I was paying a relatively expensive amount for my 100 computers package. Once I went over that threshold I had to convert to the 500 computers package which cost 4x was I was paying. That was true even if I had 101 computers and not 499. I ended up upgrading with a negotiated price but still don’t understand why it’s not…
Easier bookkeeping on their part.
Easier bookkeeping is the main ingredient of debate between consumption-based billing (AWS, Twilio, etc) vs user-based billing.