The thing is tables and Canvas-like columns (which I also know how to do) don’t work well with my typical users, who just want to make a wiki-style website. Because of the nature of my projects, the amount of training I can expect users to have on Coda is about 15 minutes.
The current pages model work for KB-style Docs. Why break it?
I am not at liberty to discuss my Enterprise order but let’s just say I disagree.
The one area where I agree with the detractors is the way in which the price change was done
It unfortunately seems to be a recurring theme around Coda and its software rollouts.
Coda’s “problem” is that it is so flexible. Some people focus on the database like aspects of it, including the formula language, others focus on a page based wiki toe implementation, with probably next to no table and CFL usage.
I see,
Seems to me your workflow is rigid. and is difficult to satisfy whatever the tool. etheir you pay more or adapt your mindset.
I would rather prefer that they do some limitations that can make them more profitable, than rising the pricing like airtable did. Especialy when you invest so much time to learn it.
The pricing implementation for Coda AI is too limiting and can potentially become more expensive than other available tools on the web.
For the Team plan, the allocation of 3000 credits is insufficient. Adding another doc maker to obtain more credits doesn’t seem logical, especially if I don’t need another doc maker.
If I need to generate or correct a two-paragraph text, it appears that I can only do ten per day per month. What if the results are unsatisfactory, and I need to redo the prompt, which often happens?
Furthermore, having to pay for an additional seat just to get an extra 3000 credits seems impractical. As it stands, I can see myself continuing to rely on other tools for AI work and only using AI in Coda for specific use cases, such as page summaries
I’m also in a similar circumstance- currently a team of two, but may have a few more soon (max of 5). I unexpectedly hit the AI limit on my first try using it- it was quite a shock, and even more of a shock to see that I can’t add on more credits. I don’t even consider myself a heavy AI user, but I love the experience of writing in Coda (especially with suggested changes, which is essential to editing and co-writing and lacking pretty much everywhere except Gdocs). Anyway, I was testing the AI to see how I can integrate my workflow into Coda and was shocked that I hit the limit on the first try with no recourse.
I’d be more than happy to pay more for a credit bundle, especially if this condenses my work into Coda (and possibly eliminates the need for me to pay for tools elsewhere.)
I’d be happy to chat with you more, David.
Asha
I agree with you that all of this is impractical, I just wish it wasn’t. Coda’s whole thing is brining together all of your work from all of the places, so running around copying and pasting between various AI apps just to not have to do it in Coda is very inefficient and adds so much friction to my workflow.
You realize this is a bug?
users who want to make wiki-style websites are Makers not Editors IMHO and so should pay the appropriate fee. its one of the best value-per-dollar offers out there.
I don’t think it was- I was using it to clean up a large transcipt- like, 3000 characters.
It cost 1400ish credits, which tracks with the use tables Coda has provided.
I was just playing around and testing it out to see if it was something I could do in Coda and be happy with the results, since that is the ultimate home for that content, and it would remove a step in the workflow.
This summarizes the vision of Coda. 
Thanks for sharing your feedback. I heard a few themes and wanted to share a few thoughts below:
Are we pushing AI too hard? It seems you’re getting less value from AI than some of our other customers, and it’s more annoying than helpful — thank you for sharing this feedback; I’m passing it along to the AI team.
Are we making the right choice in shifting Doc Makers to include page actions? I think there is a wide variety of sentiments here. We take your trust in us very seriously, and this was a big decision for us. Which is a reason why this is the first big pricing update we’ve made since 2019. There are those like yourself who are disappointed in this change. Others feel we didn’t go far enough with this change and should have gone farther — restricting even more schema actions as Doc Maker only. I empathize with all the different opinions here. What I can say is that we looked hard at the data, customer feedback, and support questions around the definition of a Doc Maker before making the change. But I hear that’s not the bulk of your feedback, which brings us to —
Are we handling the transition in the right way? Did we understate / misunderstand the impact? When making a change like this, it’s hard to estimate all aspects of impact. The data was indeed clear - for the vast majority of our customers, the impact seemed small (<5% as measured by a % of editors). Of course, this isn’t universal, and some teams are impacted more than others. A few notes on some of your suggestions:
Not making the change retroactive: This one was really tough, because a fundamental challenge was that the definition of who should be a Doc Maker wasn’t clear. As pages have gained a ton of flexibility and power over the years, they’ve become “the new docs” for many teams, especially those that come to us from tools where docs are much flatter. We had to tackle the issue at the mental model level vs. the feature level.
Grandfathering: We explored the implications of this, but decided against it. It would mean maintaining different definitions of Doc Makers for different customers which is, unfortunately, far too complex, and our team was concerned this complexity would result in downstream issues for our customers.
Different ratios by tier: Interestingly this was our original model when we introduced Maker Billing. We thought that was a reasonable path at the time, but soon heard clear feedback that customer admins found it much simpler to know and manage to a list of maker actions rather than try to communicate ratios. So we responded and landed on the model we have today.
Handling transitions, longer transition timelines: It may not be obvious here, but we have been actively working with teams that will be disproportionately affected. In some cases, it’s been simple misunderstanding — because they don’t yet really know what future behavior will be like, they might have interpreted the change as “all my editors or users will need to be makers,” but when we show them their own data, they realize that very few non-makers had been performing those actions in the recent past. And for others, sometimes we have a different setup or pricing pattern that can work. We’re hopeful that, on November 6 when the changes take effect, that you’ll be able to see what, if any, impact there is on your Editors — who really does need to be a Doc Maker, and who can remain Editors with little to no impact.
I really do appreciate the time you spent in providing your feedback, and I’m happy to jump on a call with you to discuss further. Please email support@coda.io to let us know if you are open to it, and we’ll get that set up.
There’s been some amazing input around Coda AI on this thread - thank you all! As Coda AI Product Lead, I wanted to respond to a few of your points.
Why is there a credit system? And why do I have to add Doc Makers if I want to get more?
When planning this launch, we knew we wanted to include AI in our Doc Maker packages. We also knew that AI processing power can be expensive and so we looked at how we could cover our costs while providing a valuable experience. It was clear many workspaces have a smaller proportion of heavy AI users that build powerful workflows that process a lot of data, and many users who lightly use AI.
This is a big part of why we designed the credit system to pool at the workspace level: it allows heavy AI users to make use of AI credits that other lighter AI usage makers aren’t using. We expect in the vast majority of cases even if you might go over your monthly maker allotment, you’ll be able to work with the workspace’s overall pool.
All that said, we understand the pooling model works less well in small workspaces with only a few makers, and the current option of adding new Doc Makers just to use AI more is counterintuitive. So we are actively looking into other options, including the possibility of buying AI credit add-ons. More on this soon.
What ate up all my credits?
Workspace admins can see the number of credits used by users within each workspace. We are building dashboards so all users can see exactly where their credits are going. Until we launch improved dashboards, if you have questions about where your credits are going, you can contact support@coda.io and we can work with you to understand what’s happening in your account.
On launch day we had an issue where some activities we didn’t intend to consume credits, used your credits. For example, previews in the AI column were counting towards credit usage but never should have. This has been fixed. Sorry for the confusion this may have caused and thank you for your patience and understanding. If you have questions about how AI credits have been used in your account, please reach out to support@coda.io and we can work with you to clarify what has happened in your account.
Thanks David, but I still have more thoughts on this!
Perfect! Would love to hop on a call and get your feedback on our approach if you’re open to it. Email support@coda.io so we can set up some time.
Thank you!
David
Thanks for the clarifications @khanh and @DavidK. I appreciate how transparent and open to feedback Coda has always been with the user base (and I’ve been here since before there was any pricing at all!).
I agree with some of the commenters who feel that restricting page creation is a pretty significant redefinition of the Maker role, at least in how my small team uses Coda (a few super-complex app-like docs, and a bunch of clones of a project management template, one per project). It will be a bit of an adjustment for those project management docs in particular (though I think canvas columns is a workable solution there).
As a small business owner, I know the challenges of expense management all too well. However, I also know the challenges of tools I relied on disappearing out from under me because their business model turned out to be unsustainable. There was a recent discussion on another thread questioning Coda’s financial stability in a year of severe tech industry layoffs. I’m not an expert on this kind of thing, but from where I’m sitting these pricing changes seem like a good balance of providing fair value to users while bringing in the income necessary to ensure the service we all rely on stays up (and continues to improve by leaps and bounds every year).
It’s not that I don’t 100% agree - canvases are more powerful than pages. There’s really no denying that. But that doesn’t mean pages should be further weakened by being put behind a paywall.
Because the functionality between canvases and pages still differs significantly you are effectively killing off a lot of potential use cases where pages are a much more apt solution to a problem.
Yes, your data tells you that this significantly effects less than 5% of users, I have no doubt that’s true because Canvases are so powerful. I do construct my docs using canvas tables. It’s just that I wish I didn’t have to! Page should be better, not worse. For myself and my users the experience of using canvases can’t measure up to the familiarity and intuitiveness of pages.
In comparison to pages, canvases lack:
And then there’s the UX differences:
Canvases are fundamentally multi-modal. For each process document I write out and store in a canvas I have to worry about at least 2 places how that information is displayed: The expanded row “pop-over” UI and the expanded row full-screen UI. The layout of these are informed by the woefully inadequate Layout editor. Alignments are all over the place depending on what type of info you want to display, especially when putting 2 or 3 elements side-by-side. And no matter how hard I’ve tried, the layout always looks bad because you either optimize the look for the full-screen UI or the expanded row UI. Making both look good is virtually an impossibility. Airtable’s interfaces feel a lot better than what you can do in the Coda layout editor, largely because each element you add always gets its own “bubble” around it and nothing is left floating in space like in Coda. I have faith that Coda will continue to improve this, but this is the current state of it for me.
Reading a canvas in the expanded row view fundamentally feels bad if its something you’re going to be reading for more than a minute because it locks you into a fairly slim pop-over that lacks context of the entire document. It feels a little claustrophobic. This is fine if you’re quickly reviewing the data of the row, but because Coda is now officially encouraging that this is the spot where you might read something for 10+ minutes it needs to adequately support both.
Reading a canvas in the full-screen modal of an expanded row is so awful it honestly needs to be addressed. Nobody wants to read a paragraph that goes across your entire screen. I don’t want my users to be able to destroy my intended formatting of my carefully crafted process document by clicking one button. Pages prevent that, and obviously a lot of care and craft went into doing so - having granular page width options to prevent text from overrunning but the tables on your page not being restricted by that setting is smart thinking. Smart thinking that is only available on a page.
Switching between documents is far more user friendly if they are pages rather than canvases. The left-side navigation panel is always there, ready to direct you to all the most important things, with nice icons and pages and sub-pages. Combing through a table to find the right process document pales in comparison.
Need I say more? I am merely reiterating the obvious - pages and canvases are very much not the same thing. Yes, canvases can accept the exact same formulas, separators, headers, text formatting, etc as a page can. But no matter what they are two separate entities that serve very different purposes.
Coda’s only fault in my eyes is that when I show it to the designers I work with they recoil. It’s difficult to make Coda look good and feel good to use. Making pages a paid feature further restricts my ability to set up docs that will not only fulfill their function but do it while giving a great first impression to my perpetually timid user base who will reject a method just because they didn’t like the UX.
If I could hear some confirmation that there will be steps to close this gap between the utility of pages and the functionality of canvases, either by addressing the issues raised above, or adding functionality such as @Paul_Danyliuk outlines with his suggestion to add a page-making feature to tables, then I have no issue with this change. But Coda needs to recognize that as it stands currently they are weakening a core feature of Coda that was already being under-served. I want pages to be as functional as a canvas, and I don’t want to be punished for using them more extensively. This change funnels the future of Coda down a specific path, and I even though I am a huge fan of Coda I find that troubling because the flexibility is what makes the app great.
Look, I’ve posted like 3 very lengthy posts in this thread and I truly do it out of love. I want to give as accurate feedback as possible to my situation so Coda can continue to be the best around.
At the end of the day, is it the end of the world that I need to pop in and add some blank pages for someone to work with sometimes? No. Is it a big deal to implement Paul’s page-making pack in any documents that need it? No. But it just feels like a misstep to me and I don’t see clear arguments why this was the best possible direction to take coming from the Coda team yet, especially when it feels to me that it is failing to close the loophole that it was targeting: Charge for makers, not collaborators. Its so simple to continue to get around this latest restriction. Is there something preventing me from making a template with a dozen or so empty pages that I can add in upon request and my non-paying editors could build out a doc with close to no issue? That annoyance is not ever going to motivate me to relent and multiply my cost of using Coda.
I am rooting for the team here, and I think this complication makes the calculus that new potential customers need to solve before buying into Coda much more complicated than it should be. Because inevitably the people who are pondering whether they should jump on board Coda aren’t power-users who know that this restriction is less impactful than it might seem like from the outside looking in. You’re going to get many more companies signing on with 25+ users now, which is good I guess? But do you really want to start that relationship with that company based on their misunderstanding of how Coda functions differently from other services of its ilk?
I’m not sure you can say “Coda AI is free for Doc Makers” as that’s fairly far from the truth. My initial interpretation was that it would work similarly to Notion & Taskade, in that you would receive unlimited AI access as a Doc Maker. However, after running a single AI prompt on a medium sized database, all of the credits were used.
So, in my case, it just doesn’t make sense to stick with Coda if the AI integration is essentially unusable.
Probably a better statement would have been, “Coda AI is accessible to Doc Makers”.
Just to outline how easily it is to go through 1,000 credits.
~250 Tweets
~90 Emails
~50 SINGLE AI Chat Messages
~50 SINGLE Cell Updates
I was about to write very similar thing when I saw your post. Cant agree more with you, at lest from my perspective. I can fully understand some people have different use cases/views and I respect that also, but I still feel value proposition of Coda is pretty good at the moment! (I hope we don’t jinx it 
)
I think it’s interesting how fast we got used to AI and getting so much for „free“, that we can’t value it at all anymore.
So, basically you are saying you are disappointed because additional to what you already get with Coda (lets assume Pro), where you pay a fair price for an immensely powerful tool, you additionally get 250 tweets you don’t have to write yourself for free, or 50 paragraphs of text per month. But you don’t consider it as for free because it is not enough.
Coda is so much, for many years already, and AI is a wonderful addition to it. Not sure how that addition makes Coda unusable now.
What will happen to: