April 2020 - Project Management Status

Hi all,

I know there are similar threads to this but I feel it is worth a new post since Coda continues to evolve and grow with new features.

We have been using Coda for relatively light project management with small 2-4 person teams, for the last couple months. We have a setup containing personal work view, Milestone/Objective/Item tracking, weekly sprints, and a master “All Tasks” doc that uses cross doc to pull in tasks across projects.

So far we really like the streamlined workflows compared to bigger PM software that have a lot of bloat or locked out higher-tier features.

I’m considering adding in original time estimates, multiple actual time-spent entries per item, and corresponding views for different types of reporting and projection.

I know there have been users here that have put significant effort into this over the last year, and have experience with a lot of other PM popular products like Wrike, Asana, Jira or Clickup. There have been big improvements to Coda in areas like permissions, sharing and accounts in that time frame.

If you can share your current take on Coda’s use as a standalone replacement of those types of tools for more detailed Project Management with 5-30 team members, and thousands of tasks, it would be really helpful and appreciated! Are there critical aspects of Coda in 2020, like performance, that make it a difficult choice? Or features that those other products offer out-of-the box that make the time spent in Coda not worth it?

@Paul_Danyliuk and @ABp I’m especially interested in your feedback if you have any since I have seen some of the impressive implementations and ideas you have discussed around this. :slight_smile:

Thank you


Thanks for the mention, Ed!

A super concise but also super eye-opening answer is this:
Coda is a doc.

If you decide to use Coda for your project management, that’s exactly what you’re agreeing to — managing your project in a doc, with all the drawbacks:

  • It’s all nothing but one file (two actually, but whatever).
  • It doesn’t scale like a regular database would. 125 megabytes is your hard limit at which APIs such as Cross-doc cannot read from this doc anymore. The doc is not sharded, you’re always loading the whole of it. Your browser recalculates the whole of it.
  • There’s no real permission system on doc content level. Everyone who has permission to view the file can see all the file. I don’t think this one is easy to overcome, so I wouldn’t expect Coda to change this in any near future.

On the other hand, Coda has a build-it-yourself approach that lets you make virtually any custom workflows, unlike ready solutions like Jira or Asana that are flexible only to some extent, often at a premium (plugins etc).

If you’re considering between Trello and Coda, Asana and Coda, or Sheets and Coda, then going forward with Coda is practically a no-brainer. Just always keep in mind that you’re tracking all your stuff in a doc. But if you’re looking for something scalable, then choosing a dedicated SaaS for that could be a better investment.


Hi Paul, Thank you! That’s a great perspective of viewing it as a single document solution, especially with those specific implementation considerations.

I agree I think at higher scales Coda is a difficult choice. Oh it’s really tempting me to use it for more and more though. My issue with Jira is that I find the user interface frustrating to the point of becoming an obstruction to implementing process, and then I often need to export to generate reports anyway.

Regarding the browser recalculating the whole of it - is that on opening the doc? All underlying tables are loaded and calculated?

Have you any experience with some of the more modern apps like Clickup, Wrike?

What I said was a simplification. Here’s a more detailed breakdown:

  1. A coda doc file is a big JSON, hence your browser parses all of it.
  2. Individual rows are stored as JSON+flat buffers in a base64-encoded form. I guess your browser only decodes and parses those encoded rows when it actually needs to access them; parsing all rows eagerly would be a waste, I imagine.
  3. Input values are stored as is.
  4. Formula-calculated values — depends on a formula. There are volatile and non-volatile formulas. Volatile formulas are those that depend on either current time (Now(), Today()) or current user (User()), either directly or through a dependency graph (i.e. formulas that depend on columns, which depend on columns, which has User() in its formula). Non-volatile formulas have their last calculated value captured and just show that. They are invalidated and recalculated only if something in their dependency graph is invalidated. Volatile formulas don’t capture their values: they are recalculated every time you open your browser (if that’s dependent on User()), and also every ~second if they depend on Now().