Ask HN: Single vs recurring payments for web apps | Hacker News Reader

Ask HN: Single vs recurring payments for web apps

17 pointsmatt111 comments

I'm working on a new web app right now and am trying to figure out what the best way is to charge for it.

For my previous web apps, I charged the user once when they signed up. There were no recurring payments. I reasoned that for the type of web apps I build -- tools -- that most people would prefer one larger payment vs a recurring small one.

I've been discussing it with a few other folks and they're encouraging me to try a monthly payment, pointing to the success that 37signals has had with it. Less people might sign up, but over time the extra revenue you make from them will make up for it.

I tend to to think of apps like Photoshop, Textmate, and Transmit and think "A recurring payment? No way." And yet somehow when I think of 37Signals, it doesn't seem so bad, but I can't put into words why one makes sense and not the other.

How do you decide? Has anyone tried both and compared the numbers?

View on HN

When you issue a single charge for a webapp, what kind of legal language have you provided in the EULA that states something to the effect of "I can take the webapp down whenever I want and you will no longer be able to access the service you paid for"?

It's for that reason that paying for a webapp one time feels odd to me. It's like purchasing a product, except the product can be taken away from me at any time, which is unsettling.

I agree...it reminds me of the deal Sirius used to have where instead of paying $12 a month for satellite radio, you could pay $499 one time per device. I think Tivo had a similar deal. The problem was, when these services were new, who knew if they would be around in 5 years, or whether a new service would take their place. In the case of Sirius, HD radio now offers similar service for free, and I prefer to download my TV shows rather than record them. So I was wise not to pay upfront.

There's something about human nature where we definitely prefer to make recurring payments.

Think about 40 bucks a month for an alarm system, or 60 bucks for the gym. That's roughly 5-7k over a ten year time span, and even if you adjust for time value of money and the user having the cancellation option, at the end of the day it's ridiculously easier to get people to make a monthly payment for those sorts of services than it would be to get a one-time upfront multi-thousand dollar payment.

I think you've pointed out a good rule of thumb: if the intrinsic value of the product is more than what most people would be willing to pay in a one-time payment, you should charge monthly for it.

Clearly there are other factors that go into it, but that's one way to look at it.

There's something about human nature where we definitely prefer to make recurring payments.

I think I'd rather pay a one time fee for software. My fear (and I doubt this is only me) is that I'll forget about it and wind up paying for it long after I've used it. Great for the services I pay for, but bad for me.

Is there any software you pay a recurring monthly fee for? If so, what is it? And if not, why do you think that is?

Consider a hypothetical example: You can pay $50 once for Textmate, or $8/mo. Which would you prefer? How about $4/mo?

I may not be the best example, because I am ridiculously frugal. There are very few things I pay for beyond food, rent and travel, which is another way of saying I pretty much exclusively use free tools. Incidentally, when my 30 day trial of Textmate ended, for some reason the software kept working and rather than pay for it, or stealing it by continuing to use it, I just switched to another editor.

That said, if I really wanted to spend money on Textmate, yes, I would prefer to pay 50 bucks rather than either $4 or $8 monthly. At a $1 or $2 a month, I would probably be indifferent. To some element there's an issue of how long the purchaser will actually use the tool vs. how long they estimate they'll use it.

I agree with you 100% that we develop countermeasures because we know that these recurring monthly plans are dangerous. My sense is that we develop the countermeasures exactly because the monthly plans are so effective at separating us from our money, and that the countermeasures only partly offset the tendency. Of course, for you may have an outright aversion to the monthly plans, just as I have excessive frugality, but overall my sense is that for most people monthly plans go over better than upfront charges in most situations.

Simple: 37Signals has server costs on an ongoing basis to maintain a customer - Textmate/Transmit/PS do not. Most consumers understand it's a hosted solution and are ok with paying a recurring payment.

If your solution isn't hosted and it's a onetime download kind of thing then it would only make sense to charge them the one time.

Not sure how easy it is to do.

But surely, as the "webapp" you can also revoke a users subscription.

I have been thinking about "recurring payment" with an agreed, "we the webapp" will cancel your paid access if you have been absent of the site "x days" or more likely 2 months.

I prefer to pay recurring payments because it's incentive for the developers to continue working on the project.

You could look into using quarterly or half yearly payments potentially, similar to how Pandora does it, charging for the whole in one fell swoop.

You raise an interesting point by pointing out that you like the incentive for the developers because that's not something most people would consider (I think). Our opinions may differ a lot from ordinary people.

Yeah, most people balk at the idea of paying monthly for something, even at something like $10-$20 a month. My background is heavily mixed with Internet Marketing kinds of guys, who are notoriously stingy with this stuff. But it's easy to counter: if you have a $30 per month app, and someone complains, just ask them "will this tool help you make $1 per day? if yes, then it's worth it"

Good luck with it

EDIT: misused day instead of month

Reply on news.ycombinator.com