3 ms·
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
by vishnumohandas 5y ago
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.
- unclebucknasty 5y ago>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.
- istingray 5y agoCurious 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.
- thinkloop 5y agoMy 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.
- istingray 5y agoI 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?
- vishnumohandas 5y agoI 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.
- istingray 5y agoAppreciate 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.
- nicoburns 5y agoI 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.
- vishnumohandas 5y agoPre-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.
- bjyule 5y agoWhen you say incompatible, are you talking about the cache not working or something else? How are you working around this using workers?
- vishnumohandas 5y agoB2 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.