I’m curious what to-do list would be exceeding 1,000 rows 
@nathan Thank you very for the clarifications 
!
Thanks for the quick and thoughtful response, Jeremy. My template has more than 50 elements (it contains various tools/calculators, even though many get used only on occasion), so that alone is a paid feature. To complete the picture, it does not use packs at the moment and copies won’t reach more than 1000 rows very quickly (although I anticipate many will in a few months time).
And yes, I agree about that particular weakness of the model. My clients too would only be required to push a few buttons and add certain rows every week; as a matter of fact I generally would prefer it if that’s the only thing they could do (i.e. not mess up the architecture/layout).
Congats with Coda 2.0
Next to all comments shared so far, I would like to take the opportunity to address the following:
- I don’t see a reference model offered, having in mind that the users that have experience with Coda are able to on board new users / clients
- I don’t know in other parts of the world, also private users have to pay the Value Added Tax (VAT) on top of the bill. In my region it means +20%. Companies can get this money back.
- For the docs I created to support colleagues in this community, I will be charged to use them, because of their size? Does this mean that I will need to create for every case a separate doc and get lost? `Hopeful you will consider to create a folder “free tier” for further support this community! It’s the way around also valid, all the members that have been giving me a helping hand, might…
Please consider a free tier with sponsored content, as I understand as no other, you will need to make $$$$ to keep the 
burning and satisfy the VC’s 
For the pricing structure and the benefits offered for each tier, I will need some more time to come with “Non emotional” , but grounded feedback!
8 Likes
Thanks for this feedback, Stefan. I’d like to hear more about your team needs so we can hopefully find a solution that works. I just sent an email through Intercom to follow up directly.
Easy example: My daily action list routinely includes 9 habits, 2 workouts, every meeting on my calendar, and every to-do on my work task list, not to mention critical due dates and milestones throughout the month. It’s the One List to Rule Them All. Oh, and I integrated it with a time tracker. Gets to 1000 rows pretty quickly…
2 Likes
I would also agree with a limited editor role. I created a check yourself In and Out doc trying to replace our ancient magnetic slide your button to in or out with a few columns to say where you have gone and when you will return using a dry erase board. So all of our staff would just need to push the buttons to check themselves in or out and update their time of return, date of return, and where they have gone. Having to pay for an editor role just to update their In and Out status seems like a lot. I would be fine if it was restricted to them only being able to edit their own information or not being able to add any more rows or only edit a limited number of columns or rows.
1 Like
Hey Codans, how about this suggestion: instead of setting up a limit on 1000 rows per doc stored, introduce a limit on the number of new rows per day/month (per doc or universally). Or the number of edits.
AFAIK storage is cheap, computations are not.
2 Likes
@Paul_Danyliuk Satisfactory band-aid to a larger problem, but would make things more palpable.
I think I posted my ideal pricing model suggestions somewhere in the community long ago. The idea was Robin Hoodish: keep Coda free for individual makers and small teams, and compensate by charging mid- and large businesses more (since they can afford paying an extra). This would be achieved by making only those features paid that are important to enterprise uses: locking, permissions, perhaps cross-doc (because free users still have Zapier to simulate cross-doc, just not as convenient), longer history, premium packs etc. And small teams and individual users can live well without permissions or, say, Slack integration. The number of rows or elements should have never been a limiting factor.
6 Likes
I’ve been in love with Coda since Day 1. The support has been amazing, the features are great and the possibilities endless (literally). We all knew a pricing model was coming, but I must say this is not ideal.
The first thing I don’t understand is the size limitation on the free plan. I get that this is a model used by Notion and others, but this will be a big turnoff for our clients. We built docs to manage every aspect of their life, and those docs can get big really fast. Most of them are over the limit without any rows. Having to tell them: Look, we built this great system that comes with our training, it’s like a google sheet on steroids, but you’ll have to pay 240$ a year for it. - Is far from ideal
PLUS
it this case, they would have to upgrade to a team account to get features like Gmail, Calendar and cross-doc, which also doesn’t make sense since they are realtors (usually a team of 1-3, not 7+).
Then, I’m not sure to understand the difference between a guest editor and a doc maker. Sure, one can create docs, but that’s it. We have dozens of VA’s working in our docs. This will get pretty expensive for just pushing buttons and checkboxes.
I agree a lot with @Paul_Danyliuk:
I think I posted my ideal pricing model suggestions somewhere in the community long ago. The idea was Robin Hoodish: keep Coda free for individual makers and small teams, and compensate by charging mid- and large businesses more (since they can afford paying an extra). This would be achieved by making only those features paid that are important to enterprise uses: locking, permissions, perhaps cross-doc (because free users still have Zapier to simulate cross-doc, just not as convenient), longer history, premium packs etc. And small teams and individual users can live well without permissions or, say, Slack integration. The number of rows or elements should have never been a limiting factor.
3 Likes
This really seems like the perfect pricing model right here. I agree. Editors and creators aren’t really different. The only real difference is that it adds additional processes for someone who wants to edit a doc to go through a specific gatekeeper. Especially seeing as how there isn’t a limit on number of docs and no reason to get “approval” to create a new doc, this is just red tape for the sake of red tape.
@JeremyOlson I saw a couple messages in this thread where you mentioned to reach out if there was a use case for cross-doc that was interesting and prohibited by the team plan. It relates to both this pricing model and the cross-doc functionality.
We are a small internal product incubator within a larger agency. We are the only ones who use Coda, but the “investors” at the parent org need to see the data on a monthly basis. They’re not creating, or even interacting with controls, but they need a rollup across the different products. Below that, we have four people who create and edit docs across two different product teams. Creation is very rare, normally one per month, but if one of us comes up with an idea, we should be able to create a doc and start playing around without asking someone else to just click a button so we can go in and populate it.
Honestly, we would probably use Coda to get around this. Having a seperate doc with a button to notify the maker that we want a new doc to play around in. Again, though, just an extra step.
For $30, we would definitely see value if it included the ability for people on each of those product teams to create a doc. For $12/maker and cross-doc (which we need for parent company reporting), we also see the value. But if three of us were to create a doc for our teams in a given month and our pricing were to go up to $90 for that month, that would be outrageous!
Basically, this is alpha pricing that is unpredictable and creates processes for the sake of creating processes.
I definitely agree with you arguments.
In my previous company I would definitely have used the pro plan and made a good use of the free editors per doc maker - but crossdoc or locking is a must for many use case and a bit of a no go for me at 120$/y
Right now, as a freelance, I want to keep using coda for free for some time, but the 50 blocks and 1000 rows limits seems too small for some of my usage…
4 Likes
@Paul_Danyliuk - Let’s be clear: Zapier is not an alternative to Cross Docs. I say this as someone who already relies on Zapier heavily in my Coda use. Zapier is about automation, and duplicates Coda’s automation functionality. But if you are trying to avoid duplicating data in multiple Coda Docs (for a wide variety of use cases) and are worried about data integrity, Zapier isn’t a Cross-Docs alternative. Second, why pay Zapier when you are already paying Coda? One of the justifications that Codans are offering is that Coda allows you to eliminate other paid apps. Cross-Docs functionality is critical to some of us who are obvious candidates for the Pro level plan but not the Team level offering.
2 Likes
I am not advocating for using Zapier instead of cross-doc. It was a workaround I implemented for one of my clients when cross-doc wasn’t even in the public beta (actually what I did was even more complicated: it was 2-way sync Coda <-> MySQL, and separately Coda-triggered sync down MySQL -> individual docs).
I’m just saying that I don’t see a problem with making new features paid from the start (like it’s with cross-doc), as opposed to making paid what was already free, and there was no talk of it ever getting paid. Folks who were using Coda for free and didn’t have cross-doc would just continue using whatever they were using before in place of cross-doc. It’s a convenience feature, not an essential. Hence it’s ok that it is paid.
That said, I still very much disagree that it’s only available for Teams plan and not Pro plan.
I’d disagree though that Zapier duplicates Coda’s automation functionality. Coda automations are limited to what’s going on within a doc, plus some pack actions. Zapier is much more flexible and connects many more apps together. I say this as someone who worked for a client whose all dataflows were supported by nothing but 100+ zaps 
In fact, automations and Zapier/Integromat/alike complement each other.
Ok, I found pricing complex too.
I am now at free tier.
- Why there are unlimited doc makers and unlimited editors in free, but limited in other tiers?
- Github pack says that I should update manually at free tier, but there is still “Sync daily” option. Why?
- Locking is nice, but how can I hide some sections from viewers entirely? Many sections contain team-private information, it is not enough to just disable edit for viewers, they should not see information inside.
- What will happen to my oversized doc after Dec 1 ?
- Why does section count as object, even empty one? Most of my docs have structure “one section - one table”, so tables count twice and doc faster reaches limit. Do you force me to use some inelegant and messy structure (all tables in one section) with no profit for you in terms of my data consumption and calculation cost for my doc?
- I created a doc which I help community with. Some hints and answers to questions on this forum. A dozen of people asked me to give them editor permissions and I did. Should I now delete all these community members and lock for them ability to test my answers on their questions because of editors limit?
- Why there is still large annoying blinking cursor at the right of tables even in centered mode?
- Why there is still no dates localization?
- Have you solved main problem with formulas?
5 Likes
Hi Juan, Guest Editors will be charged as Editors in our pricing plan. The good news is that we support a set of free Editors for every Doc Maker that you pay for. We are hopeful that this will balance out pricing as you grow your team. If those Guest Editors are no longer needed I would recommend removing them. You can also move to to Guest Viewer if you still wanted to give them access to view/comment the docs that are shared with them. Guest Viewers are always free. Hope that helps! Jaime
Well the “done” ones stay on there. I could create a rule to automatically delete them after a month, I suppose. It’s a combination to-do list and project management.
Congrats on the update - you guys are going huge! Thanks a lot for the credits and recognition as community member.
Agree with the general sentiment here that the pricing curve is too steep for freelancers or small businesses that have very few makers but lots of client interactions. Good to see you’re open to rethink this use case.
8 Likes
I posted this on the blog post but this thread seems to be getting more traction and correspondence.
As a new, small video game studio, this pricing model will negatively impact us. The “Team” tier fits our business needs, which is $30 per “Maker”. We have a team of 10 right now so we could fit everyone under two Makers, but we then would shifted the responsibility for all documents to be made by only two people. That’s a crushing burden for those two people.
On small teams, people wear many hats typically. Most of our people will need to make their own documents. All from very different disciplines, art, programming, QA, production, HR, etc… This pricing model essentially prices us into $30 per person. When alternatives are available at much more reasonable rates, we’re being priced out.
It’s disheartening because today was the day I was set to roll out our Coda plans to the team and now I’m having to rethink what our solution is going to be. I don’t want to rethink it, I like your product. But this model hamstrings small teams like ours.
I do appreciate the attempt to try a new pricing model. It just doesn’t make sense for us. I hope you reconsider your pricing strategy for smaller teams.
10 Likes