I analyzed SaaS billing dark patterns(quolum.com)
quolum.com
I analyzed SaaS billing dark patterns
https://quolum.com/blog/saas/i-analyzed-saas-billing-dark-patterns/
189 comments
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 abuse was the challenge but we're in a good place with it now. Customers/Potential-customers love it and so do we.
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 abuse was the challenge but we're in a good place with it now. Customers/Potential-customers love it and so do we.
> We have tried both trials with and without CC - the latter is obviously more effective.
More effective in initial trial signups or more effective in eventual paying clients?
More effective in initial trial signups or more effective in eventual paying clients?
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.
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.
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.
At this point, it's a long evolved set of heuristics based on any available data. Some quick rules around IP, Country, and email provider gets you a fair bit of the way there. But like any heuristic system that evolves, tweaking can get you to something that's "good enough".
The next step would be an AI system (like the very impressive Stripe Radar (which admittedly is in a different context)) but we're not ready for that, nor would it bring us significant value over our current system. And again - we pipe things to human for things in the grey area.
The next step would be an AI system (like the very impressive Stripe Radar (which admittedly is in a different context)) but we're not ready for that, nor would it bring us significant value over our current system. And again - we pipe things to human for things in the grey area.
It's about effort. The seller is asking you to put in the effort to enter your payment info in order to use the "free" version of the product. It's an exchange. The seller benefits because there is less friction to paying later.
The dark pattern is billing the card without consent from the user, or some weird implicit consent.
The dark pattern is billing the card without consent from the user, or some weird implicit consent.
> The seller is asking you to put in the effort to enter your payment info in order to use the "free" version of the product.
Yes, and they bear the cost of the users scared away by the extra step, so it’s sort of self limiting.
> The dark pattern is billing the card without consent from the user, or some weird implicit consent.
Yes, that’s valid to call out as a dark pattern, but the parent quoted the article as saying that requiring the credit card at all is a dark pattern or at least shouldn’t be done, so this isn’t a strawman.
Yes, and they bear the cost of the users scared away by the extra step, so it’s sort of self limiting.
> The dark pattern is billing the card without consent from the user, or some weird implicit consent.
Yes, that’s valid to call out as a dark pattern, but the parent quoted the article as saying that requiring the credit card at all is a dark pattern or at least shouldn’t be done, so this isn’t a strawman.
[deleted]
This is a perfectly valid thing to ask a user; it is part of a common dark pattern, but that does not mean it is itself bad; it is certainly sometimes necessary.
This is used as a dark pattern. Entering a credit card to try out a service without being able to see how you would cancel is asking a lot of faith in a service you are trying out. Asking for a credit card on signup means I've already decided you are worth it. I hope you spent a lot on marketing to prepare me.
Free trials can be limited in terms of services. Many times free trials are not necessary. If someone is willing to enter a credit they will pay a small amount.
Free trials can be limited in terms of services. Many times free trials are not necessary. If someone is willing to enter a credit they will pay a small amount.
I might be conservative here, but I will never trial a service that requests highly sensitive information and then makes me trust they won't sell that information to some third actor. Credit card first just screams "SCAMMER SITE" to me.
These days, I have a virtual credit card that allows me to change the CVC on demand, for just these kinds of services, and with that I void the use of this card for dark pattern payments immediately. If I think your service is worthy, I might give you good data.
These days, I have a virtual credit card that allows me to change the CVC on demand, for just these kinds of services, and with that I void the use of this card for dark pattern payments immediately. If I think your service is worthy, I might give you good data.
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.
You forget this is HN, where software engineers will go off on tangent talking about how "they could have designed the airplane rotor to not crash" or something equally ridiculous. Everyone here is an expert at everything, because they wrote a blog once, or since Paul Graham is perceived to be an expert on everything, they can be too.
[deleted]
> since Paul Graham is perceived to be an expert on everything, they can be too.
ROFL.
ROFL.
As you know, Bob, they let anybody on here regardless of occupation or knowledge of Phil Graham. So some random commenter could perfectly well be an aerospace engineer. Or someone that's never been employed in their whole life.
[deleted]
This is HN. It’s quite common that the people commenting have deep experience in the industry.
Credit card for trial is a dark pattern from the end user's perspective for sure.
Cos, that is one more place where the end user have to risk his/her/their PII. This is especially important considering the end user is trying the product out. The person has no idea whether they will invest in it or not. Yet, the person have to worry about their information leaked when he/she/they see this company on the news for a data breach.
Also, another problem is the overhead for the company on managing this data. The security, PR situation if this gets leaked. It's expensive and unnecessary. This is a risky business unless you are a data hoarder who sells them at which point that is again bad for the end user.
Cos, that is one more place where the end user have to risk his/her/their PII. This is especially important considering the end user is trying the product out. The person has no idea whether they will invest in it or not. Yet, the person have to worry about their information leaked when he/she/they see this company on the news for a data breach.
Also, another problem is the overhead for the company on managing this data. The security, PR situation if this gets leaked. It's expensive and unnecessary. This is a risky business unless you are a data hoarder who sells them at which point that is again bad for the end user.
what if the card transaction was handled by a well known processor? The SaaS business doesn't actually have to store the card details themselves - and this can be made clear.
Interesting question. My question again would be why?. You just transferred the responsibility from you (the SaaS company) to a well known processor. This doesn't make a data breach or data sharing avoidable/impossible.
Also, anything related to finance is always hot. And this comes back to the same thing I made in the above comment, why should an end user who is just trying it out risk all of this? It's like telling a stranger a secret of yours. You wouldn't just share a secret with a stranger just because they say "trust me", would you?
It is the company who needs the users attention, not the other way around. The users shouldn't be punished for the same.
Also, anything related to finance is always hot. And this comes back to the same thing I made in the above comment, why should an end user who is just trying it out risk all of this? It's like telling a stranger a secret of yours. You wouldn't just share a secret with a stranger just because they say "trust me", would you?
It is the company who needs the users attention, not the other way around. The users shouldn't be punished for the same.
> This doesn't make a data breach or data sharing avoidable/impossible.
this risk will always be present. Choosing a well known processor will reduce it quite a bit imho.
If you're asking why a user would take on this risk, i would say that they are getting a "free" trial in return. By having to take on this risk, the user is more conscious of using the product, and cut out the people who would just kick the tyres.
this risk will always be present. Choosing a well known processor will reduce it quite a bit imho.
If you're asking why a user would take on this risk, i would say that they are getting a "free" trial in return. By having to take on this risk, the user is more conscious of using the product, and cut out the people who would just kick the tyres.
I would have to respectfully disagree though. Cos like I said, the reason why free trial is there in the first place is to entice users. There are so many products without free trials.
Again, the burden should not be in the shoulders of the end user. There is no reason for the company to ask for credit card other than data sharing, other dark patterns and spam. Like many have mentioned, spam can be dealt with better by other means. These are companies who have tried it out. I don't know what else more to say. :)
Again, the burden should not be in the shoulders of the end user. There is no reason for the company to ask for credit card other than data sharing, other dark patterns and spam. Like many have mentioned, spam can be dealt with better by other means. These are companies who have tried it out. I don't know what else more to say. :)
A credit card for user validation is not necessarily a dark pattern. However, it has been abused by too many services to trick people into paying. Either by forgetting to cancel, or by having an automatic fee based on usage.
From one individual user’s perspective - card upfront trials mean that there’s a good chance either (a) I don’t want the product but will be unable to cancel the account due to dark ux/cx or (b) I’ll forget about the trial period and begin being billed then go through hell to get out of it.
I much much much prefer a no ties trial, even if you restrict functionality, volume or some other thing which makes it not useable for regular workloads. It’s a trial, I only need to get a feel for if I think this will work for me, then buy or move on.
I much much much prefer a no ties trial, even if you restrict functionality, volume or some other thing which makes it not useable for regular workloads. It’s a trial, I only need to get a feel for if I think this will work for me, then buy or move on.
> I’ll forget about the trial period and begin being billed then go through hell to get out of it
OK, this is probably a stupid question...but when signing up for a trial of product/service X, why not put a "decide on X" item on your calendar for sometime near the end of the trial?
OK, this is probably a stupid question...but when signing up for a trial of product/service X, why not put a "decide on X" item on your calendar for sometime near the end of the trial?
You’re right - that’s a no brainer everyone should be doing, but we don’t.
I provide a free trial for my product even without asking for an email address, customers can just download and test it.
From what I can tell, this works pretty well, a good amount of the ones who test the product and up purchasing (after 7 days you are prompted to purchase to continue using it).
From what I can tell, this works pretty well, a good amount of the ones who test the product and up purchasing (after 7 days you are prompted to purchase to continue using it).
Dont you think users with malintent abuse the platform irrespective of whether a card is on file or not?
Malintent exists on a spectrum and in my experience operating SaaS, a credit card is indeed a good filter for users who have no intention of ever paying you.
Credit cards act as a "cost" of sorts. Credit cards are a limited resource, it is not free to acquire more credit cards. By requiring a valid credit card you are basically relying upon the verification that credit card issuers do to prevent unlimited abuse.
Its not free to acquire credit cards? In what country?
I constantly get free offers on the mails, plus there are services to generate temporary card numbers for throwaway
I constantly get free offers on the mails, plus there are services to generate temporary card numbers for throwaway
bad actors are usually looking for low friction, it’s like running away from a bear… you don’t need to be the fastest person, you just don’t want to be the slowest
You're probably not going to go through the hassle of generating or applying for 1,000 credit cards in order to abuse some trial period on a SaaS service. Maybe you do it a few times.
It's the automated bots that a CC prevents. Even with "free" credit cards or generated numbers, there's a lot of friction in going through that to abuse the service's trial period.
It's the automated bots that a CC prevents. Even with "free" credit cards or generated numbers, there's a lot of friction in going through that to abuse the service's trial period.
> Credit cards are a limited resource
> it is not free to acquire more credit cards
If a user is malicious then they quite probably have access to malicious cards too.
Moreover, you're locking out users who don't want to give you their card just to try a service.
> it is not free to acquire more credit cards
If a user is malicious then they quite probably have access to malicious cards too.
Moreover, you're locking out users who don't want to give you their card just to try a service.
There are probably a lot more casual trolls than there are straight up criminals with stolen credit card numbers.
in my experience it’s an order of magnitude less frequent when a credit card is required
If getting the card upfront is about filtering free trial users, that doesn't support the usual behaviour of charging the user immediately after the trial ends. You can use a credit card as a filter without doing that.
> 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 decisions based on that commitment, such as hiring people, or themselves committing to bigger plans with their providers.
Why should they get screwed because you choked? Don't commit to long fixed periods if there is any doubt you won't make it.
> 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 decisions based on that commitment, such as hiring people, or themselves committing to bigger plans with their providers.
Why should they get screwed because you choked? Don't commit to long fixed periods if there is any doubt you won't make it.
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 paid for a service you couldn’t use yet. In fact, you had to pay to set it up! You had to pay upfront to get the functionality you needed."
Do I generally think that's a bad policy? Sure (depending on whether there are significant resources required on the software company's side for you to build your integration).
If you're told this is going to be the case and agree to it, is it a dark pattern? Clearly not.
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 paid for a service you couldn’t use yet. In fact, you had to pay to set it up! You had to pay upfront to get the functionality you needed."
Do I generally think that's a bad policy? Sure (depending on whether there are significant resources required on the software company's side for you to build your integration).
If you're told this is going to be the case and agree to it, is it a dark pattern? Clearly not.
That’s not really a fair way to evaluate contracts for fairness and ethical conduct. Not only does the contract have the obligation to be clear (and let’s be blunt the people that do this are often not trying to be clear about what they are doing) it also needs to meet basic standards of reasonableness.
Specifically, to the extent that a contract diverges sharply from the general understanding each party has about how the world works, the more the drafting party has an obligation to clearly call out the terms in a manner commensurate with the importance of the contract term.
Legal documents aren’t software code, it’s a classic mental error developers make when discussing them. They are evaluated by humans.
For example, it would not be reasonable to have a single sentence buried in the middle of a 20 page SaaS contract that obligated you to purchase cat food, or signed away the rights to your apartment. Wouldn’t matter how plainly worded the sentence was and if it was duly signed. You’d still have to convince a judge that was a reasonable thing to do. Good luck with that. And regardless of legality it’s obviously not ethical it’s a trick, intended to be deceptive.
Obviously there’s subtlety to this and the exact details matter. But that’s my point. You can’t just fall back on the idea that anything you get someone to agree to isn’t a dark pattern.
The whole point of dark patterns as a concept is that you’re tricking people into agreeing to unreasonable things.
Specifically, to the extent that a contract diverges sharply from the general understanding each party has about how the world works, the more the drafting party has an obligation to clearly call out the terms in a manner commensurate with the importance of the contract term.
Legal documents aren’t software code, it’s a classic mental error developers make when discussing them. They are evaluated by humans.
For example, it would not be reasonable to have a single sentence buried in the middle of a 20 page SaaS contract that obligated you to purchase cat food, or signed away the rights to your apartment. Wouldn’t matter how plainly worded the sentence was and if it was duly signed. You’d still have to convince a judge that was a reasonable thing to do. Good luck with that. And regardless of legality it’s obviously not ethical it’s a trick, intended to be deceptive.
Obviously there’s subtlety to this and the exact details matter. But that’s my point. You can’t just fall back on the idea that anything you get someone to agree to isn’t a dark pattern.
The whole point of dark patterns as a concept is that you’re tricking people into agreeing to unreasonable things.
What you're talking about is just clearly not the same point that I made.
I said: "In general I don't think it's fair to describe anything as a dark pattern this is clearly communicated in a contract."
You said: "or example, it would not be reasonable to have a single sentence buried in the middle of a 20 page SaaS contract that obligated you to purchase cat food,"
I specified that it has to be clearly communicated. You responded with an example of something that very obviously is not clearly communicated.
The examples that OP gave are generally things that are clearly communicated. When you sign up for a SaaS service and agree to pay for a set number of seats for a set duration, it's clearly communicated - after all, it's an absolutely basic part of the agreement and one that always has to be actively discussed between the parties (the SaaS vendor must tell you that you're billed on a per-seat basis, and you must tell them how many seats you need).
What you're describing is all true in theory but not applicable at all to my post or the examples of OP that I cited.
I said: "In general I don't think it's fair to describe anything as a dark pattern this is clearly communicated in a contract."
You said: "or example, it would not be reasonable to have a single sentence buried in the middle of a 20 page SaaS contract that obligated you to purchase cat food,"
I specified that it has to be clearly communicated. You responded with an example of something that very obviously is not clearly communicated.
The examples that OP gave are generally things that are clearly communicated. When you sign up for a SaaS service and agree to pay for a set number of seats for a set duration, it's clearly communicated - after all, it's an absolutely basic part of the agreement and one that always has to be actively discussed between the parties (the SaaS vendor must tell you that you're billed on a per-seat basis, and you must tell them how many seats you need).
What you're describing is all true in theory but not applicable at all to my post or the examples of OP that I cited.
I still disagree with your premise. You’re saying that as long as the terms are clearly communicated they’re not a dark pattern, aka unethical.
I think if you’re using your superior understanding of the dynamics of using your product to create unreasonable gotcha situations that customers would not have agreed to if they had any choice then that’s dark patterns.
There are lots of examples but most revolve around lock-ins and ratchet type mechanics. Things like making it easy to create data but punitively expensive to get it out in order to switch products.
Things like making it easy to scale up the service but literally impossible to downsize also can qualify, which was the issue we were both referring to.
Or your example of a setup period could also qualify. Sure if it’s like super clear I guess so, but it’s pretty easy to see that often in that scenario people don’t realize the implications of the “onboarding period” and it’s a bit of a trick.
I’m speaking from personal experience this kind of trickery is rampant in trying to interact with many of these services. I got far into negotiations with a household name marketing platform and notice they never once mentioned the mandatory fees for onboarding. They also never said a word about outbound email limits and data limits etc. I knew only from stories from someone who had gone with them, gotten locked into a year of spending, and discovered in the first week that the service was literally unsuitable for them given their requirements. I was in a similar negotiation with them at the time and they were trying to trap me in a similar way.
Humans have a pretty intrinsic concept of fairness. There’s a cottage industry of SaaS companies that don’t care about that and many of us find it exhausting and not ethical. They use deceptive tactics with customers and anti-competitive tactics to acquire or eliminate competitors so you don’t have choices.
It’s a fucking crisis. Which is why this whole thread is raging with comments.
I think if you’re using your superior understanding of the dynamics of using your product to create unreasonable gotcha situations that customers would not have agreed to if they had any choice then that’s dark patterns.
There are lots of examples but most revolve around lock-ins and ratchet type mechanics. Things like making it easy to create data but punitively expensive to get it out in order to switch products.
Things like making it easy to scale up the service but literally impossible to downsize also can qualify, which was the issue we were both referring to.
Or your example of a setup period could also qualify. Sure if it’s like super clear I guess so, but it’s pretty easy to see that often in that scenario people don’t realize the implications of the “onboarding period” and it’s a bit of a trick.
I’m speaking from personal experience this kind of trickery is rampant in trying to interact with many of these services. I got far into negotiations with a household name marketing platform and notice they never once mentioned the mandatory fees for onboarding. They also never said a word about outbound email limits and data limits etc. I knew only from stories from someone who had gone with them, gotten locked into a year of spending, and discovered in the first week that the service was literally unsuitable for them given their requirements. I was in a similar negotiation with them at the time and they were trying to trap me in a similar way.
Humans have a pretty intrinsic concept of fairness. There’s a cottage industry of SaaS companies that don’t care about that and many of us find it exhausting and not ethical. They use deceptive tactics with customers and anti-competitive tactics to acquire or eliminate competitors so you don’t have choices.
It’s a fucking crisis. Which is why this whole thread is raging with comments.
The problem is that you're not defining "dark pattern" reasonably.
"You’re saying that as long as the terms are clearly communicated they’re not a dark pattern, aka unethical."
You're saying that something being unethical makes it a dark pattern, and that's wrong. If I rob you at gunpoint, that's definitely unethical, but it's not a dark pattern.
"I think if you’re using your superior understanding of the dynamics of using your product to create unreasonable gotcha situations that customers would not have agreed to if they had any choice then that’s dark patterns."
Again, this is in no way relevant to the examples cited. Telling the customer that any seats they sign up for must be paid for a full year is not an unreasonably gotcha situation. It's a concept that's clearly explained, and one that won't be a surprise to anyone who has any experience purchasing SaaS products, because it's common industry practice.
As to the idea that they don't have a choice to agree, that's virtually never true with SaaS. It is an enormously competitive industry with multiple players in every major area. On top of that, if you're talking about tech companies buying SaaS products, they also have the option to build their own tools if they don't like the options that are available.
"Things like making it easy to create data but punitively expensive to get it out in order to switch products."
Again, this is true but in no way relevant to anything I've said. If it's clearly communicated that you're going to have to pay a million dollars to get your data out, it's a bad business practice but not a dark pattern.
You're applying the label "dark pattern" incorrectly to any SaaS practice you dislike. The phrase has a specific meaning, and any practice that is clearly and honestly communicated up front, even if it's a horrible practice, is not a dark pattern.
"You’re saying that as long as the terms are clearly communicated they’re not a dark pattern, aka unethical."
You're saying that something being unethical makes it a dark pattern, and that's wrong. If I rob you at gunpoint, that's definitely unethical, but it's not a dark pattern.
"I think if you’re using your superior understanding of the dynamics of using your product to create unreasonable gotcha situations that customers would not have agreed to if they had any choice then that’s dark patterns."
Again, this is in no way relevant to the examples cited. Telling the customer that any seats they sign up for must be paid for a full year is not an unreasonably gotcha situation. It's a concept that's clearly explained, and one that won't be a surprise to anyone who has any experience purchasing SaaS products, because it's common industry practice.
As to the idea that they don't have a choice to agree, that's virtually never true with SaaS. It is an enormously competitive industry with multiple players in every major area. On top of that, if you're talking about tech companies buying SaaS products, they also have the option to build their own tools if they don't like the options that are available.
"Things like making it easy to create data but punitively expensive to get it out in order to switch products."
Again, this is true but in no way relevant to anything I've said. If it's clearly communicated that you're going to have to pay a million dollars to get your data out, it's a bad business practice but not a dark pattern.
You're applying the label "dark pattern" incorrectly to any SaaS practice you dislike. The phrase has a specific meaning, and any practice that is clearly and honestly communicated up front, even if it's a horrible practice, is not a dark pattern.
I think we are well into semantics now but my understanding of dark patterns as a concept is things that only succeed due to trickery or intentional obscuring if what’s likely to happen that aren’t actually illegal.
They’re technically OK but we perceive them to be unethical and unfair. Which is why they get a special name.
If they were not technically allowed they’d just be fraud. Much like your robbery example isn’t a “dark pattern” because it’s a felony. We already have words for illegal stuff.
They’re technically OK but we perceive them to be unethical and unfair. Which is why they get a special name.
If they were not technically allowed they’d just be fraud. Much like your robbery example isn’t a “dark pattern” because it’s a felony. We already have words for illegal stuff.
Thanks for emphasizing about the line between illegal and dark. Makes total sense.
This is like arguing nothing is unethical as long as it's legal.
Come on now, you have to know that's a gross exaggeration.
It's arguing that no deal between two parties is unethical as long as both parties are clearly aware of all aspects of the deal and their consequences and neither party is coerced into agreeing to the deal.
It's arguing that no deal between two parties is unethical as long as both parties are clearly aware of all aspects of the deal and their consequences and neither party is coerced into agreeing to the deal.
Sure but the amount of seats is close to the most basic of specifications for a contract. Its not unethical to say "tough cookies" here - it's literally the entire purpose of the contract to make this agreement. You weren't tricked or forced, you just made a bad judgement or have bad luck.
I bought a bunch of Bananas and they sat in my kitchen bowl for 2 weeks. I ate probably half of them in that time, but after a couple of weeks, as expected they are off.
I demand Bananas compensate me for my losses. Typical banana dark patterns.
I demand Bananas compensate me for my losses. Typical banana dark patterns.
It helps to observe how symmetrical something is, to understand how equitable it is. In this case, if you want more seats, they'll happily give them to you and charge more, so it would seem fair that they should also be happy to reduce the number of seats and charge you less or refund you. If they only accept increases and not decreases, it's not particularly equitable.
Saas has obscene markups
It has "obscene markups" based on costs, but that is not how SaaS is priced. It's priced on value.
This is a very cynical take. Not all of these things are designed to trick you.
For example, requiring a credit card for a free trial is to prevent free trial abuse. A normal person can only get so many valid credit card numbers, assuming you can detect burner cards (which for the most part the CC companies will happily help you do).
Yes, a good company will notify you that a trial is going paid, and a great company will require an affirmative action on your part, but the main goal isn't to trick you and hope you forget.
Also, the part about not prorating costs if you use less resources. Usually you get a discount for paying up front. The reason you get a discount is because it allows the company to do more efficient resource planning, a savings they pass on to you. If they allowed you to cut back, you haven't upheld your part of the deal. A big company can absorb the loss, but a small one can't.
Yes, some companies do these are dark patterns to increase their profits. But most have some pretty good non-nefarious reasons to act like they do.
For example, requiring a credit card for a free trial is to prevent free trial abuse. A normal person can only get so many valid credit card numbers, assuming you can detect burner cards (which for the most part the CC companies will happily help you do).
Yes, a good company will notify you that a trial is going paid, and a great company will require an affirmative action on your part, but the main goal isn't to trick you and hope you forget.
Also, the part about not prorating costs if you use less resources. Usually you get a discount for paying up front. The reason you get a discount is because it allows the company to do more efficient resource planning, a savings they pass on to you. If they allowed you to cut back, you haven't upheld your part of the deal. A big company can absorb the loss, but a small one can't.
Yes, some companies do these are dark patterns to increase their profits. But most have some pretty good non-nefarious reasons to act like they do.
Agree with you, most companies have no malice. Especially, the ones that are early-stage, proving their PMF, and ready to scale are a pot of lovely gold. These companies are doing what it takes to make the customers happy.
Does Stripe detect something like privacy.com?
They might, but also privacy.com will not let you get more than two cards per site without a special exemption. I learned this when I tried using multiple cards for AWS, one for each app. They wouldn't let me do it.
So maybe Stripe knows which burner providers have their own restrictions and treat them differently?
So maybe Stripe knows which burner providers have their own restrictions and treat them differently?
Stripe doesnt.
Not trivial to detect something like privacy.com or for that matter any virtual card product.
Blacklisting such cards is a Hobson's choice [1] for the SaaS merchant. A lot of legit users with legit reasons use virtual cards and flagging them could be loss of revenue.
[1] https://en.wikipedia.org/wiki/Hobson%27s_choice
Not trivial to detect something like privacy.com or for that matter any virtual card product.
Blacklisting such cards is a Hobson's choice [1] for the SaaS merchant. A lot of legit users with legit reasons use virtual cards and flagging them could be loss of revenue.
[1] https://en.wikipedia.org/wiki/Hobson%27s_choice
Stripe Radar can be configured to provide signals that would reflect a virtual card, but not explicitly. Further trying to solve preventing virtual cards use potentially introduces false flags.
Requiring 3D secure may.
Depending on the product and audience, the prevalence of virtual cards may be extremely low. Outside of hackernews, the payments industry, and business cards nobody uses virtual cards like privacy.com
Requiring 3D secure may.
Depending on the product and audience, the prevalence of virtual cards may be extremely low. Outside of hackernews, the payments industry, and business cards nobody uses virtual cards like privacy.com
They probably have their own BIN/IIN. So it may be trivial. Still privacy.com per merchant cards are more likely to be actionable than stolen or prepaid cards.
I forgot the AWS password once for an account with only one S3 bucket.
I did the recovery procedure but they wanted to verify my identity using my document. I send them my ID, which was with a different address from my account information.
They didn't accept my ID and I wasn't able to stop the service and the recurring payment. Fortunately I registered my payment with a prepaid credit card, so was easy to empty the card and let them billing into the void.
Since then, I always use a prepaid card for recurring payment. It saved my ass in a way.
One of the largest dark pattern is also having a poor customer service.
They didn't accept my ID and I wasn't able to stop the service and the recurring payment. Fortunately I registered my payment with a prepaid credit card, so was easy to empty the card and let them billing into the void.
Since then, I always use a prepaid card for recurring payment. It saved my ass in a way.
One of the largest dark pattern is also having a poor customer service.
Is failure to pay (ie, card authorization) good enough for inability to cancel? Couldn't they just invoice you and hold you liable for fees regardless?
A failed card auth does not remove the obligation to pay. Most vendors write if off, and don't follow-up after a few emails. Plus, they don't want users to get pissed off and post a negative review.
Many vendors have now optimized their billing flow to reduce write-offs. They start charging on the first of the month for the upcoming use, and then cancel the account if the auth continues to fail.
Many vendors have now optimized their billing flow to reduce write-offs. They start charging on the first of the month for the upcoming use, and then cancel the account if the auth continues to fail.
> A failed card auth does not remove the obligation to pay.
Let them sue over it. They'll just love how the courts would rule in favor of a customer who clearly tried to recover their account in good faith and tried to cancel the billing in good faith and, failing both, canceled the billing in the only remaining way since the company provides literally zero customer-friendly options.
Let them sue over it. They'll just love how the courts would rule in favor of a customer who clearly tried to recover their account in good faith and tried to cancel the billing in good faith and, failing both, canceled the billing in the only remaining way since the company provides literally zero customer-friendly options.
Definitely the customer has a case if there is an intent to cancel the service. But, just ignoring based on a failed auth may not shift the liability.
Infact, when disputing such charges with the issuer, the customer always wins if there was an attempt to cancel the service.
Infact, when disputing such charges with the issuer, the customer always wins if there was an attempt to cancel the service.
Only until they try to collect and you produce proof that you tried A LOT to cancel
Some banks make this much easier by allowing you to spin up virtual cards w/ daily spend limits on them.
You'd love https://privacy.com/
I'm quite a bit leery of this article, even though some of it is pretty accurate. There are some glaring problems with it, and I would advise you not to take it as gospel truth. First, requiring a credit card for free trials is often necessary to weed out bad actors. Second, the author spends an awful lot of time complaining about being held to the terms of a contract that you willfully signed. I get that renegotiating a contract is nice to do for your customers, but it's a contract for a reason. Usually, when you signed up for that annual plan that you suddenly want out of, you were given a discounted rate by going annual. I notice that the author never mentions this when suggesting that companies are bad for holding up the terms of a contract. Finally keep in mind that this article is a marketing piece written by a saas product for rolling up saas payments.
> 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. Oh well. I guess with time more people get burned and will finally learn the hard way this is just one of many grey patterns.
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. Oh well. I guess with time more people get burned and will finally learn the hard way this is just one of many grey patterns.
It’s about what pisses off fewer customers. If I was stubborn and believed everything I read on HN about customers, I would continue to piss off a lot of people by designing under the assumption that I should only get CC details at the end of the trial.
For certain types of customers, it is surprising and annoying to have to fill out CC info at the end of a trial. The customer gets the notice the trial is ending soon, but ignores the part about adding CC info to keep using after the trial. Then the day comes, we get them on the phone to ask if they will stay with us, they say yes but the person who has control of the CC is gone for the day. You’re not really going to turn it off are you? Sorry, but we have to.
So the easy solution is to make the credit card form recommended but skippable. Skippers just need to know that the trial won’t be extended if they can’t pay. In either case, they still need to give the OK to charge at the end of the trial.
For certain types of customers, it is surprising and annoying to have to fill out CC info at the end of a trial. The customer gets the notice the trial is ending soon, but ignores the part about adding CC info to keep using after the trial. Then the day comes, we get them on the phone to ask if they will stay with us, they say yes but the person who has control of the CC is gone for the day. You’re not really going to turn it off are you? Sorry, but we have to.
So the easy solution is to make the credit card form recommended but skippable. Skippers just need to know that the trial won’t be extended if they can’t pay. In either case, they still need to give the OK to charge at the end of the trial.
This is exactly right. For years it was conventional business wisdom and best practice to focus on getting the CC. We could probably find some pretty embarrassing (for the web industry) threads if we wanted to look.
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.
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.
I disagree. I can't see how this is a dark pattern / trick. They are just saying if you want to participate in the trial they need to validate that you're serious about it. If you don't like these upfront terms, then you can bail right there and then. If however they are being sneaky about the CC requirement, or actually bill you a month later, then I could see that qualifying as a dark pattern (or straight up fraud).
I probably wouldn't move forward as a potential customer myself once the credit card requirement pops up unless I'd already done my research and was pretty sure I wanted to use that product.
They could lose potential customers, but they also probably eliminate a massive amount of customer support... which maybe they just can't afford yet. Customer support isn't free.
I probably wouldn't move forward as a potential customer myself once the credit card requirement pops up unless I'd already done my research and was pretty sure I wanted to use that product.
They could lose potential customers, but they also probably eliminate a massive amount of customer support... which maybe they just can't afford yet. Customer support isn't free.
> Just like duchey free customers ruined that for everyone.
But you need to factor this in. Nobody forces you to offer free trial. But if you do, you need to accept the fact that there are people who are going to use your product for free to the maximum available capacity.
In the old days, it wasn't much of a problem: you basically gave away pieces of software that stopped working after a certain period usually with limited functionality. There were many variants of this model: demo, trial, shareware. These free users didn't incur any direct costs for you (often someone else would do that for you, like computer magazines). Now, with SaaS, you need to provide computing resources for them - but this is your marketing cost. This is the problem of the model, not the customers. If you tell them they can use it for free for 2 weeks, they have the full right to use it and stop, period. They are not duchey unless they abuse the system by doing something clearly wrong, e.g. exploiting a bug in your software.
But you need to factor this in. Nobody forces you to offer free trial. But if you do, you need to accept the fact that there are people who are going to use your product for free to the maximum available capacity.
In the old days, it wasn't much of a problem: you basically gave away pieces of software that stopped working after a certain period usually with limited functionality. There were many variants of this model: demo, trial, shareware. These free users didn't incur any direct costs for you (often someone else would do that for you, like computer magazines). Now, with SaaS, you need to provide computing resources for them - but this is your marketing cost. This is the problem of the model, not the customers. If you tell them they can use it for free for 2 weeks, they have the full right to use it and stop, period. They are not duchey unless they abuse the system by doing something clearly wrong, e.g. exploiting a bug in your software.
Support costs need to be factored in too. Free customers can often have an enormous customer support cost. They'll send emails to [email protected] if they can't find a support email with questions along the lines of "How do I do x..." (which might be completely covered by the documentation they didn't read), or "I have a suggestion...".
You have to weigh the pros and cons. In some cases the cons might outweigh the pros and so you further qualify your free users, for example by requiring a Credit Card.
This can be a big problem in freemium (and open source) type products.
You have to weigh the pros and cons. In some cases the cons might outweigh the pros and so you further qualify your free users, for example by requiring a Credit Card.
This can be a big problem in freemium (and open source) type products.
This one doesn't bother me. In this scenario they're providing a real actual product that presumably they've worked hard on and has value. The free trial is their way of demonstrating that they have faith it's a good product and I'll want it. My credit card is a way of demonstrating that I'm a real customer that will pay if I do turn out to value it.
That seems like a reasonably balanced transaction on both sides, not sure it fits into this framework. There are so many far far worse practices out there.
That seems like a reasonably balanced transaction on both sides, not sure it fits into this framework. There are so many far far worse practices out there.
> My credit card is a way of demonstrating that I'm a real customer that will pay if I do turn out to value it.
I see your point but there are many problems with this approach.
1. First, I'm not sure if I'll actually pay. It will happen only if your product manages to convince me it is what I need, that there are no bugs, that the support quality is good enough etc.
2. For core functions related to my business, if available, I'll always choose non-SaaS solution over SaaS-based to avoid vendor lock-in and unnecessary dependence. So, the conclusion of (1) and (2) is that you need to convince me to try it and stay. You will increase your chances by making the CC data part skippable.
3. I burned a few times in the past (with shady cancellation polices). Even if you are a honest business, I have no idea what expect. Why don't you let us get into a closer relationship instead of putting your hand in my pocket before we even got properly introduced?
4. Very often I just need to understand what the project is about. Sorry, most marketing descriptions are utter garbage and the exceptions are quite rare. So I really need to try to even consider the purchase. And I do pay - I pay with my time and attention that I give to your project. If you block this possibility, you lose, not me.
I see your point but there are many problems with this approach.
1. First, I'm not sure if I'll actually pay. It will happen only if your product manages to convince me it is what I need, that there are no bugs, that the support quality is good enough etc.
2. For core functions related to my business, if available, I'll always choose non-SaaS solution over SaaS-based to avoid vendor lock-in and unnecessary dependence. So, the conclusion of (1) and (2) is that you need to convince me to try it and stay. You will increase your chances by making the CC data part skippable.
3. I burned a few times in the past (with shady cancellation polices). Even if you are a honest business, I have no idea what expect. Why don't you let us get into a closer relationship instead of putting your hand in my pocket before we even got properly introduced?
4. Very often I just need to understand what the project is about. Sorry, most marketing descriptions are utter garbage and the exceptions are quite rare. So I really need to try to even consider the purchase. And I do pay - I pay with my time and attention that I give to your project. If you block this possibility, you lose, not me.
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" clauses where it says this contract incorporates terms and conditions that are at the following URL and it's 45 pages into the fine print of that URL. I mean supposedly, since it's their URL and could just change the terms whenever they want and lie about it.
Which by the way wasn't clickable in the Docusign. Basically it was in an unlit basement behind a sign that said beware of the leopard.
It's not ethical. It's just exhausting to deal with some of these companies. I think we all know who they are, they tend to be concentrated in the field of SaaS companies that cater to the sales and marketing functions.
Lately I've had what I've found to be a fairly clever solution however. We wrote up a standard document that contains our terms and conditions for SaaS providers.
The key clauses basically say "We hereby give formal notice that we do not consent to any automatic term renewals, any automatic price increases, any charges to credit cards made 'on account' without our specific consent as to the date and amount charged. To the extent our agreement requires advance written notice of any of the above this letter serves as that notice." and so on.
Then we send it certified mail to the company's corporate HQ address and keep the tracking number. We do this on the same day we sign any software contract, it's basically an automated process at this point.
So whenever it comes around, and it has, we just say sorry we've already given formal written notice we don't consent to that. Here's a scan of the document and the USPS receipt maybe work on your internal communications.
The fact that we have to do this is apalling but hey it's better than the alternative.
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" clauses where it says this contract incorporates terms and conditions that are at the following URL and it's 45 pages into the fine print of that URL. I mean supposedly, since it's their URL and could just change the terms whenever they want and lie about it.
Which by the way wasn't clickable in the Docusign. Basically it was in an unlit basement behind a sign that said beware of the leopard.
It's not ethical. It's just exhausting to deal with some of these companies. I think we all know who they are, they tend to be concentrated in the field of SaaS companies that cater to the sales and marketing functions.
Lately I've had what I've found to be a fairly clever solution however. We wrote up a standard document that contains our terms and conditions for SaaS providers.
The key clauses basically say "We hereby give formal notice that we do not consent to any automatic term renewals, any automatic price increases, any charges to credit cards made 'on account' without our specific consent as to the date and amount charged. To the extent our agreement requires advance written notice of any of the above this letter serves as that notice." and so on.
Then we send it certified mail to the company's corporate HQ address and keep the tracking number. We do this on the same day we sign any software contract, it's basically an automated process at this point.
So whenever it comes around, and it has, we just say sorry we've already given formal written notice we don't consent to that. Here's a scan of the document and the USPS receipt maybe work on your internal communications.
The fact that we have to do this is apalling but hey it's better than the alternative.
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.
I have crossed out terms in a standard health care release and given it back without anyone saying anything. So that’s one data point.
I’ve also repeatedly been asked to sign one of those electronic signature pads as the signature to a document that I am not actually seeing. Which is a ridiculous thing to even consider as a workflow. When that happens I just sign the words “not shown document” instead of my name and move on.
I’ve also repeatedly been asked to sign one of those electronic signature pads as the signature to a document that I am not actually seeing. Which is a ridiculous thing to even consider as a workflow. When that happens I just sign the words “not shown document” instead of my name and move on.
> We all need a special version of this document we can bring to health care provider visits
Which they will the decline to sign and require you instead to sign there standard, cleared-by-their-legal consent to treatment form before providing any services.
If you could afford the kind of providers that would be willing to even consider a nonstandard agreement, this probably wouldn't be a concern you would have in the first place.
Which they will the decline to sign and require you instead to sign there standard, cleared-by-their-legal consent to treatment form before providing any services.
If you could afford the kind of providers that would be willing to even consider a nonstandard agreement, this probably wouldn't be a concern you would have in the first place.
Interesting idea.
But isn't there a risk that if the company that gets your certified mail, reads it, and then cancels your account?
But isn't there a risk that if the company that gets your certified mail, reads it, and then cancels your account?
Sure I suppose that's a risk. But then they'd be in breach of the contract since the letter definitely doesn't say to cancel the account, it says that this is notice given to all extant notice clauses that could result in additional billing, renewal, and so on. It's worded well I'm paraphrasing.
As a practical matter though I don't think there's much to worry about. These guys don't have a process to field letters like this.
The joy comes from the elegance of it all. If they want to play a game of exploiting the fact that people don't read the fine print then they should be prepared for a fair contest.
As a practical matter though I don't think there's much to worry about. These guys don't have a process to field letters like this.
The joy comes from the elegance of it all. If they want to play a game of exploiting the fact that people don't read the fine print then they should be prepared for a fair contest.
> The joy comes from the elegance of it all. If they want to play a game of exploiting the fact that people don't read the fine print then they should be prepared for a fair contest.
:clap:
:clap:
Ironically, I think you could sell this as a product/service.
Does it actually work? Have you tested in in court?
Haven't made it to court but it would certainly be legally sound. Courts love certified mail and formal notices it's not even clear what counterargument they could have. They require notice, and we gave notice and can prove it.
But in real life what it really does it get them to back off and go back to having a normal negotiation about what we do want to do for renewal instead of the bullshit attempt to mislead and trap us.
Needless to say if there's any viable alternatives to companies that do this we take them but in some categories all the options suck.
But in real life what it really does it get them to back off and go back to having a normal negotiation about what we do want to do for renewal instead of the bullshit attempt to mislead and trap us.
Needless to say if there's any viable alternatives to companies that do this we take them but in some categories all the options suck.
I am thinking the argument against would be that the company's contract with you was supported by consideration: they provide the software in exchange for your payment. You are then sending what is intended as an addendum to the original contract, but the company never agreed to the additional terms. In effect, it is an offer of a second contract that is not supported by consideration and likely never accepted by the company. In such a case it would not be enforceable I think.
"The trick is making it the same day you sign the deal and making it all inclusive."
I think the original contract is enforceable at the time it was originally agreed to. Coming up with additional terms, even if they were on the same day, wouldn't not change the original contract. Imagine signing up for a credit card offer and then sending a certified letter to the bank informing them that you will only pay a lower interest rate that you designate.
I think the stronger argument is the "incorporated by reference" argument, given the fact that those could be changed at a later time. The terms of a contract need to be clear, and any ambiguity would likely be settled in favor of the party to be charged.
I have always been suspicious of the "Click to Agree" box at then end of a long contract that no one, including the company offering it, has ever read. The problem is that there are so many (generally unlikely) contingencies that have to be accounted for. What other choice is there when there may be substantial liability in question?
I think the original contract is enforceable at the time it was originally agreed to. Coming up with additional terms, even if they were on the same day, wouldn't not change the original contract. Imagine signing up for a credit card offer and then sending a certified letter to the bank informing them that you will only pay a lower interest rate that you designate.
I think the stronger argument is the "incorporated by reference" argument, given the fact that those could be changed at a later time. The terms of a contract need to be clear, and any ambiguity would likely be settled in favor of the party to be charged.
I have always been suspicious of the "Click to Agree" box at then end of a long contract that no one, including the company offering it, has ever read. The problem is that there are so many (generally unlikely) contingencies that have to be accounted for. What other choice is there when there may be substantial liability in question?
The enforceability of the original contract is not being challenged in this example.
It’s about required notices. Basically the contract has opt-out provisions that they hope you either won’t notice or will forget to opt-out of.
The idea is simple, you just reverse this dynamic by immediately and pre-emptively opting out of every optional element of the contract that could cause you to incur additional financial obligation.
It’s about required notices. Basically the contract has opt-out provisions that they hope you either won’t notice or will forget to opt-out of.
The idea is simple, you just reverse this dynamic by immediately and pre-emptively opting out of every optional element of the contract that could cause you to incur additional financial obligation.
It’s not an amendment to the contract it’s notice.
If the contract says you must give a non renewal notice by X date or you agree to a renewal then the letter is written notice. The trick is making it the same day you sign the deal and making it all inclusive.
It doesn’t change the existing contract it abides by it.
If the contract says you must give a non renewal notice by X date or you agree to a renewal then the letter is written notice. The trick is making it the same day you sign the deal and making it all inclusive.
It doesn’t change the existing contract it abides by it.
Forgetting to kill your cloud instances and getting charged isn't a dark pattern, no more than forgetting to fill your gas tank isn't an automotive manufacturing dark pattern, or leaving your water running in the basement sink and forgetting all winter and then having a fight with your husband just before Christmas because the water bill is $1000 and you're the only one that uses the basement utility sink but only in the summer because it is too cold in the winter...
I would say it's dark because the platform does not usually place any emphsasis in letting you know it's still there or not. There are no built in safety rails (like a check fuel light) that can help. These platforms are designed to be obtuse.
I'd challenge these being "obtuse", I think it's more likely that they are designing for a different type of customer.
As an engineer working on a production system, everything in code, etc, I don't really want an alert saying "Are you sure you still want to be running your database?". This isn't really a feature that most production systems need.
What I'd like to see is features for experimental work – being able to mark an AWS account, or org, or maybe individual services/resources, as "experimental" and have it auto shut off after some reasonable amount of time, with clear warnings during use (as much as possible) that this is an unsupported experimental service.
Hell, if the time limit/capacity limit was low enough, I feel like these could be a permanent free plan with cloud providers.
The question is: are these customers worth designing features for? I could see why they might not be, although I think it would be beneficial to the industry.
As an engineer working on a production system, everything in code, etc, I don't really want an alert saying "Are you sure you still want to be running your database?". This isn't really a feature that most production systems need.
What I'd like to see is features for experimental work – being able to mark an AWS account, or org, or maybe individual services/resources, as "experimental" and have it auto shut off after some reasonable amount of time, with clear warnings during use (as much as possible) that this is an unsupported experimental service.
Hell, if the time limit/capacity limit was low enough, I feel like these could be a permanent free plan with cloud providers.
The question is: are these customers worth designing features for? I could see why they might not be, although I think it would be beneficial to the industry.
That's a good point(s). I don't need lots of obvious messages about what my system is doing if I already understand it. However, I'd like to see a "verbose" or "-vvvv" or "DEBUG=9" for any service.
I think I might be speaking from bias because I only use about 8~10 AWS services, but perhaps if I jumped into their ML stuff I wouldn't know wtf is going on. So maybe a beginner-billing mode switch would be helpful.
While most new programmers don't like to RTFM (at all!) and expect a quick search of stackoverflow to solve everything, I think the number of complaints of stealth billing are SO high on HN that it appears systemic. That's not good.
I think I might be speaking from bias because I only use about 8~10 AWS services, but perhaps if I jumped into their ML stuff I wouldn't know wtf is going on. So maybe a beginner-billing mode switch would be helpful.
While most new programmers don't like to RTFM (at all!) and expect a quick search of stackoverflow to solve everything, I think the number of complaints of stealth billing are SO high on HN that it appears systemic. That's not good.
Forgetting to shut down an instance in the cloud is the least worrying problem. In AWS, everything has a price. And some things don’t have a price until they’re the only thing left(ie. Elastic IPs that only charge once they are not assigned to an instance). For someone new to AWS and testing things out, a closer analogy would be like moving into a new house and trying to find out which pipes are leaking
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.
Ah yes they call those evergreen contracts in the US. Month-to-month works for me. It gives us both an out if one of us ends up not liking the other.
> As a result, ended up writing a small PWA to keep track of my contracts and subscriptions.
You can provide this as a yearly service where if by the ninth month they don’t cancel, they must use it for another year ;)
Edit: oh you already do sans the contract terms
> As a result, ended up writing a small PWA to keep track of my contracts and subscriptions.
You can provide this as a yearly service where if by the ninth month they don’t cancel, they must use it for another year ;)
Edit: oh you already do sans the contract terms
Whaat! This one is new. You mean subscriptions from your neighborhood store such as milk, bread, newspapers, etc?
More like gym, "clubs" (Verein-s), mobile phone, internet, electricity, etc. It's an established contractual practice, and e.g. Telekom are not in any way obligated to notify you when your cancellation date approaches. They can very well sue you, however, should you refuse to pay your automatically-renewed-in-advance contract.
Even in the cases where you're allowed to cancel on the last day of the subscription, we as humans are very prone to forget to do that, particularly for longer-term contracts. Tracking contracts and subscription deadlines is a damn profitable habit that I wish I had acquired much earlier.
Even in the cases where you're allowed to cancel on the last day of the subscription, we as humans are very prone to forget to do that, particularly for longer-term contracts. Tracking contracts and subscription deadlines is a damn profitable habit that I wish I had acquired much earlier.
Curious: if they sue, then the only damage is money they owe or there is more to it such as credit history, etc?
I haven't really tested it in court, though I did get the official correspondence that leads up to it. Friendly law practitioner had suggested that I really don't stand a chance.
Not sure about credit damage, but in case of a loss in such a suit, I'd also have to cover the expenses for the other side, so it's a risky proposition.
With my wife we did consider it for a while, but then decided it's better to do focus on solving that problem with software and thus started working on contrax.app (shameless plug!).
Not sure about credit damage, but in case of a loss in such a suit, I'd also have to cover the expenses for the other side, so it's a risky proposition.
With my wife we did consider it for a while, but then decided it's better to do focus on solving that problem with software and thus started working on contrax.app (shameless plug!).
Newspapers, fitness studios, mobile providers, railway discount ticket (Bahncard). Can't say for neighborhood stores, I haven't really used a subscription at such a shop.
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".
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".
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.
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.
> It's hard to run a business ethically so that gives you the right to run it unethically?
The word "ethically" implies a strong moral judgment.
We can discuss ethics of course. For example, why would you think that charging at the end of a free trial is a problem, if this is clearly stated when signing up, notification E-mails are sent before any charge happens, and refunds are provided with no questions asked when necessary? What exactly is "unethical" here?
But my point was that many of these decisions are made not because of evil approach to making more money, but because of very practical and down-to-earth things. For example, requiring credit card information before a free trial reduces your signups considerably, leaving only the most serious potential customers. That lessens your support and onboarding load, because you do not spend time supporting non-customers that would not pay you anyway. Obviously this is not a clear-cut decision, but I'm trying to point out that the basis for making those decisions has nothing to do with morals, ethics or "dark patterns".
That kind of "dark pattern" conspiracy thought implies a lack of understanding of how a SaaS operates. It's very naïve to think that a SaaS business would care about charging for the first month through "dark patterns". If you run a SaaS, you care about long-term customers, retention, LTV and MRR. New signups are often actually a loss over the first months. So grabbing someones $49 through a "dark pattern" makes no sense: it actually lowers your important metrics, and makes you lose money, because that customer will usually contact support.
The word "ethically" implies a strong moral judgment.
We can discuss ethics of course. For example, why would you think that charging at the end of a free trial is a problem, if this is clearly stated when signing up, notification E-mails are sent before any charge happens, and refunds are provided with no questions asked when necessary? What exactly is "unethical" here?
But my point was that many of these decisions are made not because of evil approach to making more money, but because of very practical and down-to-earth things. For example, requiring credit card information before a free trial reduces your signups considerably, leaving only the most serious potential customers. That lessens your support and onboarding load, because you do not spend time supporting non-customers that would not pay you anyway. Obviously this is not a clear-cut decision, but I'm trying to point out that the basis for making those decisions has nothing to do with morals, ethics or "dark patterns".
That kind of "dark pattern" conspiracy thought implies a lack of understanding of how a SaaS operates. It's very naïve to think that a SaaS business would care about charging for the first month through "dark patterns". If you run a SaaS, you care about long-term customers, retention, LTV and MRR. New signups are often actually a loss over the first months. So grabbing someones $49 through a "dark pattern" makes no sense: it actually lowers your important metrics, and makes you lose money, because that customer will usually contact support.
> But my point was that many of these decisions are made not because of evil approach to making more money, but because of very practical and down-to-earth things.
You make these decisions for these reasons, and others do it so they can charge me at the end of a free trial. I don't have time to figure which one of these companies you are.
That being said, if I got redirected to a CC company website so they could verify my identity and give you a token, so you can prevent free trial abuse, I'd be down with that.
You make these decisions for these reasons, and others do it so they can charge me at the end of a free trial. I don't have time to figure which one of these companies you are.
That being said, if I got redirected to a CC company website so they could verify my identity and give you a token, so you can prevent free trial abuse, I'd be down with that.
I’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 a price per computer.
Not having consumption-based billing is definitely a callout issue and many exploit the simplicity of bundled t-shirt (Small, Medium, Large) SaaS pricing.
Easier bookkeeping on their part.
Easier bookkeeping is the main ingredient of debate between consumption-based billing (AWS, Twilio, etc) vs user-based billing.
That might be the reason for the different tiers but there is definitely a dark pattern in the auto-upgrade GP describes. LogMeIn could just as easily put a hard stop at 100 computers with a notification the user needs to upgrade to a higher tier package. Instead they auto-upgrade the user without asking. (I’m assuming there’s no way to avoid the auto-upgrade. It’s one thing if a user opts in to the tier scaling for their own convenience I think that’s different.)
In their defense, I wasn’t auto-upgraded. I just couldn’t add computers anymore. I hovered around 99 for a while, removing old computers, but one day I had to open up my wallet.
Hubspot. The yearly plan is way cheaper. But you need to cancel it 3 months in advance or you’re on the hook for ‘the same period’, thus another year. No reminder email of course.
FullStory sent us a reminder email last week that we need to cancel 2 months before the annual contract ends. I started a Slack thread, we all agreed we love FullStory, done. I think SaaS that try to trick their customers by not reminding them about their cancellation policy (which isn't consistently 1 month, 2 months, or anything, and is hard to track when you're a small startup) are just afraid their product isn't good enough or valuable enough for people to renew. Instead of improving their product, some exec can say "let's not remind them", and get about the same rate of retention.
applicable to a majority of annual contracts of top SaaS vendors.
I got locked into a reseller agreement with JustHost for my wife's GSuite account, which she uses for her full-time work. Now I'm paying them $90 a year just so I can retain my GSuite services without her having any downtime or losing her data.
Only recently did I discover GSuite has an FAQ for getting out of reseller agreements. Going to have to act on that.
Only recently did I discover GSuite has an FAQ for getting out of reseller agreements. Going to have to act on that.
> Companies waste tens of thousands of dollars every year on SaaS products they subscribe to but don’t use. And when I say “don’t use,” I literally mean zero logins for paid users during a subscription period.
We have a SaaS product, and we see that as well. Usually our sales folks will have a look every now and then and see if there's a lack of activity.
Almost always it's the result of someone quitting or losing their job, and our software gets lost in the handover of responsibilities. I've heard of several cases where sales has effectively re-sold our software more than 3-4 times to the same division in a company over the years.
We have a SaaS product, and we see that as well. Usually our sales folks will have a look every now and then and see if there's a lack of activity.
Almost always it's the result of someone quitting or losing their job, and our software gets lost in the handover of responsibilities. I've heard of several cases where sales has effectively re-sold our software more than 3-4 times to the same division in a company over the years.
This 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.
“Free trials should not require a credit card.”
I have a small project where I allow people to auto-translate their web and mobile applications. I’m using Google Translate and DeepL for translating texts from language to another. DeepL charges me $20 for every 500k translated characters. What I supposed to do? I’m getting a bit pissed off because I spotted multiple accounts who registered for the highest plan, used the whole auto-translation quota and quit without paying. Sometimes, users just misbehaving, and this is the reason why there are some dark patterns. Personally, I don’t use any. If you are looking for some decent i18n platform, try SimpleLocalize.io
Registering for the highest tier plan definitely shouldn't mean a free trial. Why didn't you charge them upfront the moment they wished to choose a bigger non-free plan?
While there are some valid points here, a lot of it seems to be moaning about having to pay for your own lack of good capacity planning, as if someone else should eat the cost of your estimates being inaccurate or plans falling through.
> That’s eight months of paying for nothing.
You signed up for a service. You stop using the service but don't cancel. How is that anyone else's fault? Furthermore, your accounting is so bad that you didn't notice for months. Making cancellation difficult and other similar things are dark patterns, this complaint though is just disorganised people trying to pass the buck.
> If you’d received an email before the bill hit
That would be nice, and many providers do that (I get an invoice for the dedicated server I don't properly use yet each month, which is a reminder that I should get around to the rest of the things it was intended for or downscale the operation), but you could also set reminders when you sign up for something, or keep an eye on your accounts.
> Unused seats? Still gotta pay for ‘em.
Ask yourself this: if you had customers who agreed to x00 users each and you paid for infrastructure and employed support staff to support this level of user activity, would you be happy to take the hit when half those user accounts don't all end up being needed? I doubt it, so you shouldn't expect other businesses to do so either. Your planning failure is not someone else's problem.
> But what if ... you actually ... wanted to add the seats. Well, the CRM would be only too happy to accommodate!
Again I wonder how much business the writer is willing to give away for free. There are no links to their own policies to suggest that they operate better than what is being complained about here - if such evidence existed I'd expect a noise to be made.
The real issue that is here sometimes is deliberately unhelpful bracketing of payment plans, jumping straight from 20 to 100 to 1000 seats with no provision to pay for a smaller amount of extra seats (perhaps at the 20-plan per-seat cost) because you need 110. But simply expecting to maybe not have to pay at all for the extra is a sign of a distasteful entitlement personality defect.
> I’d love to know if you’ve seen or experienced these dark patterns — or worse!
Ah, the infamous “please gift us free content for our future articles”!
> That’s eight months of paying for nothing.
You signed up for a service. You stop using the service but don't cancel. How is that anyone else's fault? Furthermore, your accounting is so bad that you didn't notice for months. Making cancellation difficult and other similar things are dark patterns, this complaint though is just disorganised people trying to pass the buck.
> If you’d received an email before the bill hit
That would be nice, and many providers do that (I get an invoice for the dedicated server I don't properly use yet each month, which is a reminder that I should get around to the rest of the things it was intended for or downscale the operation), but you could also set reminders when you sign up for something, or keep an eye on your accounts.
> Unused seats? Still gotta pay for ‘em.
Ask yourself this: if you had customers who agreed to x00 users each and you paid for infrastructure and employed support staff to support this level of user activity, would you be happy to take the hit when half those user accounts don't all end up being needed? I doubt it, so you shouldn't expect other businesses to do so either. Your planning failure is not someone else's problem.
> But what if ... you actually ... wanted to add the seats. Well, the CRM would be only too happy to accommodate!
Again I wonder how much business the writer is willing to give away for free. There are no links to their own policies to suggest that they operate better than what is being complained about here - if such evidence existed I'd expect a noise to be made.
The real issue that is here sometimes is deliberately unhelpful bracketing of payment plans, jumping straight from 20 to 100 to 1000 seats with no provision to pay for a smaller amount of extra seats (perhaps at the 20-plan per-seat cost) because you need 110. But simply expecting to maybe not have to pay at all for the extra is a sign of a distasteful entitlement personality defect.
> I’d love to know if you’ve seen or experienced these dark patterns — or worse!
Ah, the infamous “please gift us free content for our future articles”!
I really appreciate how Slack handles things by scaling down your payment month by month based on how many users are actually using the service. I wish more SaaS providers, especially big ones with the capacity to develop the feature, would do this rather than lean on people or companies forgetting to remove seats.
Slack is the gold standard.
I reached out to a Senior Product person at a very large SaaS vendor on auto-scaling the seats -- based on simple monthly active.
His response: "Our Sales team would never let that happen."
I reached out to a Senior Product person at a very large SaaS vendor on auto-scaling the seats -- based on simple monthly active.
His response: "Our Sales team would never let that happen."
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.
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?
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?
I'm implementing this in my cloud hosting platform (https://primcloud.com) and how we plan to do it is email triggers when certain thresholds are met, and if no action is taken, give a grace period before taking stuff offline.
Yes they will be charged for that grace period, but setting a limit of $200 and being charged $250 sure beats getting a random $1,000 charge.
Yes they will be charged for that grace period, but setting a limit of $200 and being charged $250 sure beats getting a random $1,000 charge.
> 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.
That's not the only thing you can do.
It takes quite a while from non-payment for OVH to take down their clients' services and delete their data, for example. They give customers a month long grace period before taking their service offline, and then there's another waiting period before they delete the data. At any point clients can resume service with payment.
That's not the only thing you can do.
It takes quite a while from non-payment for OVH to take down their clients' services and delete their data, for example. They give customers a month long grace period before taking their service offline, and then there's another waiting period before they delete the data. At any point clients can resume service with payment.
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.
Another dark pattern is the use of credits.
You subscribe for $X/month. That buys you Y credits, which you then spend at different rates depending on your usage. Some services are credits per minute, some are fixed credit amounts.
Not only do you have to guess your capacity requirements, you also then have to translate that into a series of tiered variable costs and fixed costs, and translate from credits to currency (often working through bulk purchasing rates) to figure out how much you'll be billed.
I manage a SaaS contract that bills like this and I'm not sure I've ever accurately predicted our bill. Also one of their fixed credit cost items is clearly 10x more expensive than it should be when you actually work through the numbers to see how much it costs.
You subscribe for $X/month. That buys you Y credits, which you then spend at different rates depending on your usage. Some services are credits per minute, some are fixed credit amounts.
Not only do you have to guess your capacity requirements, you also then have to translate that into a series of tiered variable costs and fixed costs, and translate from credits to currency (often working through bulk purchasing rates) to figure out how much you'll be billed.
I manage a SaaS contract that bills like this and I'm not sure I've ever accurately predicted our bill. Also one of their fixed credit cost items is clearly 10x more expensive than it should be when you actually work through the numbers to see how much it costs.
Datadog for the win in dark-pattern land.
Love the software, hate the billing.
Love the software, hate the billing.
I run a SaaS service and noticed we did a couple of these 'dark patterns', but not intentionally!
I've now added to our short term roadmap changes that will resolve these problems.
1. Emailing account holders a couple of days before billing to give them an opportunity to cancel.
2. Emailing account holders whenever a change to their account occurs which would affect billing.
This wasn't us being 'dark' more 'lazy', but thanks for highlighting!
I've now added to our short term roadmap changes that will resolve these problems.
1. Emailing account holders a couple of days before billing to give them an opportunity to cancel.
2. Emailing account holders whenever a change to their account occurs which would affect billing.
This wasn't us being 'dark' more 'lazy', but thanks for highlighting!
:clap: :clap:
Lovely. Most of the time it is software complexity that goes into the way or prioritization of features.
Hope your sales team do not start hating you for some of these changes ;-)
Lovely. Most of the time it is software complexity that goes into the way or prioritization of features.
Hope your sales team do not start hating you for some of these changes ;-)
I really like Digital Ocean and Linode in this respect, I can spin up a server, play all night, destroy it and it cost me cents. It's easy to see what't still running and monthly emails (payed per minute) remind you if you still have things running. I never had any surprises. But then again, I am the VM kind of guy, not the hyperscaler type.
Subscription service is a blessing for both businesses and consumers. However it is shocking to see the exploitations. This is what telecom companies did before congress legislated to protect customers from unscrupulous charges. Hope this doesn’t happen with SaaS as the industry is new and there is a long road ahead for developers and entrepreneurs.
Is anything being done about this kind of thing? It's one of those steal-a-dollar from 1M people tricks. If you stole 1M from one person they'd do something about it. Pick 1M pockets and nobody can do anything.
there are a few ideas, to let technology help.
Others are around legislation, such as the one that came yesterday from FTC on call to cancel being illegal.
Others are around legislation, such as the one that came yesterday from FTC on call to cancel being illegal.
I absolutely think a CC upfront opens many doors to potential abuse and hidden recurring charges , obscure opt out etc.
Could use alternative methods to prevent spam, like sms etc.
Requiring a credit card is asking for too much trust from the user.
Could use alternative methods to prevent spam, like sms etc.
Requiring a credit card is asking for too much trust from the user.
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?
"Our research shows that companies underutilize their SaaS products by an average of 30% across the board"
Big yikes.
I'm curious which of these approaches would have the biggest impact on bringing that SaaS waste down.
Big yikes.
I'm curious which of these approaches would have the biggest impact on bringing that SaaS waste down.
Though not easy to implement, but consumption driven billing rather than seat/user-driven would reduce the grief quite a bit.
In the early days AWS EC2 became popular for their per compute per hour pricing compared to hosting providers fixed monthly cost.
In the early days AWS EC2 became popular for their per compute per hour pricing compared to hosting providers fixed monthly cost.
> Free trials should not require a credit card.
I'm not in business to provide services to people who want stuff for free permanently. They complain on forums, raise stink and spend nearly no money. They are not my customers. I always ask for a credit card for a free trial. The fewer non-customers signup, the better it is for me.
I'm not in business to provide services to people who want stuff for free permanently. They complain on forums, raise stink and spend nearly no money. They are not my customers. I always ask for a credit card for a free trial. The fewer non-customers signup, the better it is for me.
While I kind of understand your point of view and not all businesses are equal, a free trial is not stuff for free permanently. You should be confident that your product will be able to make the customer willingly add their credit card after their trial is over if you are indeed providing them with a useful service.
I agree, and was going to posit the same argument, however, a credit card is a useful way to get unique info. If someone signs up to free trail without something like a CC, instead using an email address, then they just have to register a new email address to get further free service. Although I am sure there are alternatives that I havent considered.
What's your thought on alternatives, like Ahrefs' $7 for 7 days trial?
Unrestricted service at the highest plan level, 1 to 2 weeks, credit card not only required but is authorized for the plan price - do not settle transaction as it is still a free trial. This ensures:
1. Whoever tries the service at least theoretically met minimum qualification to be a customer - they have a credit card and can authorize several hundred dollars on it.
2. We get the real lead.
3. We limit the number of people who recycle free trials -- this happens a lot.
1. Whoever tries the service at least theoretically met minimum qualification to be a customer - they have a credit card and can authorize several hundred dollars on it.
2. We get the real lead.
3. We limit the number of people who recycle free trials -- this happens a lot.
Interesting take.
Hotels do it, authorize you for N nights during check-in capture/sale during check-out.
Hotels do it, authorize you for N nights during check-in capture/sale during check-out.
This person does B2B SaaS! Great comment and 100% agree.
Do you ever offer to extend free trial for people who want to cancel, and do you convert them back?
Do you ever offer to extend free trial for people who want to cancel, and do you convert them back?
> Do you ever offer to extend free trial for people who want to cancel, and do you convert them back?
Yes - but that's the sales reps job. If they think we have a decent chance of converting "no" into a sale after they reach out to the customer to find out what, if anything, made the customer decide not to become a paying customer, they can extend the trial.
In my experience the vast majority of the convertable free trial expiration without conversion is lack of time on customer's side -- the customer did not really use the product. So now our sales people actively approach those customers.
Yes - but that's the sales reps job. If they think we have a decent chance of converting "no" into a sale after they reach out to the customer to find out what, if anything, made the customer decide not to become a paying customer, they can extend the trial.
In my experience the vast majority of the convertable free trial expiration without conversion is lack of time on customer's side -- the customer did not really use the product. So now our sales people actively approach those customers.
I read the article and after a few para's I know that the author now works for a SaaS expense management company and I am reading marketing material.
While some marketing is more crass than others, there is no doubt that advising people of dark patterns is valuable, and probably worth money to mitigate. Every security advisory in the last decade has been marketing material for a security company or researcher. Everything should be read critically, and this article reminded me to drop a subscription.
You can have an opinion without being dishonest about your interest behind it or its controversy, no?
You can have an opinion without being dishonest about your interest behind it or its controversy, no?
AWS costs are somehow always higher than your estimate. Even when using their little calculator. That's the dark pattern right there.
Emmm, no? You can download detailed billing and drill down if you want.
If you see differences, one reason is that with hourly billing your monthly bills will be different, depending whether it’s a 28, 30 or 31 day month.
If you see differences, one reason is that with hourly billing your monthly bills will be different, depending whether it’s a 28, 30 or 31 day month.
For people just starting, I can see it being true. A pedestrian example might be a Lambda. You look at the pricing on their site and calculate it down to the penny, but the cost ends up higher. Because the Lambda pricing page doesn't mention the Cloudwatch logs that were created with your Lambda, but they aren't free. (Leaving free tier stuff out of the picture).
I've been with AWS for a number of years (personal and for work) and haven't seen this problem either.
Some services will be higher if you don't account for all the costs. You can do the math for an EC2 instance but if you don't account for storage prices and bandwidth prices then the bill will be higher than you expect.
But some service prices will be lower than you expect. If you create multiple EBS snapshots from the same server, you'll notice that the price you pay isn't the sum of the individual snapshot sizes. It's far less because each new snapshot only saves data from blocks that have changed since the last snapshot.
Some services will be higher if you don't account for all the costs. You can do the math for an EC2 instance but if you don't account for storage prices and bandwidth prices then the bill will be higher than you expect.
But some service prices will be lower than you expect. If you create multiple EBS snapshots from the same server, you'll notice that the price you pay isn't the sum of the individual snapshot sizes. It's far less because each new snapshot only saves data from blocks that have changed since the last snapshot.
Without reading too much into the fact, it's still pretty funny that this is marketing for a SaaS product
Subscription-based software is already a dark pattern.
Our software is subscription-based, and our customers love it. They get a predictable cost over time, rather than large costs every now and then. We can afford to include features that otherwise might not be justifiable in terms of new sales.
On the flip side, one of our competitors who hasn't switched has been struggling for years and a recent new version almost killed them off as many customers didn't feel they could justify the $10-20k or so to buy the license to the new version.
A key part of our success is that the subscription price scales linearly with customer activity. There's a fixed base price per active user, and in addition there's a cost associated with certain actions. This means that the subscription price scales with the customers activity and hence income. If they have a slow month they have less income but pay less, if they have an active month they have higher income but they also pay more.
FWIW our software is primarily installed on premise, but we do offer hosted service as well (base cost is different for the two cases).
On the flip side, one of our competitors who hasn't switched has been struggling for years and a recent new version almost killed them off as many customers didn't feel they could justify the $10-20k or so to buy the license to the new version.
A key part of our success is that the subscription price scales linearly with customer activity. There's a fixed base price per active user, and in addition there's a cost associated with certain actions. This means that the subscription price scales with the customers activity and hence income. If they have a slow month they have less income but pay less, if they have an active month they have higher income but they also pay more.
FWIW our software is primarily installed on premise, but we do offer hosted service as well (base cost is different for the two cases).
>"They get a predictable cost over time, rather than large costs every now and then."
For the software I buy one time price is often about the same as the annual subscription. With perpetual license however I often do not upgrade for years. So the perpetual licensing is a clear winner for me. I understand that SAAS can make sense for other customers but it is their choice not mine. I just simply do not buy software without perpetual license. It ruffles my feathers in a bad way.
Of course I am not talking about services where monthly payment is a natural state like Netflix.
For the software I buy one time price is often about the same as the annual subscription. With perpetual license however I often do not upgrade for years. So the perpetual licensing is a clear winner for me. I understand that SAAS can make sense for other customers but it is their choice not mine. I just simply do not buy software without perpetual license. It ruffles my feathers in a bad way.
Of course I am not talking about services where monthly payment is a natural state like Netflix.
> For the software I buy one time price is often about the same as the annual subscription.
That of course changes the balance. In our case the annual sum of the subscription is much less than that. More like 2-3 years before intersection, though I forget as we've had this system for over a decade now.
It should be noted that we're also in a segment where customers will need a new version now and then as rules and regulations change.
That of course changes the balance. In our case the annual sum of the subscription is much less than that. More like 2-3 years before intersection, though I forget as we've had this system for over a decade now.
It should be noted that we're also in a segment where customers will need a new version now and then as rules and regulations change.
No, I don't think so. If the seller actually incurs monthly costs like hosting, this is absolutely fair. What I would call a dark pattern is when you buy an app, a piece of software that executes code on your device, and are forced to pay monthly fees. This gets more and more common. I understand the reasons, but I personally prefer one-off payments and buy software in this way. If it's good, I will pay for upgrades anyway.
Another dark pattern is switching off your customer's apps remotely as Adobe did to their customers in Venezuela two years ago.
Another dark pattern is switching off your customer's apps remotely as Adobe did to their customers in Venezuela two years ago.
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.
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.
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).
Seems orthogonal. You can have subscription-based desktop/self-hosted, and one-time-payment hosted software.
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".
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".
>"First, supporting desktop/mobile software can be hard"
I have Windows desktop software (my product with about 40,000 customers) that I support and I would not call it any harder than maintaining for example backend C++ servers I make for my clients.
>"What happens when Apple removes an API that your program used?"
No idea about Apple as I do not develop for their platforms but my yet another desktop software (uses DierctX 9 and DirectShow) that did release in 2003 and abandoned sometime in 2008 as the revenue had decreased still works like a charm.
>"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"
That DirectX program I just mentioned was developed in Delphi 7 (I use Delphi and / or Lazarus to develop desktop applications). This Delphi 7 still runs and compiles this software on my Windows 10 machine. Latest Delphi which I have compiles it as well with no problem (just checked).
So yes in theory you are right, in practice (as much as it concerns my products) it is however totally irrelevant.
I have Windows desktop software (my product with about 40,000 customers) that I support and I would not call it any harder than maintaining for example backend C++ servers I make for my clients.
>"What happens when Apple removes an API that your program used?"
No idea about Apple as I do not develop for their platforms but my yet another desktop software (uses DierctX 9 and DirectShow) that did release in 2003 and abandoned sometime in 2008 as the revenue had decreased still works like a charm.
>"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"
That DirectX program I just mentioned was developed in Delphi 7 (I use Delphi and / or Lazarus to develop desktop applications). This Delphi 7 still runs and compiles this software on my Windows 10 machine. Latest Delphi which I have compiles it as well with no problem (just checked).
So yes in theory you are right, in practice (as much as it concerns my products) it is however totally irrelevant.
as a new entrepreneur trying to understand saas expenditures this was an insightful read into the industry
The payment gateway HyperWallet doesn't even let me send email to them without an account. I want to ask the transaction fee before joining but you need an account. I don't understand what service level it is.
It's under Paypal so I don't feel surprised at all. Just another enterprisey payment company
It's under Paypal so I don't feel surprised at all. Just another enterprisey payment company
"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 all kinds. Having an opt-in to use/abuse your platform for 2 weeks is not always viable. Card up front is not a perfect filter, but it's helpful in turning this noise way down and letting you focus on helping actual prospective customers become successful with your product.