Hacker News new | past | comments | ask | show | jobs | submit login

Drawing a direct parallel with Google will make this difficult, since they own their storage and network infrastructure and have ways to monetize your data. But here's an explanation on why there are large gaps between plans:

- Our 1TB plan costs only 3x the 100GB plan. This model works under the assumption that the average utilization of a 1TB plan (across all customers) will be ~30%.

- If we were to bring in an intermediary plan (say 500GB), we would have to increase the pricing of the 1TB plan (since at least 50% will now be utilized), and also set the price of the 500GB plan to at least 2x of the 100GB plan. Both plans now appear unattractive.

- Since Apple and Google don't support per GB billing yet (which IMO would have been the fairest way to go), we had to pick buckets, and the current ones seemed like the fairest possible.

I hope this makes sense.




>If we were to bring in an intermediary plan (say 500GB), we would have to increase the pricing of the 1TB plan (since at least 50% will now be utilized), and also set the price of the 500GB plan to at least 2x of the 100GB plan

What happens if you start by pricing all tiers "honestly" (i.e. reasonably profitable even at 100% utilization)? Have you determined that the market won't bear that pricing? If so, is there any way to meet in the middle?

In general, you may be erring a little too much on the side of asking some customers to grossly overpay for their actual utilization and, in practical terms, 100GB to 1TB is just an extremely wide gap, as evidenced by your parent's comment.

So, it seems that most who tip over into the 100GB - 1TB plan will be there, overpaying, for a long time. And, obviously, most people who make it to 1TB will pass through that range. So, if you do see a higher concentration of users in that range than at 1TB (as intuituon would suggest), then you're essentially "punishing" a plurality of your customers by asking them to subsidize a smaller group's pricing.

Failing other options, it may be better to do the inverse: raise the pricing of 1TB to accomodate a "friendlier" 500GB plan.


I definitely empathise with the difficult in competing with the big cloud providers on price. Your service is inevitably going to end up more expensive. Having said that, I'd be interested to know how you're hosting the content.

When I was looking at setting up a similar service, it seemed like you Backblaze B2+Cloudflare might well be the best combination. B2 will sell you storage at $5/TB, and you can get free bandwidth out to Cloudflare's network. It's against Cloudflare's terms to use free plan for image hosting that isn't just images as part of webpages. However, one of their staff members commented on a thread that they'd likely to be willing to set up a custom plan for a business who wanted to do this. And I'd bet that Cloudflare's bandwidth would be a lot cheaper than B2's.


Pre-signed URLs generated with B2's S3 APIs are incompatible with Cloudflare at the moment. We are working around this by using a Cloudflare Worker to proxy data from B2 to the client. This is currently free if you're on the Bundled plan and Cloudflare's support has promised that when they decide to start charging, they will alert us in advance.

Interestingly, Workers Unbound charges 0.045/GB which is more than B2's 0.01/GB.

A viable long term alternative could be Wasabi that offers free egress in return for a $6/TB plan. But we're waiting to see how things pan out before executing an expensive migration.


When you say incompatible, are you talking about the cache not working or something else? How are you working around this using workers?


B2 documentation suggests that after adding a CNAME (eg. cdn.ente.io) for their bucket endpoint (eg. bucket.s3.eu-central-003.backblazeb2.com), you will be able to replace the latter with the former. This breaks with the native B2 APIs with the following error:

```

{

  "code": "not_found",

  "message": "/api/top_level_url_mapping",

  "status": 404
}

```

The last I checked was a few months ago, not sure if things have been fixed now.

With Workers, we simply fetch the remote resource from B2 and return it back to the client, acting as a thin proxy.


Curious about alternatives. GB to GB, other services will always be cheaper. How do you help frame pricing What about charging per picture? Likely a non-starter, but you get where I'm going with this. iPod = 1,000 songs in your pocket.

If not you, someone will figure this out. Charging by the GB seems hard. What if instead your levels were: 1,000 photos 10,000 photos 100,000 photos

You might get people who store super high res files, but work that into the pricing.


I had thought about this a year ago when I was pitching the product to my parents who had no idea what a GB was. But I was put off by the possibility of abuse once I extended the framework to videos.


Appreciate your reply! It gets to the core of your value proposition though. Surely you could add in some limitations if needed. If it worked, maybe the biz would grow so fast you don't care about a little abuse.

Do you have any marketers to help you? Will be hard to navigate the messaging alone.


My phone photos are 2.2 MB each. 1,000 GB's is 1M MB's which equates to approximately 450,000 photos. At $18.99/TB/year, 1,000 photos would cost ~$0.42 a year.

Photos can easily be 30 MB each or more, especially from dedicated cameras. If all photos were 30 MB it would cost $5.69 per year for 1,000 photos.

Not making any point, just calculated it for myself and thought to share.


I like this line of thinking.

You know it really gets me thinking about packages rather than GB for this service. Maybe there's a "family plan" opportunity here. Do families value anti-surveillance in general, or is it simply lone actors?

Just the idea of archetypes flashed through my mind. An opportunity to sell to difference audiences. What kind of algos do individuals need, pro photographers, families?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: