Why would you NOT try to manage all a Tech Start-Up's stuff in Coda?

Let’s revisit this assertion because I cannot recall anytime this has happened with Coda and I have some client tables that exceed far more than 1,000 records. What is the original source of this claim?

I’ve also updated my initial comment to better outline that I personally have not run up against any hard-measurable limit. (Mostly soft throttling that I have not been able to pin down to specific hard limits, but which seem to be in the same order of magnitute (<1k rows) for automated operations)

@GJ_Roelofs:

it looks like the performance issue is rather fundamental and not easily solvable.

This is what I want to know. Are the performance characteristics we are seeing a result of a race to provide some initial featureset via a solid architecture while putting performance on the backburner? Or does the architecture have fundamental problems that make reaching performance targets for the use cases @GJ_Roelofs and I are talking about out of reach in the short to medium term.

The Year of the Maker Coda team doc has performance as number 2 voted issue. I would love to see a 1 (or 2!) month sprint by Coda focusing strictly on performance and bugfixes. I think if the reason is the former, than we will all be super happy and Coda’s adoption rate will see a nice bump.

3 Likes

In my opinion, this is a flawed claim at best. While I certainly believe @Johg_Ananda experienced this error, I also believe it was entirely avoidable.

Recall my reaction to this [alleged] limitation here. I’ll summarize by saying that (a) Zapier is not kind to APIs, and (b) Zapier must look at every record to determine when absolutely nothing has changed.

I don’t think it’s fair to hang an assessment on a conclusion about Coda’s API that is fundamentally based on the results of a likely bad actor (i.e., Zapier). Codeless integration tools are generally heavy-handed and unaware of discrete knowledge about the data in the integrated system. And let’s be rational about this - the Coda API is Beta 1.

If you want to create sound API-based solutions and you are building a commercial-grade application, the last thing you should be doing is using a glue factory to wire it all together. Adhesive tools like this are fine for prototyping a solution or using in limited and personal projects, but it is very risky to bank on them.

Making it Better

I hate to bitch about something and not offer alternative approaches, so here’s how I program interfaces with the Coda API knowing it is Beta 1 and performance is probably at issue -

  1. Use queries - retrieving records with filters is a must; you cannot optimize without them.

  2. Use visibleOnly - find ways to hide records that aren’t relevant; it has a positive impact on performance.

  3. Pace your processes - chunkify the process over many hours to lessen the calls.

  4. Use views - instead of reading from tables, read from deeply optimized views. This was mentioned in the Maker webinar but I’m not sure this is released yet - will test later this week but the idea is simple - instead of a table, integrate via a view that vastly limits the activity.

  5. Use PUT - sustain discrete record IDs in the middle-tier so you can instantly update any item in Coda without performing repeated GETs just to find that which you want to update.

4 Likes

@GJ_Roelofs, really great commentary in here.

So I’m forced to ask - what else have you considered besides Coda? One alternative I was looking at is a new tool, Fibery. They have a great approach, loaded with potential, but very fledgling.

I am essentially trying to replace most of the tools that I listed at the top of this thread, I believe based on your posts that I’ve read that you have a similar goal. Most of these tools are based on some sort of db or another, and if I can do stuff like product plan, as well as manage tasks, in one place, I certainly want to accomplish that!

You raise great points - I too dread Cross Doc. In fact, to get back to the subject of reciprocal linking, I already am handcuffed with trying to relate all the tables I have, due to the fact that lookups can only handle a one-table to one-table relationship. Unless some expert developer-level formulas are brought into the mix? I’m willing to deal with some stuff that I have in one table that should really be in separate tables, though. But Cross Doc is much less something I’d like to deal with…

