So I have been playing around with coda and I love the tool but I am running into a few of the issues referenced by power users like @Paul_Danyliuk @Bill_French and others have referenced in the community previously. I actually read through the Why would you NOT try to manage all a Tech Start-Up’s stuff in Coda? thread and it still left me wondering if it is possible to make things work for anything that will exceed a small task management doc or wiki in coda.
Specifically I have been working on a watered-down CRM doc and hit the hard limits of doc size when I imported some prospect data into my doc (20,000 rows) where the doc just stopped working on mobile entirely and struggled in the browser. I recognized that I had some inefficiencies in my doc filters, formulas, and structure (buttons are so useful but seem to be resource hogs). I figured I would take a second look at everything and start fresh but I find myself mentally running into a bit of a brick wall trying to plan out how to most efficiently design a doc with all of the constraints I am now aware of - at the end of the day it may not even be possible using coda which would be a big bummer. I guess I am struggling with a few of the following conundrums:
- If the doc size is too large it can be split into smaller docs - but if data within the doc is dependent on other tables, splitting the doc would create another issue with the inefficiencies and limitations from cross-doc.
- Was using a search table to filter a view by user, but that leads to a couple of inefficiencies with formulas - but if new views are added instead of a search table then the doc size increased even more.
- Interactive control filters are WAY inefficient - my search table and filter formulas would take less than 30 seconds to calculate and show results where an interactive control filter would take 2 minutes on the same 5,000 records?
- I also did the same math that other have - if I have 5 employees entering 40 notes a day that will add up to 48,000 records by the end of one year and that by itself will probably break coda (ok so you archive some of the notes after a while, but still it seems like it would very quickly break down from moderate usage)
To me this seems to be Coda’s biggest opportunity and flaw - there really should be a way to handle more data in these docs. I understand some of the under-the-hood aspects of coda thanks to Paul’s extensive research and very helpful posts on the community, but I guess I am still really surprised that this isn’t priority #1 for the company. I feel like these docs need to be more efficiently handled by coda.io - and yes good design will still come into play but when you talk about companies using something like this you are bound to hit a lot of these hard limits very quickly.
Does anyone have any solutions to these issues that still leverage coda.io? Are there any ways to split docs with data dependencies and avoid inefficiencies? Does anyone else here scratch their head when they see cross-doc and wonder if it is even worth it to use (I personally laugh every time I look into it and try to find an efficient use)?