This topic is open for any feedback that doesn’t fit in the following particular use-cases. If it fits better in a use-case below, please use that topic instead.
3 Likes
I will add my thoughts/suggestions later but for now I just want to express my appreciation for your response to this matter and for taking the community feedback to your consideration.
2 Likes
Here’s a piece of general feedback. It kinda reiterates what I said before, just in a more expanded manner.
Coda is what I call “a lovable product.” People choose it over competitors not because it’s more capable, but primarily because they love the aura around the product. They love how it’s packaged, how updates are communicated, and how developers value the community. I happened to make a lovable product myself a year ago, so I know how it is from both sides.
What you’re doing with your current pricing model, I believe, is slap your users in a face. And the more devoted they were, the harder is the slap. Because of the free tier limits, people who invested into building in Coda the most are now switch-and-baited the hardest.
What did I do with my app when I failed to monetize it sufficiently? Did I start charging my free users? Nope, I started doing Coda consulting to make a living. And though I’m failing my users by not providing them with updates, at least I know that I’m not betraying their expectations regarding the features that they can keep on using.
This may sound overly sentimental, i.e. you don’t really monetize love. But having everyone pissed off about the product isn’t going to help either. Word of mouth is a pretty powerful thing, and betraying users’ expectations once means soon no one would trust you anymore. When you launched crossdoc beta, you did set expectations that it would be a paid feature, so that’s fine. But regarding doc limits, you never did.
FWIW, if I were only using Coda for personal stuff and fooling around, and weren’t doing this consulting business of mine, I’d most probably give up on it, in spite.
5 Likes
I can’t say I wasn’t disappointed when I had to pony up and pay after using Coda for free for these last several months. However, I knew I would have to pay eventually. Plus, I know if it stayed free, it wouldn’t be around for long. I love Coda and am totally willing to pay for it (I subscribed to the Pro plan already) because I want the developers to get paid for their idea and hard work and be profitable enough to make it even better.
One thing that would help me and possibly other Coda users is that as I build my apps out more, I intend to have more ‘casual’ users. I don’t want to pay for an editor in order to have a client fill out a form once or upload data once (or even once a month). Maybe there is a way to do something like that now that I am not aware of. But if not, a pack or some other way to address casual use without paying for a lot of editors would be great. Otherwise, I will have to change my app design going forward.
For example, I am building a Coda app for our local rock club. The treasurer definitely needs editor access. Members only need to view the membership list and probably nothing else. If the secretary takes meeting minutes inside Coda, then she needs to be an editor too. But the field trip chair and the presentation coordinator only need to fill out details and upload a photo to Coda so that the Facebook manager and newsletter editor both have access to the information. These are only monthly functions so I don’t want to pay for 2 extra editors. That means we’re back to emailing the data to 2 parties without using a form to make sure no data is left out. OR, I would have to dedicate one editor to be the recipient of the data and input it for both parties. But that rather defeats the purpose of using Coda for ease and efficiency.
Another example is that I would like to be able to have clients contribute copy and images to me with the data points requested. I know you have guest editors (which I haven’t tested yet), but it sounds like I would have to not only add a client as a guest editor before they could fill in their data, but I would have to actively monitor their completion in order to remove them again to make that guest editor space available to a new client. Again, this defeats ease and efficiency. Although again, I have not tested this function yet so maybe I am mistaken about how it works.
Would it be possible to have unlimited guest editors (even anonymous ones if permissions are not needed) but limit the access instead? In the example of our rock club, we wouldn’t need more than 10–20 guest edits per month. Even if we did a one-time survey of each club member, that would be less than 100 guest edits per month. This would relieve the requirement of deleting guest editors to make room to add new ones. Even better would be the ability to add additional guest edits when needed. I could see us needing this during our rock show where we have 2000 customers enter a free drawing that requires they answer some survey questions. If we had a limit of 100–500 guest edits per month, we could bump that up to 2000–2500 that month to accommodate our once a year influx.
This idea is similar to my web hosting account at SiteGround. They have an autoscale option that, if turned on, automatically bumps up my CPU or RAM if there is a significant increase in resources on my server so that visitors don’t experience a non-responsive server. I have already agreed in advance that if an autoscale is necessary, that the fee is $___. There’s no surprise on my end and it only happens a few times a year. The next month the autoscale goes away and I’m back to my original fee — unless I decide that is my new ‘normal’ in which case I can make it permanent.
Well, that’s just an idea of what might work for both my business and my club. I look forward to seeing everyone else’s ideas.
3 Likes
@BenLee Okay, I want to apologize here. My message above was harsh and unjust, more emotional than constructive. I had a pretty bad day, and didn’t know any better than to put it out on codans here. Sorry for that.
First, I want to say that I truly want to support Coda and don’t mind paying for the product. As a casual user I wouldn’t mind paying, say, $6/mo for it for my personal use (a comparable cost to GSuite). Shame to admit, but I’m not really using much of Coda in my own life. I’ve been thinking of doing more actual stuff on Coda for myself (e.g. make a “Life doc” where I’d track all my expenses, utility bills, cleaning schedule etc since I moved out), but I never got around to that. So with that in mind, I wouldn’t probably pay more than $6/mo at this point — this is the price for the knowledge that whenever I decide to build something on Coda, I would be able to start right away without worrying about limitations.
Then, if the Life Doc would bring me a lot of value (i.e. help me get my life more organized), I wouldn’t mind paying more.
However, since my sole business (Coda consulting) is, well, related to Coda, I’m actually okay with paying an extra right away, just for the ability to explore all the features. $30/mo still sounds like a stretch to me, but put into perspective of “what I pay vs what I earn”, this could be manageable. Again, we’re just talking about 1 user here.
My point is this. I think Coda pricing should not be based around row/element/pack/automation limits or whatever. The existence of limits itself is what would scare people off. Personally, I wouldn’t want to invest much time into learning the product if I know that I’m going to hit a limit eventually. Or, actually, I wouldn’t be so eager to do more stuff with the product, knowing that the more stuff I do, the sooner I reach the limit. I mean, 1000 rows is okay perhaps, but 50 elements (which include canvas formulas, views, and sections) is just too little, and something that I’d hit after just a few hours of playing around with Coda.
This said, here’s what I’m thinking about an ideal free tier:
- A 30-day unlimited trial. A user shouldn’t feel limited in what they can do to learn the platform. And time limit gives them specific expectation of when the “free” ends, not making them worry that they build too little or too much.
- Optionally, allow extending the free unlimited use for a) referrals, and b) community answers. This would provide incentive for the users to 1) learn Coda faster and be able to help others faster, 2) improve the culture around Coda.
- After the trial ends, then fall back to a free limited tier.
- And yeah, a cheaper Starter (or Solo/Duo) plan could also help.
This all said, I still believe that all existing users shall be 100% grandfathered, not with finite credits but with the possibility to continue using Coda for lifetime on the same terms they were using it before. Instead of trying to monetize on existing users who had already invested time into Coda (and scaring most of them off, as lots of recent feedback indicates), rather think on how to make the best use of the newcoming users, including getting them involved in the community. Think of your existing users that you’re going to grandfather as the people who’d support you on Product Hunt on your next launch, retweet, help newcomers in the community, and submit tips and tricks. You don’t want to lose them, do you? This is the crowd that ensures that new users see there’s life around Coda — you don’t want to look like everyone abandoned it. And think of the grandfathering loss-of-profit as the cost @shishir and co. must pay for the decision to not come up with the pricing from the very start.
Let all existing users have one unlimited workspace for free for lifetime, with the set of features that was available just before 2.0 (no cross-doc, no permissions and locking, unlimited collaborators, unlimited rows and elements per doc, unlimited pack uses and automations). Then if they wish they can either upgrade it to a paid one to get cross-doc and locking/permissions, or make new workspaces now following the new pricing, but keep that free unlimited one as long as they wish. This would already take most of the disappointment away. Next, think of how to accommodate for all those “few makers — lots of light editors that only click buttons and fill in little data time to time” scenarios.
I understand that startups are business. That you were aiming for traction at any cost, for rapid adoption thus undercutting prices. By startup means, it’s understandable and totally logical that you now want to convert that adoption into revenue. But with all recent feedback, please do evaluate whether you’ll not lose it all with this bold pricing move; whether enough people would stay with Coda for its ecosystem to not deteriorate.
4 Likes
Dear @Paul_Danyliuk, I second your vision.
None of the business owners (SME), I introduced to Coda are interested to continue with Coda, sad enough, and now I’m extremely busy to create new tools at other saas applications.
To be honest, I can understand their decision as Coda has still quite a lot of unsolved points, having in mind simple things like number notation with “,” (comma), day/month names in other languages etc.
As ambassador of “Coda”, I have mixed feelings on the direction Coda goes.
- Obvious for me it’s the tool with the best perspective for the future and my loyalty is big because of both the application and the community have created a new perspective in my life that creates many new opportunities.
- The transition to the paid plans, caused the companies to move, not because of the money, but because of the not clear direction.
- I don’t need to explain, that in business there are so many dynamics, that the tools used should deliver a stable outcome. That is a part of my promise, when I implement a solution with a tool like Coda, both management and staff need to see the benefits.
- For the time being, I expect to go in the pro_plan, just for private use, personal development and support others. Although I received some credits, my thoughts are in line with the suggestion of @Paul_Danyliuk
Amicable,
Jean Pierre
4 Likes
Thank you @Cari_Adamek for the detailed use-cases and where the current model falls short.
Thank you @Paul_Danyliuk for the insight on limits and how this influences reactions to sign up or not sign up. As well as how it may negatively affect a new member’s ability to learn Coda and see what it can do.
Thank you @Jean_Pierre_Traets for putting things in perspective and showing that even though you love working in Coda, it might not be an easy fit for others with the current pricing setup and approach.
This is all constructive and very valid feedback. Thank you all for taking the time to write this up.
3 Likes
Surely we all appreciate the great work done at Coda and for seeking everyone’s opinion. Shows respect and is respected. Thank you!
I am not in great condition lately and can’t contribute as much as I would like to on the topic. Coda has had quite some valuable feedback already and I am just hoping that you would listen to it to find an appropriate update on the pricing model ASAP because we are not purchasing anything until we have those concerns addressed, neither will any of the contacts from all over which I introduced to Coda and seek my advice on the purchase. We simply need a proper statement ASAP because my best advice at the moment is don’t buy it as Coda has some major flows with complex calculations, handling big data files, mobile experience and google-only access and it’s current pricing is just not helping in convincing.
1 Like