My hope in reading all this is that, indeed, Coda will address the Scalability over time. I have the sense, although as you state it’s not clearly published, that they are interested in serving as a Team Hub solution, and not just limiting to “short” projects as you aptly put it. This is interesting in the context of the Template Repository. I think you have here a bunch of great ideas, but they are all isolated, and shouldn’t be. Meeting Notes, but no tasks connected. OKR’s, but no customers or projects closely connected. In fact, there is no real mention of even connecting these docs in the first place. Those type of Coda docs are exactly what I’m not looking for, as they put your team in isolation, having to rely on some other app to track the rest of your data.

And @Bill_French, touche. As usual agree with most of what you say. Interesting to hear about Airtable rich text feature. Can you @mention any entity in a Base like with Coda?

I could make a list comparing Coda to AirTable, but for me, there was no contest as to which is superior for team use. Would you choose AirTable for what I and I think @GJ_Roelofs are looking for? And I believe Air Table still has as a top request the ability to link bases’ data. As much as I fear Cross Doc, I do have confidence in the Coda team on this front. They are the first to admit this is an initial cut, and they did ship it in a matter of months after 1.0. I think AirTable hasn’t addressed their own lack of “cross base” in years.

Finally, I think a big point of hope is your assertion of the “adolescence” of Coda. That is probably something that gives me the greatest confidence in moving forward. I believe that if enough highly skilled Makers continue to flock to Coda, as most of you posting here, they will for sure prioritize this issue of Scalability. In a sense my whole point with this thread is about the potential of Coda. I’m sure many of the Coda team has read a lot of this commentary, and I believe deep down they will take you Power Makers seriously and we will continue to see Scalability addressed at the forefront of the roadmap!

2 Likes

Wow, did this turn into a big topic!

I’ve read and re-read this pretty carefully and wanted to address the concerns that have been brought up so far and I also want to thank everyone here for putting so much time into writing these posts and offering this feedback.

There is a lot of great stuff in here about how Coda allows everyone to build much more than they were able to with other systems, and with much less effort. There is also a very big array of other software that Coda has taken the place of, from as big as fully featured project management systems to smaller meeting notes apps.

The big questions popped up around scalability, doc size, and how to manage various amounts of data. One of the questions is how big of a team or company can Coda be used for. Well, Coda is about 70 employees and we actually run on Coda. We use it everyday in all sorts of capacities. Other companies that use Coda, to extents that might surprise you, are Uber, Spotify, The New York Times, Square, Zapier, and more. These are companies with large engineering, sales, and support teams and they use Coda for a very wide range of things as well. So why do we see posts here saying a few people is too much and companies with 1,000’s of people who happen to be running Coda just fine?

It’s been said here already that it’s pretty rare to have a system so flexible that it can be made into the various solutions we see posted in this community. With that kind of extreme flexibility comes an even more extreme number of permutations in the ways these various features can be put together. If you consider every feature available, and all configurations of formulas, it’s an incalculable number. If you throw in the various permutations of data that can be used in these docs, it actually is infinite.

This unthinkably gigantic number of permutations, from formulas to various types and sizes of data, make estimating how big a doc can become very difficult. There is more to consider than just data size. This isn’t having a flash drive with 500 MB of space and hoping to fill it up to 499 MB while accurately estimating each picture being between 4.6 MB and 5.4 MB. When you have operations to run and require a cache of memory to hold data while those operations are running, you need memory to perform the process. With the nearly wide open formula language that Coda offers, there are some calculations that can take quite a bit of memory while they run. So that same flash drive can’t hold 499 MB of data AND do calculations at the same time.

There are docs with 10,000 rows that run just fine and docs with 1,000 rows that are somewhat slow. Due to the very wide range of data we seen in rows, it’s tough to ballpark when this happens, but if I had to put a range on it for where Coda is at the moment of writing this post, 0 to several thousands, you should be totally fine and thousands to 10,000 you should be efficient with your formulas. 10,000 to 20,000 you should be very efficient with data and formulas for a single doc.

As far as the API goes, the limit is more with doc size than with row number. There is a very small percentage of Coda docs running the API that this affects. So small that I can count them on one hand.

Like was mentioned before, every system can be overloaded. So when you chose a system, you need to design within that systems constraints, and if you want bonus points, play to that systems strengths. Spend some time figuring out what data is necessary and what can be discarded. This will help to streamline your processes as well, so it can be a win win. Then spend some time figuring out how to most effectively display that information so it can be digested quickly and easily.

My Personal Experience with Larger Datasets

At a previous job, I was asked to help out with a data project that ran well over 100,000 rows of data and that would grow by more than that in less than a year. There were enough columns to make the dataset not loadable in any online spreadsheet software (Sheets or Excel). A local install of Excel was required. The ongoing project had taken roughly 10 hours each month to sort and compile the new data entries and even then, it was just a grid of numbers and pivot tables that would hopefully make sense at some point.

After looking over the data and spending far too many hours trying to reverse engineer and clean up a massive spreadsheet, I started to see where some of the problems were. Then I turned to Coda to sort out the solution.

There were simple ways to break down the data into smaller chunks, run what I needed to in Coda, then compile the results into a cumulative results doc. Data split monthly into separate docs, then compiled results from each into a results doc. With this setup, the time the project took each month went from 10 hours down to 15 minutes. That’s 40x faster than the previous large database setup. Not only that, it found previous errors in the system and improved accuracy moving forward. Charts and stats were far more readable which also allowed them to be far more useful.

I didn’t insist on absolutely all data being in one doc AND expecting it to be readily available and usable in a web app. I broke it down into realistic groups and engineered the solution around the strengths of the system I chose to use.

I’m not saying that Coda’s answer is to split docs up and that’s that. I’m saying that where Coda is right now, 100,000 rows of data is not likely to run well. But we are working on performance daily as well as growing the product. If you’re building a house, you can’t paint the walls and clean up the kitchen before they are even built. And while you’re building, you can’t continue to the next task until you cleanup after the first one. Coda is several teams working together building, cleaning, fixing, and repeating on a regular basis over various areas of the product always aiming for continuous improvement and innovation. Thanks to computers, steps aren’t as literal as this metaphore, so where there is overlap with these steps, we try to take full advantage of it to be as efficient as possible.

We’ll keep pressing forward to better the product and improve performance and we hope that you’ll keep testing, using, and pushing Coda in new and creative ways. I’m betting there is going to be a heck of a lot of good stuff in the years to come.

13 Likes

I concur. This is exactly how I segment range of scale and the responsibility that goes along with knowing the boundaries of the underlying solution. Scalability is not a one-sided requirements debate; it involves careful planning and a comprehensive embrace of internal and external limitations.

1 Like

LOL. No.

(more fluff because this platform doesn’t allow me to be concise)

@BenLee the issue is that the constraints aren’t clearly defined. The Coda marketing pages say its unlimited:

And while I agree with the spirit of your post, you failed to address the elephant in the room, which is that a small team of four breaks the API in a few months. This is happening in manifest - this thread is the evidence of it - to small teams and individuals are hitting the limit and getting disconnected from the API with no forwarning or indicator (instead we are told its unlimited):

Its hard for us to square the circle that you have thousands of people from Uber, Spotify, The New York Times, Square, Zapier, and more NOT having any of the issues that us small independents are?

1 Like

Hey good stuff here @Johg_Ananda and I think you are also hitting on potentially my biggest concern area - trying to use Coda where it’s most useful - keep all relevant data in one place for a growing team.

What brought me to Coda is trying to solve having my data in various apps, and trying to keep track of it. One thing I wonder about with users that only use Coda for certain things, like the Uber famous doc here:

…and also, I imagine, the likes of those other institutions you are citing: What are those teams doing for the rest of their work management? In other words, all the people that worked on this Uber doc, what other tools did they have inside Uber that were tracking other parts of their day?

@BenLee really appreciate the explanations, but I think John raises a valid point. Although I think you did answer it partly. I do think you guys should be planning your roadmap in such a way as to accommodate teams trying to solve this problem of proliferation amongst apps by “bringing it all” into Coda. As yet another example, I imagine in your experience at REI, the Coda apps you created were supplemental to a host of other tools used to manage other kinds of tasks company-wide, such as IT team projects, HR, calendar, etc. I can only imagine how much an organization that size was using! What always strikes me is that Coda can handle much of this, so I just feel compelled to try to get it done in Coda! As somebody in charge of this at my organization, it has been a nightmare trying to manage stuff strewn across the suite of apps @John_Scrugham posted earlier in here…

I know this is probably getting self-serving at this point, but I just want to express again that I think you guys should keep stressing, if it isn’t at the top of your list already, building Coda in such a way that a smaller team, such as 4 that John cites, can get into Coda and try to solve all these needs, and also not worry about performance as they grow. You guys yourselves, and your growing team of 70 is probably the best example out there of how to do this. In particular, I think it’s interesting your discussion of the various stalwart companies using Coda. What is the extent of the expansion of that use? How many Squads at Spotify are now on Coda? Although Betterment is tracking some marketing stuff with you guys, is that same marketing team still using Asana or Wrike at scale? Another app, Monday, has in its marketing materials that “WeWork uses Monday.” It turns out 200 people at WeWork use Monday. That can only be on experimental basis given the size of the entire workforce at WeWork, and I don’t think it really counts. I wonder how many of the teams using Coda are still on this more limited scale in isolated use cases. Would be very interested to hear about any larger-scale adoptions you guys could share…

I think it would be great if we could see more from you guys officially about Coda as an “end-to-end” solution. Things like in your Template Library publishing more about your internal CRM that got me started on this thread, with some instructions, so teams can adopt it in the context of the rest of their Coda. Then a start-up can realistically consider skipping Salesforce for $1k/month or more. This actually touches on one of my hangups with Coda: As I make my way through Coda, and look at the great templates you guys have published, I have trouble figuring out how to tie these in to create a full-team implementations on one’s own. You talk about numbers of rows in a table and doc in your post and the impact on performance. I think it would be great if you guys gave more guidelines about best practices around that, but with concrete examples: If you want to use CRM + OKR’s + Meeting Notes + todo tracking, how to structure then? Versus if you just want to use the UX/UI Starter Kit. In my own implementation, I have been stuck for a while with questions around how many tables and how much intra or inter-table hierarchy will work if I want to reference stuff in my Coda freely. This is a more advanced question strictly related to how much a team is trying to solve in Coda. I would love to get some more official guidance from you guys around these types of challenges.

I hope this is useful and thanks for that insight. I continue to be excited about Coda, and more eager than ever to see what you guys have coming up next!

5 Likes

Things keep getting reiterated about how to get everything into Coda, and yes, that would be great, but it also doesn’t necessarily need to be in a single Coda doc. Send me a system name and I’ll send you a use-case that will crash that system. That’s easy, anyone can do it, and no system out there is immune to it. Sitting here insisting that the system should fit that particular use-case that particular way also isn’t getting anything accomplished.

In short, step back, take a breath, and view things at a different angle.

The Uber doc was one big project, and all people involved used it as their source of truth and that’s how the project was run. That’s why we posted it. Other companies have their entire schedules running on Coda, so big stuff is possible when it’s the necessary information.

When things require brainstorming, notes, various meetings that only apply to that particular project, and various lists and resources, break that away from the initial scheduling doc and create a doc specific to that particular project. You can link to it in the original doc. The lets each team run the project the way they need to and gives them freedom to work the way that suits them. Trying to force all this information into one doc doesn’t make sense. So I don’t run into performance issues on a regular basis, only when someone insists on things being in one doc.

4 Likes

@BenLee, thanks for the response.

I think what I’m getting at, and I also get this vibe from @Johg_Ananda and @GJ_Roelofs, is that we are talking about situations when an entire team that is also an entire organization, is trying to run on Coda. I think Coda is suited for this. You speak of a lot of examples of teams that are distinct within an organization. That won’t work for me as I’m not big enough to have a doc that is just for one team inside my company.

