Coda 4.0 Pricing Updates: Supercharging Doc Makers

[Scott_Collier-Weir]

@Remco_de_Louw

would the free tier help Non-profits? You cannot share or have Editors or am I missing something?

Personally I’ve worked on, in, and with many non-profits. In a majority of those cases there easily could have been a world where there was one free account who ran the operations of the business on a personal coda doc

Automations, organization of data, reports, dashboards, etc.

Surely it won’t work for every non-profit out there - but for all the ones I’ve been a part of it would’ve been an immense gift

[Remco_de_Louw]

Ah yes I understand!! It wouldn’t work for us but I get it.

[DavidK]

Thanks for your feedback! When planning this launch, we sized the number of credits to include in each tier per maker based on overall workspace behavior. We noticed many workspaces have a smaller number of heavy AI users, and a larger number of users who lightly use AI. This is part of why we designed the credit system to pool at the workspace level, so heavy AI users can make use of AI credits that other low AI usage makers aren’t using. So we expect in the vast majority of cases even if you might go over your maker monthly 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. For these we are actively considering the option of buying AI credit add-ons as you suggest. Would love to hop on a call and get your feedback on our approach there if you’re open to it. I’m sending you a private message.

[Reed_Mitchell]

I don’t understand what you mean:

“Even more, we saw AI’s potential to truly empower everyone, and anyone, as a maker to help you feel informed and plugged in, get your creative juices flowing, turn a spark into safe-space brainstorms, then proposals and tasks, then actually help get those tasks done!”

I didn’t ask for AI or for my creative juices to be manipulated. I’d just like more robust printing and faster ways to jump between docs.

R. Brian Mitchell, MD

Virginia Cancer Institute

Mid-Atlantic Medical Consulting

rbm@5mitch.net

804-833-8903

[Vitaliy_Malanchuk]

