I think the model seems fair for teams. One thing I’ve been thinking of is that the free version is very limiting, which I think will hinder adoption. When I recommend coda to people I know it is a lot of the time due to the packs that are in pro and teams tiers, and if it costs money to try those out in a new doc people might not try it out.
One thing I would like to see is every new doc can use every feature possible the first two weeks or so to make it possible to try things out before committing and start to pay for it.
2 Likes
Our pricing page mostly shows the tier that gives you full access to Packs.
Many of them actually have a free version with limits on actions or how frequently your sync will refresh. It’s much easier to see in the in doc pack gallery
For example Gmail in the free tier is limited to 20 actions (like sending an email) and only manual syncing (as opposed to automated syncing in the pro tier)
1 Like
For us at work the worst problem with the pricing is, that editor counts as 1/2 of a maker. And since the biggest advantage of Coda is making interactive “apps” that people interact with (edit), for such use there are virtually zero viewers that are not also an editor.
So what was originally a nice combination of Wiki and a simple tool (let’s say a simple Trello) can become unproportionally expensive tool that no longer makes sense to use. That would of course be totally okay had such a pricing model been teased or hinted at.
If I started now, I’d never even use Coda for such a use case given this pricing model and be okay with it. Now I just may have to migrate our data elsewhere if I don’t manage to strip it down all the way down to the Free limitations. Annoying, yes, but hopefully manageable.
And don’t get me wrong, I love what Coda can do. It’s just that given the pricing, some use-cases are no longer worth it. Which is sad for the early adopters who already established such use-cases.
4 Likes
@Tomas_Bachtik this is the same scenario for us.
1 Like
Howdy!
Avid user and advocate here. I’ve used Coda across various orgs and have always been a huge fan (even after we accidentally crashed your Zapier integration and our doc got cut-off). I gotta admit, though, that I’m disappointed by the pricing model.
tl;dr here’s my suggested pricing model:
- You have: Viewers, Editors, and Builders.
- Editors have Free Tier abilities. That means they can (a) create docs and (b) edit any doc that is below the Free Tier size threshold.
- When a doc passes the Free Tier threshold it gets locked and can only be structurally modified by Builders. That means:
- Only Builders can change text, add / remove columns, change formulas, etc.
- Notably, Editors should still be able to use controls to fire triggers and add / remove table data. In other words, Editors should still be able to use the apps, just not edit them.
Why is this better? Because everyone can still benefit from what’s great about Coda! Coda’s all about lowering the barrier to creating powerful apps. You want to encourage all people to build expertise and construct more and more sophisticated documents to really entrench yourself in the organization. As regular folks become Coda experts, they’ll end up upgrading to Builder seats.
Now for monthly pricing:
- Free Tier stays the same.
- Pro plan: greater of $30 or $2.50/editor and $5/builder
- Team plan: greater of $100 or $5/editor and $10/builder
Viewers are always free. Guests are always free. You want to encourage the sharing of the product. Do what 1Password and Slack do and limit the number of documents within a workspace that a guest is eligible to access. If a guest has access to more than 3 documents they need to become a paid editor.
My context:
- Coda serves two primary purposes for us:
- It’s a collaborative document space and wiki a la Hackpad / Paper, Quip, etc.
- It’s a low-code app creator a la FileMaker, FastField, etc.
- Our users fall into these categories:
- Viewer: a person who is purely consuming content
- Wiki Editor: a person who is creating, editing, and maintaining simple wiki-like documents
- App User: a person who interfaces with a Coda App using form controls
- App Builder: a person who makes the big, powerful apps
- As a result, our documents fall into these categories:
- Lightweight text and a few tables with no real automations
- Apps that are table heavy, more relational, and use triggers / automations
My thoughts:
- The current pricing model hinders bottom-up skill building and innovation, and as a result, discourages platform adoption.
- The distinction between user types is silly:
- A builder can create a hundred empty documents in a folder that any of the editors can come in and move, rename, and completely modify. If that’s the case, then what’s the real distinction between them?
- Why on earth should I be charged the full cost for a guest editor that has access to a single document? Again, this stifles sharing which hinders platform adoption.
- Not all editors are created equal. Look at Airtable — they distinguish between people who have full access to the base and folks that are just entering data into the form view with good reason.
The “Split into two workspaces” recommendation on the Keep Costs Low page is an indicator of the fundamental problem with this design. You shouldn’t have to split your team as a requirement of a tool being affordable. For example:
- Organizations want to have a folder hierarchy to keep documents organized.
- I want anyone in my organization to make a wiki-like document that fits neatly within the Free Tier criteria, but I don’t want to pay for that user to be a Builder.
- So as a result I create two workspaces: one for “Paid” and one for “Free” and both hav the same folder hierarchy.
- Now we have a document organization nightmare — which workspace was that Sales document in? Did it get to big and get moved? Are all the users in both workspaces?
It’s crazy that a given user’s abilities in a Free Tier workspace exceed their abilities in a Paid Tier workspace. It’s crazy that there are cases where if I reduce the number of Doc Makers my price actually goes up. This can’t be the optimal solution.
Further, there’s the use-case of having a Coda table where you need lots of people to contribute. Let’s say you’re hiring a mechanical turk team to do some data entry, or have a survey you want to distribute, managing that becomes a nightmare.
And every company has to collaborate with outsiders from time to time. That sharing is valuable — it’ll drive Coda’s adoption! Making someone think about the cost of sharing is friction you don’t want to introduce. And if you add someone for a single document and forget to remove them, you’re going to kick yourself in the butt and be angry at Coda when you discover you’ve been paying for that guest on one document a year later.
I really encourage you to reconsider your pricing structure. As it stands it leaves a lot to be desired and has negative effects on the adoption of what is otherwise a great tool.
6 Likes
This is probably the single best assessment and case-in-point for reconsidering the pricing model.
4 Likes
In my opinion, the pricing structure in Coda right now is quite unique and very practical. Some of the use cases above (e.g. making a wiki which can be edited by editors) seem to be addressed/can be addressed through the locking features introduced in the last few last months. Personally for me I love this pricing structure. It goes well with how people actually use coda - doc makers and editors/guests.
What I’d like to see in the future is introducing custom user roles, and attaching custom permissions/locking based on user roles. Or basically more user permission granularity
3 Likes