I am trying to be able to refer to everything in Coda in a meeting, because that’s how small teams operate. When Co-Founders in a start-up meet, they will talk about vendors, projects, laptop leases, HR, everything. There may be teams that are disciplined enough to only meet about “project x,” and not talk about in that meeting that your real estate agent needs an answer on the new space you’re looking at. But in my experience, this is the nature of small teams. Coda is flexible enough to handle this scenario. What you are suggesting with boxing this activity into one doc for one team reflects exactly what I just referred to about the Coda Template Library. A lot of it is designed with a particular team in mind, a team that might be part of a much larger organization. You guys have had some success clearly here. But these are teams working in Coda in silos. But I think there is huge potential for Coda in a small team actually to handle everything. That’s why I created this post.

I have to say that for all my enthusiasm for Coda, if in the end I have to do some stuff in Coda, and still do other stuff elsewhere, I would probably ultimate move on to a tool that is outwardly offering to be a Single Source. Things like Notion, which is currently inferior to Coda, but also iterating and will have new features soon, or ClickUp, which outwardly wants to do the same. You guys have a superior solution to both of those, and everything else in the market right now. If your Product Team’s intention is to build Coda so that more variety of stuff can be handled better in Cross Doc vs. just one Doc, I wouldn’t have any issue with that, if ultimately Cross Doc can work as seamlessly as two tables in one doc can work now.

I guess in the end it would be nice to have continued clarity from you guys about your intentions towards this use case that is the topic of this thread. I think that’s the reason a lot of the community got involved in the topic, in particular the question of performance when adopting Coda for all-team use. I sense there are a lot of us out there who seek to solve the problem of app proliferation with Coda.

Thanks again for your comment.

6 Likes

Holy hell… I ain’t reading all of it :scream:

One recurring thing I noticed was performance. Yeah, as a software engineer I’d like to have more control over how things get recalculated. I just made a doc for a client (that I was building for the last 3 months) that’s not as much data, as much as it is very complex in nature, with lots of rows being dependent on lots of other rows, and the recalculation complexity well venturing into O(N^3) I believe.

But realistically I know that for challenges like that, programming languages exist. So not really a task for Coda.

2 Likes

For what it’s worth, we upgraded our Workspace and will actively try it for CRM and Company Management as a starter, and have fleshed out PM processes to roll into if those go well.

@BenLee your response was awesome (although I read it after our decision :slight_smile:), and it’s especially enlightening to hear about some of those more specific use cases by big companies. I downloaded the Uber template yesterday and to be honest I wasn’t sure if it was some hot air or really used at some reasonable scale at Uber, no offense, and for a relatively new product like Coda it’s really important to know how much rigor it has been put through.

We will aim to keep our tables clean with very explicit responsibilities and all under filtered views, and to be honest I don’t see any strong need for crazy formulas to accomplish 95% of the types of things we are looking for.

That being said, there are many cases where up to 100,000 rows w/ formulas on them are going to be common (timesheets, financial data) for many small companies, so it’s good to hear you continue to focus on performance there.

3 Likes

@BenLee Thank you for taking the time to comment. As a developer myself with public facing products I know it can be hard to read criticism knowing full well some issues or annoyances could be avoided.

I should be more specific, nuanced and less broad in some of the statements I make.
The problem for me arises when the usage of Coda becomes “advanced”.
I have no doubt that Coda is capable of running 10k row tables if the tables are simple - I’ve tested it - but to me the strength of Coda is its formulas - not to have simple tables.

My goal is to develop a custom application that solves my needs for project management, and solves it well. Otherwise I could just as well do my project management elsewhere - which means I could do my knowledgebase elsewhere.

The strength of Coda for me is to make a solution that works for me and mine.

