Tarsnap and the prepaid billing model | Hacker News Reader

Tarsnap and the prepaid billing model

daemonology.net

47 pointscperciva41 comments

This is partly the micropayment problem. The other way around it is to extend credit, and bill people. I can see this is against your profitability rule. Just saying it's another solution, in general.

You didn't ask for feedback, so feel free to ignore the following :-)

It would be nice to have a demo service, to play with before paying the $5. You could limit it to a trivial amount of storage (like 100 bytes) - the purpose is not to store stuff, but to have a play. An easier on-ramp helps adoption, gives people a chance to kick the tyres.

If your account stays below zero, your backups will be deleted. This is a bit scary for a backup service. I'm sure you haven't actually deleted anything, but it would be reassuring if you gave a schedule, e.g. emails every day for a month (perhaps mimic the warnings of a domain name registrar). The main thing is to reassure people, by communicating what you will do before deleting their stuff.

One warning about "a service that you would use". A multinational corporation has different values from an individual, and they will happily pay more than you can imagine, if you can solve their problems. I guess this doesn't apply to you, because bigger customers would setup their own backup, instead of using your service (as you say). I'm just saying that your own sense of value doesn't always translate to different needs - unless you can imagine yourself as a multinational corp, I guess. :-)

It would be nice to have a demo service

That might happen in the future -- the current architecture of the tarsnap server makes this difficult (I don't have "total storage used by user X" updated in realtime).

If your account stays below zero, your backups will be deleted

Right now what I do is send out an email when an account balance falls below 7 days worth of storage, another email when an account falls below zero, and then I wait a week after that before deleting anything. These timelines might change in the future, which is why I haven't specified anything precise on the website.

...multinational corporation...

You're quite right -- but I didn't start this because I wanted to make life easy for multinational corporations. I started this because I wanted a good backup system, and it seemed to me that while multinational corporations had lots of good options available, there weren't really any good options for people like me.

Thanks for your answers. You email timeline seems reasonable to me, but what I meant was that you need to communicate this on your website. Otherwise, the user thinks that if they forget to pay, their backups are suddenly and instantly lost.

> But I'm building tarsnap first and foremost to be the backup service I would want to use -- and who wants to pay more than necessary? I certainly wouldn't.

Always good to see someone scratch thier own itch then sell the solution as they would want it.

Thanks! To be honest, getting rich has never been on my list of reasons for building tarsnap -- I really just wanted good backups. But my idea of good backups is a backup service, and in order for a backup service to be sustainable it needs to make money, and in any case I couldn't afford to spend two years writing code for tarsnap without a good chance of earning some money from it later...

A reliable revenue model only increases confidence in a service such as backups. It is always good to know your backups won't disappear because the service has gone bust.

Absolutely -- and there have been more than enough examples of backup services going out of business lately to make people worry about this. This is the main reason I wrote my previous blog post: http://www.daemonology.net/blog/2009-03-09-tarsnap-reaches-p...

I find pricing tiers distasteful in general -- A man after my own heart!

How do you manage the float of your users' prepaid balances?

At the moment, I'm not really managing it. It's just sitting in paypal.

Unfortunately being a Canadian makes it hard to get USD out of paypal without having paypal convert it to CAD at a really horrible exchange rate -- I'm going to get a US bank account soon (a USD bank account at a Canadian bank isn't good enough) to get around this problem, but I haven't made it that far yet. Given how horrible interest rates are right now it's not as if there's a huge amount of money to be earned on the float anyway -- the main reason I want to get the money into a USD bank account is so that I can pay AWS costs in USD instead of having those converted to CAD (at a really horrible exchange rate) so that they can be billed to my CAD credit card.

While you're a startup it doesn't matter much, but if you become a larger company, having the user's money that they haven't "spent" yet can be quite irritating for accountants, depending on which accounting method is being used.

In essence you have may have to refund "unconsumed" funds and this affects how you do your books.

Well, users' balances can be refunded whenever they want -- I'm not going to hold onto someone's money if they want it back.

