4 ms·

I thought this would be about pricing. In pricing, there’s a real advantage to being small: prices are often artificially low at low volume to promote lock in.

I thought this would be about pricing. In pricing, there’s a real advantage to being small: prices are often artificially low at low volume to promote lock in. Then they gouge you in the middle. Then at the high end, they have to stop gouging you because you know that they know that you know you could go elsewhere for your volume. For example, AWS free tier is a great bargain. AWS is a terrible value once you’re paying the price of a bare metal box each year (or sooner!), but then at Netflix scale it balances out again because Amazon knows that Netflix could easily talk Microsoft into doing the port themselves if it would actually make financial sense. Most pricing is S-shaped, so it typically is best to be in the position of exploiting a loss leader or running at scale.

minot 6y ago
I still don’t understand how this business model works at all. Take cloudinary, for example. You can have your images transformed and hosted by cloudinary. So like you have a photo and let cloudinary examine the photo and serve different sizes, cropping to a human face as a circle for profile pictures for example. It is expensive. All you need is some idiot hitting refresh in a few tabs on the browser for a few hours on your website for you to run over your free tier. I’d imagine that anyone spending real money is always thinking of ways to get off of something like this?
- shash7 6y ago
  It doesn't work like that. Cloudinary caches the transform so you only pay for the first time for the transform. Of course, you do have to pay for the bandwidth but by then the image would be cached somewhere on the network or on the browser anyways.
- josephg 6y ago
  I did some contracting work a few years ago, and one of our clients was a small entertainment news site. They used cloudinary for image hosting and were paying some insane amount for image hosting. I think their cloudinary bill was $8000/month or something. The client didn't even know that was expensive. They just saw it as a cost of doing business, alongside their cloudflare bill and so on. (And what they were paying us.) It took work over several weeks to convince them that that was a ripoff. I think their business people eventually called up cloudinary and negotiated a better rate, but by that point I was annoyed by the whole situation. The site used cloudinary's HTTP based API from the browser. I configured cloudflare to redirect any request hitting example.com/images/... to act as a caching proxy to cloudinary's actual servers. Unsurprisingly, that one configuration change made their cloudinary bill drop to about 1/20th what it was. When the client was billed we got a panicked phone call asking why it was so low, and if something was broken on their site. Anyway, tldr; lots of folks out there have no idea what a service like cloudinary should cost. Apparently more than enough to make cloudinary a profitable business.
  - coding123 6y ago
    Awesome story.
  - ProZsolt 6y ago
    I think it's also a problem that engineers are rarely incentivized to make the right decision initially. If the initial price is low they will be prized if they able to cut down the development time. After that if the solution auto scales then it will be the beancounter's problem.
    - qazxcvbnmlp 6y ago
      I deliberately make things expensive during development so there’s room to ‘optimize’ later.
  - earthboundkid 6y ago
    I actually looked at Cloudinary for my job. I thought the pricing didn’t make sense so I ended up just running imgproxy on Heroku (it was free tier for a long time but I upped to hobbyist to get better latency).
- lmm 6y ago
  People don't pay you to run xyz, they pay you to solve their problems. If you can solve a problem that real businesses have, then as long as you're not charging enough to be a bigger problem than the original problem, they'll be happy to pay it.
- petercooper 6y ago
  We pay like $200/mo for Cloudinary and we barely use any of the features. Primarily it's to serve up an image scaled to the right (single) size and occasionally I'll tweak the URL to add an effect, a tint, or something. This convenience is worth the money so far considering $200/mo is a rounding error in our monthly expenses but I could probably write a script to achieve similar ends in a few hours and upload to S3 instead..
  - pc86 6y ago
    Even if it's a rounding error, it sounds like you'd break even from having one of your developers do it within a month or two. Unless everyone truly has a months-long backlog of high-impact stuff to do it sounds like a good argument to do it some Friday afternoon.
bsder 6y ago
> AWS is a terrible value once you’re paying the price of a bare metal box each year (or sooner!) You're probably off by about 2 orders of magnitude. If your AWS spend is $10K per year or below, it simply isn't worth thinking about in terms of engineering time if you have real revenue. Once your AWS spend crosses about $100K/year, it's time to pay attention. However, you probably want to be stingy about this as your engineer is in that range. Your engineers are supposed to be providing business value and looking at $10K/year costs probably isn't worth their time. At the $1M/year mark, you already have an engineer on this full-time anyway so it makes sense to have some hardware you actually own in a colocation facility somewhere.
- josephg 6y ago
  I agree - but there's a few gotchas here. One is that there's often simple configuration changes where a few hours of engineering effort could save $30k+ each year, and those changes can still be worth looking into. I set up AWS a few years ago at a startup I worked at. I didn't really understand the difference between spot instances and reserved instances on EC2, and I didn't bother to learn (we were all very busy!). We didn't notice for 18 months or something, and the amount of money we wasted with that single mistake would have paid my salary for several months. Its also easy to accidentally lock yourself in to bad infrastructure decisions early, that become extremely expensive to fix later. Mongodb might seem like a good place to start your project, but trust me - moving away from it down the road will be a nightmare. Too much up front design will kill your velocity. And not enough up front design will cost you too. If there's a good rule of thumb here, I haven't found it yet.
  - ramraj07 6y ago
    Thanks for the honesty, most new engineers make such mistakes, AWS and other massive Cloud offerings are like a forest where one can easily get lost!
  - bsder 6y ago
    > he amount of money we wasted with that single mistake would have paid my salary for several months. Sure. Presumably, though, your engineering salary for a couple months had more business value than you would have saved, so it's still a net plus. > Too much up front design will kill your velocity. And not enough up front design will cost you too. If there's a good rule of thumb here, I haven't found it yet. In my opinion, err on the side of velocity. Most startups are worrying about staying alive. If the startup survives to have the problem of ripping out bad decisions, consider that your engineering decisions did their job and chalk it up to the scars of battle. "Good judgement comes from experience. Experience comes from bad judgement."