Per example, my goal was to create a custom project management app inside Coda to replace Jira/Trello + Confluence/A wiki. What attracted me to Coda was that I could, through formula, create all the custom views that were interesting and do so from inside Coda.

To give an example of usage that I would consider essential from a UX perspective, my custom card view:

It shows at a glance the estimate, urgency, type, category, percentage completed and project a task was assigned to. The formula itself, while doing some referencing outside the main Task table, is not doing anything that has excessive running time (no aggregation, lookup outside direct references, etc - i.e.: a constant running time per row that doesn’t increase with table size.).

Changes in status trigger row creation for Morning Review, as well as weekly summaries posted to Slack.

Here an impact matrix for planning a sprint, with a Gantt chart that automatically updates based on the workload assigned to someone - and shows a timeline with tasks ordered by urgency to quickly see if someone has enough work assigned.

Tasks are assigned task templates that try to track how long certain tasks took, in an effort to provide better estimates for upcoming tasks and the ability to recalculate the global planning.

Is it all excessive?

Maybe.

The problem though is that I am looking for the capacity to present my team with a product that can handle serious project management and give us real insight. If I wanted simple project management, there is a plethora of robust tools to chose from.

For my usecase, Coda feels like it isn’t mature enough yet to be that.
UX, performance and not getting the “last mile” right prevent me from using it in this fashion.

A small grab from the bag of UX annoyances that weren’t reported yet:
The hover over preview of rows references was one of the reasons we chose Coda as a knowledge base. However, sometimes it cuts off a single line, and at other times it displays a paragraph.
Even though the cut off line is shorter than the paragraph that was displayed in full - or vice versa.

image

image

The impact matrix (shown earlier) categories jumps in ordering - even though the source table the categories come from are ordered. Refreshing it sometimes ensures that the ordering “becomes correct”.

Rendering of category labels sometimes is done as a text, and properly colored, sometimes as an entity cookie. (See card view)

5 Likes

This is without question a good test of Coda and I thank you for starting this massive missive. :wink:

Everything?

The only problem I have with this idea [generally speaking] is the term “everything” because - well - it’s big. My reaction to broad and sweeping statements like this is simple -

You can’t have everything - where would you put it?

I think I know what you really mean though and I don’t think what you’re suggesting is outside the realm of Coda’s capabilities or necessarily outside the realm of expectations, even in this adolescent stage of the Coda’s lifecycle.

However, just as no startup should ever create a single Excel workbook to manage “everything”, the same applies to Coda. I’m sure we can all agree that this would be nutty thinking.

Breaking this down a bit, would we attempt to break out all of a startup’s activity across multiple Coda apps/documents? Perhaps. Certainly to a degree this is achievable but only given a context and scale, right?

Going a little deeper, Coda isn’t really suited to replace email. Nor is it suited to compensate as a banking platform. It would be silly to use it as a web server for 10,000+ visitors. Video storage and editing for your Kickstarter campaign? Probably a non-starter. Planning your Kickstarter campaign? Definitely a starter.

Startup Lifecycle

There are periods where Coda is vastly more relevant and helpful as a unifying information infrastructure. Is this true with a head-count in excess of 200+ workers? Probably not. As such, the essence of this thread is contextual and across many possible startup attributes.

This is reasonable and sound advice.

I tend to nudge clients in precisely this direction, but not necessarily because it avoids performance issues. Rather, it’s a fundamental tenet of building modularized solutions that are fabricated from multi-use components - indeed, components that the organization may be able to use independently.

Building solutions where key functionalities are designed as distributed components (as opposed to a monolithic architecture) have enduring benefits. Yes, it sometimes creates difficult design and integration challenges, but the added effort invested to avoid all-in-one feature clusters …

  • Allow you to expand functionality over time without invasive new releases;
  • Dramatically lessens regression bugs and rewrites;
  • Improves testing and time-to-functional use;
  • Create additional agility when shaping processes for different roles and stakeholders;
6 Likes

Hey @Bill_French, always glad to see you!

