To your first point, we’re always actively working to improve performance, but 10K-20K rows isn’t a hard limit. We have tested docs with 100K rows successfully. We have a few help articles on improving performance when you’re feeling a slow-down.
That said, I’ve shared your API issue with the product team!
I definitely feel this should be the case! I’m a part of five different organizations, which essentially means just for myself I’d be paying over $150 
This is unfortunately incredibly disruptive and disappointing when it comes to the need for “Doc Makers”. We are a documentation heavy Data Science and Analytics team, and this really changes things for us.
I really consider the messaging here to be “Corporate Speak” and gaslighting and using the veil of “Supercharging Doc Makers” as a way to to hide the fact that costs will increase drastically for some companies using Coda.
Coda is a great product. Changes like this happens. I know most of us are accepting of that to a certain extent.
But perhaps use less positive/uplifting wording as it can be seen as offensive to many of us.
Long time coda user here. The pages change is really disappointing. It breaks the promise I signed up for years ago, pay for makers, not for editors.
We created workflows based on your definition of maker vs editor. PMs are makers, Dev and Clients are editors. Your change broke our workflows.
I get that SaaS needs to make money, but it leaves a bad taste that the actual model changed, not the price for the existing one.
The issue is we have team members that very rarely add new pages to an existing doc, now I need to pay for them when they do add a page every few months. Sure I saw the pack to add a page button… but the whole point of code it it’s supposed to be easy-no-code. Now I don’t want ask our devs (editor) to waste a PM’s time (makers) to rename, and move pages or something like that. The tool is supposed to reduce overhead not increase it.
We also have a workflow where the icons are “status” pages. Once something is ready we change the icon to a green check mark. So devs review partially completed specs and change the icon or updating the title to more accurately reflect the content - That’s now a maker thing. So in our situation every team member will need to be a maker so that once and while they add a page or rename one.
So if my team needs to be 100% makers, notion is a little cheaper for us. Now coda vs others is a pure feature comparison and not a pricing model comparison. The value prop is quite a bit lower then it was on before this update.
Suggestion here: You’ve already opened the can of worms of “credits” for AI calls so why not gate “Updates” so editors can apply 50 changes a month or something. So the occasional changes are OK but heavy users need to be makers?
@Jeremy_Clover thank you for your feedback and sorry to hear that this has been a disruptive change for your team. Can you share more about how your team was using Coda so we can understand this impact?
@BrianD I understand your frustration; our goal with this change was to make understanding who within your team requires a doc maker licenses an easier process as you grow with Coda, while still encouraging collaboration within your doc for editors.
We heavily depend on Coda as a surface for every analysis we publish, documentation for every tool and workflow, a record of every communication we send for future search and discovery, every proposal and PRD we put together for the internal products that we build. It’s well organized and structured. We have an org of about 50 (small) in different timezones across the world. We leverage Coda as a live and transparent history of everything that we are working on, thinking about working on, and the assumptions that go into it. To bottleneck this workflow by changing who can do what now either requires that we make everyone the “expensive” license for everyone to retain functionality we already had (and why we moved to this product from Confluence), or we route these through a small subset of doc makers who are going to increase the time of decision to create new pages due to timezone constraints and availability. This tool just lost a massive use case for us, which was the ability to unlock everyone in real time.
The point is, I understand the drive in this market to make money as a Data Person. We do this type of analysis ourselves - I get it. That being said, it’s clear you wouldn’t change pricing to make less money. You expected to charge your customers more.
In this case, for a local optimum, you’ve likely missed out on a global one that would be much better.
Our switching costs just decreased due to the increase of yours.
Hi Aidan — I’m sorry to hear about the frustration here. Thank you for taking the time to share your use cases & workflows, the page icon one is an interesting one that I don’t think I’ve seen before!
Thanks for the suggestion around gating frequent vs. occasional “updates.” As you guessed there’s a wide variety of sentiment & opinions here, and we looked hard at the data, customer feedback, and support questions around the definition of a Doc Maker before making the change. We’ve experimented with more complex mechanisms like ratios of Editors to Doc Makers by tier before, and heard clear feedback that customer admins found it much simpler to manage to a list of maker actions, rather than try to communicate what might seem like arbitrary ratios.
I passed your feedback along to the team working on these changes though!
@BrianD I understand your frustration; our goal with this change was to make understanding who within your team requires a doc maker licenses an easier process as you grow with Coda, while still encouraging collaboration within your doc for editors.
@Brian_Klein this is more gaslighting. Was this Coda’s only goal? Doubtful. I appreciate you responding, but this explanation is even worse and honestly more offensive.
To make this more direct. The majority of us believe you are making these changes to extract more money from your customers. Which is perfectly reasonable. So, just say that, stop with the BS gaslighting.
Thoroughly upset that my editors can no longer add, hide, unhide, rename or overall do anything related to new pages within documents. Even within their own spaces that are already created. I could understand making a brand new doc/page would be limited, but within an already created document or space? Seems completely absurd. We have 15 editors and 5 doc makers on our team. Within the first 2 days after this change, our Doc Makers have been bombarded with menial tasks that should not require a more expensive license to accomplish. Completely disappointed.
Hello @Brian_Klein like you already mentioned before in this conversation that one of the Coda 4.0 changes was making showing hidden pages unavailable for editors.
I have noticed that it is still possible via the app (IOS and android) to show hidden pages as an editor. Is this on purpose? Now it is easy to bypass the hidden pages lock for editors to just open the app on your phone and unhide the hidden pages.
Thanks Andre, we’re having our team take a look at this.
It seems unreasonable to say editors are free and then remove just one feature that requires people to go from $0 to $36/month. Surely they could create a price between those? It would be one thing for me to be asked to pay $10/editor/month (with the ability to add pages, without a workaround) and then $36 for makers, but paying $36/user for a team of 40 is a disaster for me.
Dear developers! With the new update you have introduced control over the hide / show pages feature for doc creators and editors. This could be a tool for granular access in some cases. However, these pages are very easy to find via the search bar. This seems like a bug, because it completely invalidates the original functionality to disallow displaying hidden pages. A better solution would be:
I somewhat understand why only doc makers can make pages now but subpages as well?
Editors can not even edit icons now? Sigh.
The fact Coda allows users to use this AddPage Pack, just prove that this new pricing structure, where just DocMakers can create pages, is totally useless (why I should pay more if there is a workaround??) and, at the end of the day, just will annoy the current user.
Some suggestions if Coda needs to increase its profitability:
Totally agree !! That AddPage restriction, aiming to have more paying users, at the same time allowing users to use a “workaround “ via API, is totally nonsense and useless. The result will be users sadly jumping to another tools instead buying more seats…
If Coda wants more Doc-Makers - especially those who work in the Team plan, then one approach would certainly be that the costs for additional packs are not charged to all Doc-Makers, but only to those who want to use them themselves. I assume that packs are installed domain-wide, so this would have to be adjusted accordingly. We would like to have more doc makers, but at the same time each new doc maker makes the use of packs less financially viable.
Same. We trusted that Coda would maintain a reasonable pricing scheme and all of the sudden my cost, if we were to continue using it, would jump 10x from ~$100/mo to ~$1,000/mo, and I’m not willing to pay $36/mo for someone to be able to add or rename a section once in a blue moon. That’s insanity.
There are a lot of ways to divvy up pricing. I’d be willing to pay $5-10/mo per editor which would have increased what I pay them by 2-3x, but the current change reflects an insane 10x jump.
For the vast majority of teams, this results in a small impact (<5% of current Editors needing Doc Maker access).
I find this statistic incredibly suspect:
#3 is the part that’s the real kicker for me. My users need to create or rename a section once a quarter, but if I want to avoid having them have to track down and bother an editor, I need to spend $36/mo for them. That’s insane and, at least in our case, is just not going to happen.
I suspect you’ll see a short-term bump in revenue, but a medium-term decline unless this marks a drastic change in strategy: with this price change, you just turned your small-business-friendly product. enterprise-only.