As for the accounting side of things: My understanding is (at least as far as Canadian accounting goes, which is what matters to me) that it's handled as a liability called "unearned revenue". So while it's certainly something to be aware of for accounting purposes, it's not a big problem.

From the user perspective, I find this a very attractive policy. I considered it for my own business model.

Do you refund 100% of the initial fee or do you deduce some processing charges ?

I'm thinking of this 7 day full refund law abused in the domain name business. People would get a name, test its "responsiveness" in hits, and ask for a refund of names below a threshold.

What protection do you have against such type of abuse of your refunding policy ? Are the refunding cost "payed" by other clients ?

Do you refund 100% of the initial fee or do you deduce some processing charges ?

At the moment I refund 100% of any unspent amount. In light of payment processing costs, I might change this to deduct a small processing fee (say, $0.30 + 3%) in the future; but so far the number of people asking for refunds has been sufficiently small that it isn't really necessary.

I think domain tasting and tarsnap tasting are quite different concepts; I don't see any reason to open 10,000 tarsnap accounts and then ask for refunds. I'm also reminded of Joel's article about how, because he had a no-questions-asked full refund policy, he never had to actually give refunds. When a customer is asking for a refund seems like the worst time to nickel-and-dime them with fees.

> Second, I find pricing tiers distasteful in general.

I don't have the time to dig up a great explanation of them, but they're not inherently bad. If you can get more money from some people by giving them a bit more, that means more investment in your service and code, which is good for everyone, no?

I'm not sure if you understand what I mean by pricing tiers. I have no objection to people paying more in order to get more -- by pricing tiers I mean things like "plan A costs $5/month and lets you store up to 20GB; plan B costs $10/month and lets you store up to 40GB" because with a pricing model like that the 20,000,000,001st byte ends up costing $10/month, which is plainly absurd.

Oh, I was thinking more along the lines of price discrimination:

http://en.wikipedia.org/wiki/Price_discrimination

Yeah, your example definitely wouldn't be good business.

I also find price discrimination inherently distasteful -- but even if I didn't, I'm not sure how it would be possible for tarsnap without adding a lot of extra complication.

I'll take your word for it that price discrimination would be difficult for tarsnap, but I don't think there's anything particularly distasteful about it as long as you're not sneaky about it (i.e. Amazon showing different prices to different people, who then figure it out and get irritated).

I agree that price discrimination isn't necessarily dishonest -- I just find it distasteful because it seems unfair. :-)

I keep hauling out the 'Information Rules' book because it's so good... I just picked it up and looked, and they do cover price discrimination some. There are plenty of examples where it's not really unfair, mostly where people self-select.

For instance, coupons are a way of getting people to buy something they may not have otherwise bought, with the thinking that those who have time to sit around clipping them out are a group of people with less money than those who simply don't care and go to the store and buy stuff without looking at the price much.

Student and senior discounts are another one that doesn't strike most people as 'unfair'.

prepay is a good tactic for small customers -- getting the entire lifetime value up front in most cases.

but why are you bothering with customers spending <$1/mo? (we avoided pay-as-you-go for this reason)

I'm not sure exactly what you mean by "why are you bothering", so I'll answer both versions of the question I can imagine you meaning.

If you mean "why bother charging them instead of making it free" -- as I explain in the post, I don't want to get into a situation where I might have enough small non-paying users that I end up losing money.

If you mean "why accept them as customers at all" -- well, thinking as a user of my own service, I'd be really irked if I got told that I couldn't use a great service simply because I didn't want to use it enough! But from a purely business perspective: In my experience, small-scale users are some of the most important ones to have, since they tend to be the ones who go around telling everybody they know about tarsnap.

And they might turn into larger scale customers later.

This is the very important part. I probably had my S3 account for a year until one day I dumped hundreds of gigabytes into it. I used S3 because I already had it setup and it was convenient.

