Live data from Hacker News

I analyzed SaaS billing dark patterns

quolum.com

131–140 of 190 posts

Re: I analyzed SaaS billing dark patterns

#131
post #23

These 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…

We all need a special version of this document we can bring to health care provider visits, something to the effect that they agree to inform of and get consent for any products or services that are Not covered by insurance BEFORE they are provided, since of course they are experts in medical issues and billing.

Re: I analyzed SaaS billing dark patterns

#132
post #96

Earlier quoted context omitted.

Multiple consecutive signups from the same IP address is one way. But as GP said, this and other signals require coding abuse detection, and then you must find a way to enforce this. This is not the kind of activity you want to be involved in while validating a product concept and working toward pmf.

In NZ some ISPs use cg-nat meaning that you will have many people under one public IPv4 address. Going by this logic you could ban a whole ISP in one go.

Also mobile networks have typically one public IP address.

Re: I analyzed SaaS billing dark patterns

#133

Some of these dark patterns like getting charged for 9 months without knowing doesn't make sense to me. Don't people have to file expense reports each month for their corporate credit cards?

expense reports going directly to the corporate card are signed-off. Finance see a "software charge" and assume that someone is actually using it. No red flags.

Re: I analyzed SaaS billing dark patterns

#134
post #88

Earlier quoted context omitted.

We have tried both trials with and without CC - the latter is obviously more effective. On the back-end however, this forced us to spend weeks developing an intelligent automated approval process to limit abuse (which is common). After that, monitoring systems alert humans to suspicious trial activity for further review. So it continues to be a lot of work. Financially, we love the idea of a true "free" trial. The ab…

I think we are on the same boat. How to do detect abusing the service?

Is the abuse typically just people re-signing up continually every two weeks? Or are there other super common abuses? This isn't my field and I have always detested the commonly required CC inputs for free trials, so interested to know more about the motivation from software builders.

Re: I analyzed SaaS billing dark patterns

#135

The dark pattern I like the least is the one where providers do not let you set a limit or budget for charges to your account per billing period. For example, I've yet to find a cloud provider that lets you, say, put a $200 a month spending limit on your account. The best we get is a notification system.

Imagine the issues on something like AWS, Google Cloud, Digital Ocean, Rackspace, etc. Imagine if a company sets a limit. One that allows for burst and growth. Then they forget to update it, and then one day, all their servers, data and everything else is gone. Even if things are offline, they accrue costs, so the only thing to do when a limit is reached is destroy everything. What’s the balance?

It should be trivial for the provider to compute the cost of offline resources and account for it when triggering the limit to give a few days to react before destroying everything.

Re: I analyzed SaaS billing dark patterns

#136
SaaS founder here (solo self-founded business), trying for years to be ethical and not use any "dark patterns". The article is one-sided and ill-informed, clearly written by someone who never ran a SaaS business and had to balance the books.

Those who run a SaaS will know what I'm talking about (for example, the difference between no-credit-card-required trials and credit-card-required trials is about support costs, not about secretly charging that first fee). They will read the article, conclude that it's ridiculous, and skip it.

For those who do not currently run a SaaS themselves, please critically read the article and do not immediately conclude that all SaaS businesses are immoral and use "dark patterns".

Re: I analyzed SaaS billing dark patterns

#137
post #79

> 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…

In general I don't think it's fair to describe anything as a dark pattern this is clearly communicated in a contract. Same with "Here’s a similar problem with a different scenario: You sign a one-year contract with a SaaS provider. You start paying immediately. The process to get API access, build integrations, set up the software, and onboard and train your team takes three months. In those three months, you still p…

This is like arguing nothing is unethical as long as it's legal.

Re: I analyzed SaaS billing dark patterns

#138
post #136

SaaS founder here (solo self-founded business), trying for years to be ethical and not use any "dark patterns". The article is one-sided and ill-informed, clearly written by someone who never ran a SaaS business and had to balance the books. Those who run a SaaS will know what I'm talking about (for example, the difference between no-credit-card-required trials and credit-card-required trials is about support costs,…

It's hard to run a business ethically so that gives you the right to run it unethically? Business convenience should rank far lower than personal convenience in the world.

I will _never_ provide a credit card for a free trial because some companies will charge you at the end of the trial and I don't have time to figure out whether you're one of those.

I will _never_ provide my phone number for "security reasons" because a load of companies used that excuse to get the phone number then used it for marketing or for correlating it with other personal data.

I say that as a failed SaaS co-founder. Being ethical was no part of the reason the SaaS failed.

Re: I analyzed SaaS billing dark patterns

#139
post #26

> Free trials should not require a credit card. Collecting your payment information is an obvious red flag that you will be billed as soon as the free trial period ends. I remember many people on HN defending this pattern saying that they are not interested in people who don't want to provide their CC details, that they are bad customers, they just want a free ride, and they are not sorry for setting it up like this.…

How is this a dark or “grey“ pattern. Are they being sneaky about it? At most it could be a signal that a business intends to be a douche, but that’s only because douchey companies ruined it. Just like duchey free customers ruined that for everyone. My employer probably thinks payroll is a “grey” pattern by this logic.

It's a dark pattern because they claim the trial is free, but ask for a credit card. They are betting on the user forgetting to cancel, or worse, actually make it difficult to cancel. If it was just about giving the user a chance to try a product, they wouldn't need to collect credit card information. Some people claim it helps to prevent abuse. Maybe, but there are other, user-friendly ways to prevent abuse.

Re: I analyzed SaaS billing dark patterns

#140
post #12

Earlier quoted context omitted.

Why does hosting need to be bundled with software upgrade and support? Hint: It doesn’t.

Because otherwise you’re on the hook to support N versions of the software instead of just one. It’s vastly easier, simpler and cheaper to support hosted software.

That’s simply not true. There is no reason why you couldn’t simply drop support for even very recent versions. Google and Apple do this today.
Post reply on HN