I have been writing free-flow for most of this, apologies as that hasn’t helped the focus of this convo no doubt. But I thought it would be worthwhile to clarify what I meant by starting this thread and talking about “everything” that you allude to here:

What I meant are the tools I’ve found that tend to share common info such as assignees, cross-team projects, company departments, and strategic planning.

It’s the group from the original list I posted:

I will add that re: Version Control tools (what I called “repo mgmt”), what I mean is you can integrate with your tool of choice. Some stuff I’ve looked at, like Teamwork Projects for example, has no integration whatsoever here - I don’t count Zapier when it comes to integrating with Gitlab, Github, Bitbucket.

And re: the final item: Chat - Coda is not a total replacement, but I believe it can accomplish much of what Slack provides to a team. I actually use a Slack alternative, Twist.

100% with you that we are not talking about accounting, invoicing, banking, analytics, and some other stuff that we don’t have even packs for right now.

Bottom line - if I could get all that in one tool, my team’s day-to-day life is tremendously improved. And there are other competitors out there attempting to try to solve, more or less, that list in one app. I would hesitantly put AirTable as one. But nothing I’ve seen yet can do it as well as Coda! And Coda is inherently modular, even within one doc. So I think you avoid much of the growth pains you talk about:

…if you try to use Coda alone for all this. You are building on a common platform. To illustrate the point, would you want to try to integrate all those apps effectively? And to keep it precise, by “effectively” let’s just define that as two-way sync of data across them all. In other words, you’re going to be working exclusively across API’s as few have native integrations with each other. With API’s doing the integration, you will have suspect visibility about the syncing amongst your rank-and-file users. If I hook up Wrike and Aha, I can’t see either of the other app’s info within the user interface, even though I can set up event handling so when you move a linked entity in Wrike, it will transition in Aha. This is the “nightmare” solution I keep referring to that plagues tons of teams right now.

In my mind Coda as a source-of-truth for this stuff wins vs. this “other” API option hands down…

1 Like

Not sure if I missed something - in this thread or in the interpretation of the clauses below …

in considering why NOT to develop a startup, where intellectual property is an asset, (including business model and any other content) does this clause in the Coda Terms of Service not concern anyone? Am wondering why it is necessary:


'… Customer further agrees that we will have the perpetual right to use, store, transmit, distribute, modify, copy, display, sublicense, and create derivative works of such derived data.

License to User Content.

With respect to that portion of Customer Content that consists of videos, images, music, comments, questions, documents, spreadsheets, Templates (defined below), and any other content submitted, posted, or otherwise made available by Customer and its Authorized Users through the Services (“User Content”), by submitting, posting, storing, or otherwise making such User Content available through the Services, Customer grants, and represents and warrants that it has all rights necessary to grant (including without limitation any necessary consents and authorizations from individual persons identified in the User Content and licenses from third-parties whose content is included in the User Content), to us a royalty-free, sublicensable, transferable, perpetual, irrevocable, non-exclusive, worldwide license to use, host, store, reproduce, modify, publish, list information regarding, translate, distribute, publicly perform, publicly display, and make derivative works of all such User Content, and the names, voice, and/or likeness contained in the User Content, in whole or in part, and in any form, media, or technology, whether now known or hereafter developed, solely for use in connection with our provision of the Services as described in this Agreement and our product documentation.’

_____https://coda.io/trust/tos

There are a lot of great features in Coda but this concerns me as far as content ownership goes.
Maybe I’m being over paranoid but I feel this is a bit over the top. Intrigued to hear community and Codan thoughts.
Rob

4 Likes

Hi @Saturday_School,
and welcome to Coda Community! :handshake:

I believe you highlighted a good point and it would be nice to hear something from Coda side in such regards.

2 Likes

Hi @Saturday_School,

That’s a good question and the answer is this is what’s required for us to be able to serve you your information on the internet. You’ll see very similar statements in nearly every apps TOS, from blog posting services like Medium to photo sharing apps like Instagram.