[TobyTheDog123]

Netlify pricing has always been confusing to me, but I'm not entirely sure why. I guess I'm more accustomed to pay-as-you-go in this space (CFW) than tiered plans (Netlify bundles their features into starter/pro/business).

It seems that the free plan is 3M invocations/mo, starter is 15M/mo, and business is 150M/mo, but there aren't any ways to increase those limits (business says to contact them for higher limits).

Personally I'd prefer true pay-as-you-go without hard limits, even if it's a bit more expensive. To me the point is to sign-up-and-forget-it without having to worry if I'm within those limitations.

[foxbarrington]

Netlify's creative pricing is what lost me as a customer. They decided to start reading our git commits to decide how much to charge us. Instead of charging for usage of bandwidth and build minutes they decided to charge based on how many different authors we had--even though those people never interacted with Netlify or even knew how we were deployed. If we didn't hurry up and migrate to Render.com this would have taken our bill from $1.5k/year to over $25k/year.

[jamestanderson]

Wow - really surprised at this move by Netlify. It looks like that's a new policy[1] where a "Member" is not just someone who can log in to the Netlify UI and manage a site, but anyone who can trigger a build.

Relevant quote from the article outlining the policy changes:

> For sites connected to private Git repositories on Pro and Business teams, Git contributors will need to be team members in order to trigger builds.

> Teams will only be billed for the number of team members. Currently, Git contributors are people who trigger builds on your team’s site(s). Moving forward, in order to trigger builds, Git contributors who aren’t Team Members, such as people in the ‘Contributors via Git’ section, Reviewers, or people not on the team entirely, will need to have their deploy approved by a team Owner.

> Once their deploy is approved, they’ll be invited to become a Team Member and can deploy without approval from then on. If their deploy is rejected, their build won’t run and they will not be added as a team member to your monthly bill.

> This change does not apply to sites linked to public repositories or sites on Starter or Open Source plan teams.

So it sounds like you could limit your costs by limiting your team Owners.

This pricing doesn't seem like a good value proposition to me. I see Netlify as a web host and CDN which has products very comparable to some of Cloudflare's products. In those spaces billing is generally based on usage, not number of seats.

What you get from Netlify doesn't scale with the number of seats you pay for.

If I have 1 member on the Business plan I'll pay $99/mo and get 1.5TB of bandwidth per month. If I have 5 members on the Business plan, I'll pay $495/mo and still only get 1.5TB of bandwidth. Hardly seems fair or reasonable.

[1] https://answers.netlify.com/t/upcoming-changes-to-netlify-pl...

[webmobdev]

> Personally I'd prefer true pay-as-you-go without hard limits, even if it's a bit more expensive.

Please, a hard no to that. That's the worse aspect of AWS, Azure and all those new huge hosting centers - hard to calculate the real cost and set a budget.

I don't know about Netlify, but the old Linode (before it got acquired), was flexible with its "hard" limits in a plan - for example, if your site got slashdotted / Digged (or was that dug?) and suddenly saw a spike on its resource, exceeding the limits, they were quite accommodating in not charging their users for the unexpected extra usage. Linode even wouldn't mind an occasional surge in resource a few times a year. But if it happened more frequently, they would recommend that you upgrade to a more suitable plan. They earned a lot of goodwill that way from their clients who really appreciated that their server / site wasn't unexpectedly taken offline because of a resource crunch they hadn't paid for and / or anticipated.

[TobyTheDog123]

Like another comment said, different strokes for different folks.

I would much rather pay overage fees than have my site go down due to a hard limit, but I would also like the option to choose the opposite.

That way you appeal to both sides of the scalability-vs-predictability crowd.

[phphphphp]

I have no special insight into Netlify, so this is (educated) speculation: there's an important difference between pay-as-you-go compute providers, like AWS, and Netlify: Netlify is a platform, their value is not derived from the workloads they process, so charging (or not charging) based on compute doesn't align with their value proposition. The value of Netlify is that it's an end to end platform, taking a business from having some code to having a live website, where compute is just one component of the entire value proposition.

The marginal cost of a request is probably negligible, hence the tens of millions of requests included, but there is a cost associated with each user making use of their platform because it includes a lot more than just compute, and that's the value they're charging for.

I think if you're looking for a compute provider that offers pay as you go billing in order to minimise your costs, then Netlify probably isn't the platform for you, and you'd be better off using their service provider directly (in this case, Deno, but many Netlify alternatives use Lambda, Cloudflare Workers etc.).

[mavsman]

Different strokes for different folks.

This has been one of the big knocks on AWS, that a poor little old lady can setup a "free" AWS account then when her website (and accompanying Lambda function) goes viral she gets hit with a $100k bill from uncle Jeff.

[rmbyrro]

Would the Lady prefer to let her site go down?

I don't understand this way of thinking. One of the main benefits of serverless is scalability, peace of mind for precisely when you go viral.

If you're doing something good, especially if you're selling something good, all you want is to go viral. And of you went viral, you don't mind paying the AWS costs, which should be tiny compared to your revenue. Just need to care about your unit economics.

[yurishimo]

Sure, but I think the GP was referring to a situation where revenue doesn’t match the traffic.

Imagine the grandma scenario. Let’s say that she cooks and sells artisanal jams and jellies. With the help of her granddaughter, she creates a TikTok that goes viral. Her web store immediately sells out, and the traffic from the video hammers her website. She cannot react fast enough to enable back orders and so most of those visits go to waste.

Putting aside the technical absurdities (why is she hosting on a lambda, etc), in this scenario, grandma is up a creek.

If this scenario were real, I would feel really bad for the grandma with a huge bill and not enough revenue to cover it, but I would be livid at whatever imbecile decided to set her up with such a ridiculous hosting paradigm.

“But it only costs pennies a month to run!*”

Yeah, until she goes viral. This scenario right here is why services like Squarespace et al are still valuable. You’ll pay a few extra bucks a month, but if you go viral, you won’t go bankrupt when the bill is due.

[rmbyrro]

Then get peoples emails to notify when stock is up again.

The worst thing it could happen is having your site down when many people want what you have.

In any business, the hardest part and most expensive, by far, is sales and marketing.

You wanna throw it all away to save 100 bucks on Amazon? That's insane!..

[tazard]

And how about a fun educational project you aren't expecting visitors for and make zero revenue from? AWS bills can far exceed 100 bucks. Paying thousands for... Exposure? That's insane!..

[realmod]

> Personally I'd prefer true pay-as-you-go without hard limits, even if it's a bit more expensive. To me the point is to sign-up-and-forget-it without having to worry if I'm within those limitations.

Sure, if you can set a max budget. Otherwise, you'd constantly have to worry about the unbounded cost.