Hacker News Reader

Comment by iamcalledrob | Hacker News Reader

I unfortunately had a less than stellar experience with Render.

The actual services worked great, but their pricing changes at short notice left me in an awkward spot that made me not trust Render going forwards.

tl;dr is that they introduced a charge of an additional $20/mo per person on top of compute. Even if it's just to maintain billing info.

This may be trivial if you're a business spending hundreds or thousands on compute every month, but for bootstrappers, hobbyists and freelancers this is horrible. A $7 instance easily becomes $67/m if a couple of other people need access.

I had just moved a bunch of services over from Heroku when this price change was announced, and it was a very sore experience. Poorly communicated with very short notice.

Jumped ship again to DigitalOcean, which has a near identical product but without the wonky pricing.

More discussion: https://community.render.com/t/pricing-update-nov-2022-reque...

View on HN

Yeah, I had been keeping my eye on render.com, but haven't been using it yet -- I just noticed the price changes, which can be pretty steep for a small project. I was curious if they had been discussed on HN yet.

Now, I'm currently on heroku, and to be honest, the pricing of heroku is not a huge problem for me, although did seem a bit steep. (With a small/medium sized project for my small non-profit employer, I pay heroku somewhere between 8-10K a year -- kind of a lot for us, but less than sysadmin/devops, and peanuts for heroku).

Render used to seem _incredibly_ lower-priced than heroku, which led some people to suggest that heroku was incredibly over-priced... but perhaps this pricing change shows that in fact render was kind of under-priced. It's hard to say exactly what my spend on render would be if I switched, as the metrics charged are different, and I haven't done the work to estimate.

But I'd guess it's still a bit cheaper -- and honestly even if it were about the same, that would be fine... we're not looking to get off heroku because of price mostly, but because we don't trust heroku's future.

I really don't love the per-developer pricing or the non-trivial bandwidth pricing though. I don't like being incentivized to have fewer developers with access to render. And for a small organization, having predictable pricing that doesn't go up if our bandwidth goes up (not entirely under our control) is huge, and something that heroku gives us... although I realize there are hardly any services that can give you unmetered bandwidth these days, it may just not be feasible.

I would _rather_ have increased compute prices, that are more predictable and stable costs for us, instead of a per-developer or bandwidth increase.

I hear you. As I'm sure you saw, the per-person fee is only for active team accounts; individuals/hobbyists still only pay for compute, and inactive teams don't pay anything.

The team charge assigns a nominal value to the productivity boost Render gives to teams, without increasing compute prices (which stayed the same even with the change). Existing single-seat teams also got a 6-month grace period for team fees.

While our change means we're not the cheapest option on the market, we believe the DX and features we have (and will continue to add) makes Render an incredibly good deal, both now and over the long term.

I was eager to give Render.com a try, but $20/user seems both strange and unnecessary - especially considering your positioning as an alternative to Heroku (you even have "Compare to Heroku" on your frontpage). For our case, if we were to switch over from Heroku, we would be paying more for _just the users_ than we do in total for everything at Heroku.

I'd be really interested in hearing why your reasoning for seat-based pricing, as I struggle to see this from a user perspective, and from the perspective as someone who runs a SaaS. Paying a $20/month premium per user just for the privilege of paying you for computing seems like a strange proposal.

Reply on news.ycombinator.com