Is there anywhere I can read more about Tarsnap's features/architecture? You're obviously a bright guy, and you say you've been working on it for over 2 years, so I'm just curious about what exactly you built ...

For example, what advantages does tarsnap have over some bash scripts I write in a few hours that give me off-site encrypted backups with the help of GPG and rsync? (That's pretty close to the system I use now). I'm sure there are some, but I just don't see them enumerated tarsnap.com ...

The tarsnap website links to several of my blog posts about tarsnap, but this one probably has the most information of interest to you: http://www.daemonology.net/blog/2008-11-10-tarsnap-public-be...

For example, what advantages does tarsnap have over some bash scripts I write in a few hours that give me off-site encrypted backups with the help of GPG and rsync?

It's hard to say without knowing exactly how your scripts work, but I'd guess that one big advantage tarsnap has is that it works with a snapshotted model of backups.

Thanks, that answers my questions. Your snapshot system reminds of a reference counting GC - neat trick.

As it happens, tarsnap's snapshots work via reference counting -- fortunately, it works better for tarsnap than it does for garbage collection. (Reference counting breaks if you have circular references; this is a problem for garbage collection, but not for tarsnap.)

Why didn't you go for a 'real' GC?

I have no clue what your question is trying to ask. Can you clarify?

Why did you choose to do reference counting instead of more sophisticated techniques?

I can imagine that ref. counting is much easier to implement and the drawbacks are unimportant in your domain. However I'd still like to read about the reasons for your decision, since you will have thought about that issue much longer and clearer.

But I guess I should take a deeper look at http://www.daemonology.net/blog/2008-11-10-tarsnap-public-be... before writing anything..

Oh, now I understand. Methods such as reachability analysis require reading lots of memory locations; but for tarsnap, "memory locations" are blocks of data stored remotely, so this gets expensive (and slow) very quickly. With reference counting, the counts can be stored locally and no extraneous data needs to bs transferred to or from the server.

I guess there's a precedent there in the fact that unix file systems use reference counting for file links, presumably for the same reasons. Considering how well-architected tarsnap seems to be, I suspect you've taken steps to avoid losing data via inconsistencies in the reference counter?

... you've taken steps to avoid losing data via inconsistencies in the reference counter?

There are some sanity checks built in, but in the extreme case what you're suggesting is impossible. Reference counts are managed on the client side, and the client has the keys necessary to delete blocks from the server; if the client is functioning correctly, it won't get the reference counts wrong, but if the client is malfunctioning then it could go berserk and delete blocks without even looking at the reference counts.

I have taken care of the obvious issues, though -- as long as the OS implements fsync() properly, there's no way that tarsnap or the client system crashing will result in corruption.

I actually quite like pay in advance. If you're not really using a service like you thought you can extend the use over a long period making it worthwhile. Of course the same applies to pay for what you use, after the fact, but then there is some ongoing mental load with remembering to either keep or cancel your account.

If you're going to stick with this model you should definitely add an auto-recharge feature. This is how I use my Skype account. I auto-recharge $10 every time my balance falls below $2. Very convenient. I don't have to have $100 sitting in there for no reason, but I'm never out of credit.

If you're going to stick with this model you should definitely add an auto-recharge feature.

I might do that at some point, but right now that would kill one of the key benefits of the prepaid billing model -- right now, I don't need to store credit card numbers.

I'm guessing that this wouldn't be competitive in the market at a higher price point? From a personal viewpoint if I was going to pay for a backup service i'd be open to paying more.

I guess free alternatives would make that hard to be a competitive business move though?

There are certainly backup services which are more expensive than tarsnap -- Mozy, for example, charges $0.50/GB, and rsync.net charges $2.10/GB for their georedundant storage (which is probably still far less reliable than the backing storage for tarsnap). But I don't particularly want to find out exactly how much I can gouge my customers; I'd prefer to have a comfortable profit margin and hope that reasonable prices result in more people using tarsnap.

Too bad this is not available in Canada. I would love to pay for this service.

Reply on news.ycombinator.com