minot 6y ago

I still don’t understand how this business model works at all. Take cloudinary, for example. You can have your images transformed and hosted by cloudinary. So like you have a photo and let cloudinary examine the photo and serve different sizes, cropping to a human face as a circle for profile pictures for example. It is expensive. All you need is some idiot hitting refresh in a few tabs on the browser for a few hours on your website for you to run over your free tier. I’d imagine that anyone spending real money is always thinking of ways to get off of something like this?

shash7 6y ago
It doesn't work like that. Cloudinary caches the transform so you only pay for the first time for the transform. Of course, you do have to pay for the bandwidth but by then the image would be cached somewhere on the network or on the browser anyways.
josephg 6y ago
I did some contracting work a few years ago, and one of our clients was a small entertainment news site. They used cloudinary for image hosting and were paying some insane amount for image hosting. I think their cloudinary bill was $8000/month or something. The client didn't even know that was expensive. They just saw it as a cost of doing business, alongside their cloudflare bill and so on. (And what they were paying us.) It took work over several weeks to convince them that that was a ripoff. I think their business people eventually called up cloudinary and negotiated a better rate, but by that point I was annoyed by the whole situation. The site used cloudinary's HTTP based API from the browser. I configured cloudflare to redirect any request hitting example.com/images/... to act as a caching proxy to cloudinary's actual servers. Unsurprisingly, that one configuration change made their cloudinary bill drop to about 1/20th what it was. When the client was billed we got a panicked phone call asking why it was so low, and if something was broken on their site. Anyway, tldr; lots of folks out there have no idea what a service like cloudinary should cost. Apparently more than enough to make cloudinary a profitable business.
- coding123 6y ago
  Awesome story.
- ProZsolt 6y ago
  I think it's also a problem that engineers are rarely incentivized to make the right decision initially. If the initial price is low they will be prized if they able to cut down the development time. After that if the solution auto scales then it will be the beancounter's problem.
  - qazxcvbnmlp 6y ago
    I deliberately make things expensive during development so there’s room to ‘optimize’ later.
- earthboundkid 6y ago
  I actually looked at Cloudinary for my job. I thought the pricing didn’t make sense so I ended up just running imgproxy on Heroku (it was free tier for a long time but I upped to hobbyist to get better latency).
lmm 6y ago
People don't pay you to run xyz, they pay you to solve their problems. If you can solve a problem that real businesses have, then as long as you're not charging enough to be a bigger problem than the original problem, they'll be happy to pay it.
petercooper 6y ago
We pay like $200/mo for Cloudinary and we barely use any of the features. Primarily it's to serve up an image scaled to the right (single) size and occasionally I'll tweak the URL to add an effect, a tint, or something. This convenience is worth the money so far considering $200/mo is a rounding error in our monthly expenses but I could probably write a script to achieve similar ends in a few hours and upload to S3 instead..
- pc86 6y ago
  Even if it's a rounding error, it sounds like you'd break even from having one of your developers do it within a month or two. Unless everyone truly has a months-long backlog of high-impact stuff to do it sounds like a good argument to do it some Friday afternoon.

bsder 6y ago

> AWS is a terrible value once you’re paying the price of a bare metal box each year (or sooner!) You're probably off by about 2 orders of magnitude. If your AWS spend is $10K per year or below, it simply isn't worth thinking about in terms of engineering time if you have real revenue. Once your AWS spend crosses about $100K/year, it's time to pay attention. However, you probably want to be stingy about this as your engineer is in that range. Your engineers are supposed to be providing business value and looking at $10K/year costs probably isn't worth their time. At the $1M/year mark, you already have an engineer on this full-time anyway so it makes sense to have some hardware you actually own in a colocation facility somewhere.

josephg 6y ago
I agree - but there's a few gotchas here. One is that there's often simple configuration changes where a few hours of engineering effort could save $30k+ each year, and those changes can still be worth looking into. I set up AWS a few years ago at a startup I worked at. I didn't really understand the difference between spot instances and reserved instances on EC2, and I didn't bother to learn (we were all very busy!). We didn't notice for 18 months or something, and the amount of money we wasted with that single mistake would have paid my salary for several months. Its also easy to accidentally lock yourself in to bad infrastructure decisions early, that become extremely expensive to fix later. Mongodb might seem like a good place to start your project, but trust me - moving away from it down the road will be a nightmare. Too much up front design will kill your velocity. And not enough up front design will cost you too. If there's a good rule of thumb here, I haven't found it yet.
- ramraj07 6y ago
  Thanks for the honesty, most new engineers make such mistakes, AWS and other massive Cloud offerings are like a forest where one can easily get lost!
- bsder 6y ago
  > he amount of money we wasted with that single mistake would have paid my salary for several months. Sure. Presumably, though, your engineering salary for a couple months had more business value than you would have saved, so it's still a net plus. > Too much up front design will kill your velocity. And not enough up front design will cost you too. If there's a good rule of thumb here, I haven't found it yet. In my opinion, err on the side of velocity. Most startups are worrying about staying alive. If the startup survives to have the problem of ripping out bad decisions, consider that your engineering decisions did their job and chalk it up to the scars of battle. "Good judgement comes from experience. Experience comes from bad judgement."