I have continued the chat about it in Coda chat support. But yes you are right, I am in category where max 3-5 coda makers ll be on team. My focus is ecommerce perosnal and ecommerce marketing for customers, so had hopes to integrate Shopify plugin, Coda AI, and replace some of the tools like (https://describely.ai/). Therefore 3k credits would not help, maybe a package to buy AI in bulk would also help where we can buy lets say 10k,50k,100k ai credits that stay in account until used. Although, I did truly hoped for at least 10k / doc maker ai credits. Thanks for the responses.

[DavidK]

Love that use case - love to chat more about credit packages!

[khanh]

Hi Tim — yes, as you mentioned, changes will not take effect for existing subscriptions until November 6th. Your workspace admin(s) should receive an email with details on how to prepare for this change for your workspace. We’ve also updated our in-product reporting to provide more information about your Editors’ Total docs (docs they previously owned or were an admin of, or docs they’ve added pages to in the past 90 days) and AI usage; you can review all this and more in your workspace settings → Members tab (more on that here.)

[Bill_French]

@Vitaliy_Malanchuk

the AI credits will be used up quickly since generating data for 250 products across various columns would already consume at least 1000 credits (and that’s assuming everything is perfect and we don’t have to regenerate any data, which I doubt).

Would a Maker or User be running this AI process?

Ya’ know - with the OpenAI Pack you are free to apply generative AI to any application without purchasing credits. If you use PaLM II (LLM) you can do all this initiall classification and summation for free.

[AJM]

I do think that editors can do a lot more than needed, but creating pages (or subpages) isn’t one of the features I would nix, personally. I would appreciate it, for example, if editors didn’t have the ability to establish new automations or new relationships, but COULD add subpages and use templates that have already been established.

[khanh]

Hi Reed — thanks for sharing your feedback. (I was initially also an AI skeptic, so I hear you. I hope you give Coda AI a try; we’d love to hear your feedback.) Our team has also been working hard recently to make it easier to search, organize, and navigate inside Coda — have you already tried out universal search and the QuickNav beta?

We also shared some updates today around sync pages (and sub-pages) that can be multi-homed across docs, so you don’t have to choose, and can have the same pages live across multiple docs.

[Vitaliy_Malanchuk]

Hey David saw your DM just now. Thanks

[Mitchell_Wells]

@Scott_Collier-Weir

Editors in Coda are far more than editors. Editors in Coda have always been architects. Editors have always had the ability to configure documents, build net-new tables, write formulas, and more.

Without knowing anything about Coda, I would assume that Editors can merely interact with exisiting elements on a page (like adding rows to a table, pressing buttons, viewing data, editing rows, editing canvas content, etc). Essentially, I would assume that editors are indeed EDITORS.

But Coda still maintains the idea of an editor as an architect. Yes, no net-new pages can be added, but any pages that are existing can be architected. New tables made, relationships established, formulas written, buttons configured, automations set, etc.

Fully agree, which is why I think its puzzling that the choice was made to paywall page creation - one of Coda’s most basic, familiar, and intuitive functions - rather than the higher end functions you mention. If their intent is to make sure that the doc architect must be a paid user than surely they should target the higher end rather than the low end?

What I’d want a member of my team to do most of all is the stuff that comes intuitively: writing out a process document and be proficient in using Coda basically as a word processor and a way to organize their thoughts. I don’t care if my team members can’t draw relationships between tables or wire up buttons. That stuff is best left to the doc maker to orchestrate anyways. So if we want to make sure the people constructing the docs are paying then why are we pay-walling basic organizational tools rather than power-user tools?

I would prefer they restrict setting up automations, configuring buttons, maybe even writing formulas before restricting page-making. Page-making fits very well under the “editor” moniker and is what my team would expect to be able to do.

I think Coda is a bargain, but obviously if I can avoid paying 20x the cost I am paying now then I will. So I’ll have to restructure our wiki doc to fit a narrower vision of what Coda can do. It’s just annoying more than anything.

[Theresa_Aguilar]

Out of all the platforms I’ve tried (Trello, Notion, ClickUp, Tallyfy, etc), Coda has been the winner in terms of user freedom and pricing. Every platform has jumped up in pricing PER USER , especially with AI, and so I’m happy to see that Coda did not go this route.

In terms of changing who can create and manage docs, I see no issues with this change. By having one doc maker seat, a team can still set up the framework for editors to operate in. I feel like canvas columns could be the alternative.

Either way, if that change impacted <5%, why not “grandfather” those accounts?

Thank you Coda team!

[AJM]

I second this request!

[Marko_Petrovic]

I just wish that, since Coda went into that direction, also ability to unhide hidden pages was also moved to Doc Editors only as the rest, that would really make a lot of sense, since most hidden pages are “background” stuff normal users shouldn’t really see anyway.
I know its not meant to be security feature etc, but 95% of “normal” users wouldn’t definitely open developer tools and start sniffing around or use some programming techniques to dig up those hidden pages. On the other hand it would help so much for easier hiding pages with background logic/calculations etc. “end” users don’t need to see
edit: also I think access to version history should also be restricted to doc makers

[Breno_Nunes]

@Mitchell_Wells

Two-way sync, along with a host of other exciting new changes, was just announced with Coda 4.0

One thing I miss about the two way sync is the ability to use CFL to modify the embedded Doc.
Do you guys have any plans to tackle that? Maybe by passing values in the url of the embedded?
It would be a game changer

[Paul_Danyliuk]

Posted in another thread, will reshare here for everyone who comes with concerns about the editors/page downgrade.

@Paul_Danyliuk

To everyone affected by the editors/pages downgrade (@Timothy_Choi @Ariella_Messing @Mitchell_Wells @Christian_Conte1 et al) — there is a way to alleviate the blow.

There is still a way to add pages through Coda API, which will (as far as I know) remain functional for makers. It’s not a full replacement — there’s no way to delete or reorder these pages, and definitely it’s not as convenient as just adding them in the editor. Yet still it’s a valid way. The “add page” button can be implemented as a pack; the doc maker would then make a shared connection for it in their name. There’s plenty of generic Coda API packs already, but I went ahead and created a specialized one with hopefully a better UX and some specific design choices (e.g. only a doc owner can install it, and each installation is limited to only that doc) that’s also more secure than just allowing all API calls on the maker’s account:

[Pack] Add Page — As a doc owner, allow editors to add pages after 4.0

Before making it, I ran this by Coda and they were okay with it. To me this is but another proof that this change is not about paywalling but about making a right design change that in the long term will promote better practices. I’ve been around long enough to live through the whole 2.0 Pricing thing, and I can say for sure that the way they handled it really shows that Coda cares and listens.

[khanh]

Thanks for the thoughtful feedback here Marko! Just to confirm your intuition, with this update only Doc Makers will be able to hide and unhide pages.

Good feedback for us to consider on access to version history. We debated this too, but felt that it was important to keep Editor access to page history.

[Paul_Danyliuk]

@Mitchell_Wells

I would prefer they restrict setting up automations

I thought that was already the case, oh wow. TIL.

Anyway, I think automations only stayed unlocked because editors could bring in templates (and templates could have automations). If the ability to add templates will be taken from editors, so will the automations. It really doesn’t make sense to keep them in the editor access level then.

[Cristobal_Alarcon]

Oh, amazing! I run my business as a solopreneur with Notion, and it got somewhat slow with my recent formulas and projects. I thought of jumping to Coda because of the seemingly more powerful formulas. However the docs limits where the deal breaker, it was such a let down. This new change sounds amazing! Thank you so much for considering us. I’ll get back to learning Coda for testing, and, if it performs well, migration.