Upcoming changes to Netlify plans

For our particular situation, these changes aren’t good.

When we outsource work, we give temporary access to some devs on Github, let them commit and leave it there. Netlify shouldn’t care about it.

Actually, having more bandwidth on Netlify is not even interesting for us since we had to put Cloudflare in front of Netlify to avoid huge bills due to a sudden spike in traffic.
We don’t need everyone who’s committing code to be part of the team on Netlify, nor are we willing to pay the extra cost. At least if it were reduced to let’s say 5$ a seat, we could still have 20 people for 100$.

Thus, depending on the situation, we might look elsewhere, like Cloudflare pages.

Note I still think Netlify has great value and will use it for certain projects, but is probably not friendly anymore for certain type of organizations.

1 Like

That would be fine with us.

Thanks for the comments, @biilmann. However, there is still a major issue with the narrative presented that I don’t think you or your team has fully acknowledged.

So far, it seems like you didn’t notify anyone at all prior to the change–except for a post on the support forums (this one).

Everyone with a github connection was affected by this change–probably more–you should be reaching out to all of your paying customers, not just the people complaining or those who hit some abstract ratio of git contributors to team members.

There’s still been no communication via email past the post-implementation email and the initial “whoops” email that was sent out last week. You may have seen a number of upset responses here, but a quick search on twitter will reveal the problem is much more widespread and those are only the folks that are complaining.

We’re all losing money accommodating this change–“we’re trying” isn’t enough. We need the git contributor workflow changes rolled back until we all have time to accommodate the change with proper notice.

Thank you for rolling back the deploy approvals, however, we’re still not seeing any substantial communication outside of this thread. (I just did a test commit to see if this was true because we didn’t get any notice of this outside of your reply on this thread)

Ultimately, our team is left asking: Does the leadership team have any idea of the scope of impact of these changes? Should we continue to trust Netlify given how poorly the rollout of these changes was handled and how the response has been equally unsatisfactory? Currently it feels like the answer is “no”.

Your support and engineering teams are doing great work, but they’ve been failed by the leadership team–they don’t seem to have the resources, information, or directives necessary to address our concerns.

2 Likes

^ @billmann this right here

FYI – the changes got rolled back for our team as I was writing the post, are you still getting approval requests, @ten07? (just curious)

@cosmicneil — Just checked. Confirmed. Looks like rollback wins. :face_exhaling:

2 Likes

Just to be clear, as per the post by @biilmann

It’s not a permanent rollback, just a temporary removal of the restriction as it was currently implemented.

It’s a “pause” to provide time to “prepare for the change”… for which you can only either “make sure that your wallet has enough money” or “spend the time migrating your projects away from Netlify”.

1 Like

Yes, an important clarification indeed. The thing that isn’t clear to me is–is this a blanket rollback until they have an actual plan for implementation or is this the 30-day rollback mentioned in the email? Because, based on the email and the statement from the CEO, this seems like two different “pauses”?

As far as I know, we haven’t initiated this process, yet the change was rolled back for every team we manage. Are these the same pause and they’re just mixing their messaging? Or is there a superseding pause of an indeterminate length to “make sure [customers’] workflow is not in any way blocked by these changes and that we have a path to permanently fix the issues with the approach of having to manually approve and add team members”?

@cosmicneil I just had a chat with @safoo from the “Partnership Program”, while he couldn’t speak to any of the changes, there was likewise no hint that Netlify plan on actually rolling back the change.

They claim to be listening and they’ll obviously need time to react, but until Netlify prove themselves with their actions or provide any statement otherwise, the safe play for your business will be to operate under the assumption that per contributor pricing is here to stay.

I was deeply troubled that @safoo indicated that for agencies the “best practice” is to set up “a Netlify account per client” and thus for each client to get billed individually directly by Netlify for each developer/git repository contributor.

I may be the only one, but this is absolutely outrageous to me, since it multiplies the number of “seats” of a single developer by the number of client accounts they’re working on. Which generates a windfall to Netlify, but is of no benefit to the agency and burdens the client with an increased and changeable cost.

2 Likes

There’s really three major issues to this pricing change:

  1. People were (if at all) informed at far too short notice, especially given its breaking potential.

  2. It leads to a strong loss of trust when a service you rely on and depend on adjusts the pricing model (for an existing relationship) in such a way that it can lead to exorbitant differences.

  3. The new pricing model per se is not cool, at least for some groups. Imagine a web agency of 20 devs with 50 small clients. Each of them has its own Netlify Pro plan (because a. that was the way to go and b. it keeps concerns separate). Now you’ll have about 3 devs working on every project, but one time here and then again there. And you have 2 team member changes every month. Now imagine the administrative mess keep the members per projects in sync. Not to mention the increased pricing despite most of those site having small requirements. I personally like services that scale well – it’s totally ok to pay a few thousand bucks. When you need it!

Still, I do see your issue and that you want to avoid 1000 collaborators for only one paying Netlify account. My suggestion would be to make this a monthly usage option. E.g. Pro plan includes 3 contributors, every additional contributor costs 5$. Something along that line – this also wouldn’t break existing projects and only cost more at peak times.

I really hope this will be fixed, because I (and many I know) love Netlify, but that kind of stuff is hardly acceptable.

4 Likes

This would be a great solution.

We remember that the previous pricing plans were like this.

Yeah, I don’t see this changing either, especially as vercel has implemented a similar seat-per-contributor system as well (I suspect other providers that offer similar “bells and whistles” will be doing a similar thing). I just wish Netlify would have one clear and concise communication about the timeline that isn’t countermanded within a few days or hours and own up that it’s not a handful of accounts that were affected but that every customer that has this kind of integration that has been affected, and as far as I can tell, no one has been appropriately notified. We still have other teams that haven’t received a single email about this.

1 Like

Hey there @cosmicneil - and for anyone else following along, I just wanted to confirm that anyone who we talked to via email about this (most of you we reached out to you by sending you an email, the rest of you we contacted via email from the helpdesk) is guaranteed to have the 30day pause on this feature before reactivation that we mentioned. We are absolutely going to keep that promise; that has been explicitly confirmed with our leadership team.

A point of information: what exactly is a “Committer”. Pre GitHub days in Open source at least (not sure about inner source etc) a committer was generally a core team member who could submit changes to the core code base. Everyone else was a “contributor”. Simples.

Now With GitHub people can submit PRs with commits in a non critical or even non repo branch. People submitting PRs from external Forked repos are clearly contributoes and not comitters as far as the repo in question is concerned. But others with restricted repo access may be allowed to commit to non critical paths only. I’d call them contributors with extra prviledges but expect they’d fall under your definition of committer (perhaps AKA github team member).

HTH

1 Like

thanks slim, that is part of the conversation we are having.

we’re going to get some news out to you as soon as possible (trust that the support team has been very hopeful this will come today, but it is looking like early next week)

1 Like

@perry I presume there hasn’t been any news yet?

Hiya,

we hope to have some updates out very soon - I can’t say exactly when - still bubblin’ - but soon. I can promise soon if i can’t say exactly which day.

1 Like

Do we have any news on this topic?

:face_with_monocle:

Hi there, we have just released some more information about pricing changes.

here is a thread with a link to our blog:

In order to keep conversation all in one place, please continue the discussion there.