I’m Lane, and I lead product here at Coda. You haven’t heard from us in a while, and I know silence can feel uncertain.
Over the last few months, we’ve been deep in the work of bringing the teams together. That work is going very well and will be ongoing. In the meantime, I wanted to respond to the feedback directly with a look at some of what we have planned. What I’ll talk about below is not comprehensive, but it’s what we’re able to talk about at this moment.
It’s also worth saying one thing up front since we’ve heard concerns about resourcing. The teams working on Coda today are now larger than they were pre-merger. That’s great news for customers! As someone who is very invested in this product, I’m also excited to share that Grammarly has closed $1 billion in financing to deepen our product investments. We’ve added more Engineers lately and many of them are getting up to speed fast and writing code to accelerate delivery of our roadmap. For those of you who are engineers, you know that an upfront investment in hiring and ramping new engineers comes with a velocity cost at first, and then an acceleration.
Onto our plans. The acquisition gave us a really unique moment to reflect and rethink the core parts of Coda. Not just small tweaks and improvements, but also bigger changes that respond directly to some of the larger and more difficult feedback from the community and our customers. We previewed some of those changes in the webinar at the beginning of the year and have been deep in design, implementation and iteration.
I asked a few PMs and Engineers to jump in and share a bit more on this thread, but here’s a preview of *some updates we are working on in the next 6 months:
Significant upgrades to the table experience, starting with Table Locking (in Beta now!)
A refreshed UI that makes docs feel faster, cleaner, and more powerful to use every day
A new dedicated data layer that gives makers more control and protects important data from accidental edits by collaborators (sets us up to do things like hide data from search, which we’ve heard the community loud and clear on)
Performance improvements that make Coda faster and scalable - big docs that will load quicker, use less memory, and support databases with millions of rows
A self-serve version of Coda Brain
Our ambition is for Coda to be the best AI-native work surface for teams and agents to collaborate and get work done. We’re investing more deeply in the platform than ever before, not just building new features but strengthening the core experience so we can grow with you for the long haul!
I’ll let some of our PMs and Engineers chime in with more.
Thank you for all your feedback and support of Coda, including the constructive parts, it means a lot to the team!
Hello all! I’m one of the developers here at Coda, and I’m excited to share one of the projects we’ve been working on lately.
If you’ve ever made a hidden page for a base table, this one’s for you! We know how important it is to keep your data organized and intact, especially when collaborating with others. That’s why our team has designed a new home for your base tables to make it easy for you to manage, organize, and update your essential data all in one place.
By creating a dedicated data home designed for makers (and out of easy access for collaborators), we help ensure that data interactions are intentional. And there’s more - this update sets us up for more performant and scalable docs by making it clear which data needs to be loaded when.
Sneak peek of what to expect here, but lots more to come on this one - keep an eye out!
Hi Community! Thank you for your continued feedback and support. I’m Harshita, a Product Manager working on Table Locking. I’m super excited to open this Beta feature up to you all — you can sign-up here.
We’ve heard feedback over the past 1+ years that users want a better way to lock content in tables and views to preserve data integrity. This is especially critical in app-like use cases, such as OKR trackers, task trackers, and wikis. With Table Locking, you can lock a base table and its views, with options to prevent collaborators from adding, deleting, or editing table content or schema.
We’re excited to release this feature to Beta testers, and would love the Coda Community to try it out. If you have any feedback, please don’t hesitate to share it with our team in this form. Thank you!!
Hi all, just wanted to add some more on Brain. When we started building Brain we were targeting Enterprises, because that was where we were focusing at Coda. We were trying to help people search through the noise of their companies knowledge for answers. After joining Grammarly the obvious thing is now we have an even bigger consumer base who also has a ton of data they want to be able to do more with, especially as we move into a world of AI and agents.
So that’s what we’ve been doing (as well as getting to know our new co-workers) we’ve been building a consumer Brain It’s closer than it’s ever been and I’m excited to start giving you all access very soon.
I’m Ayuba on the Coda product team. We know that many teams use Coda as a central source of truth, ranging from client and project tracking, all the way through to company OKRs, knowledge hubs, and more. Over time, we’ve seen two common challenges arise and we’re working to solve them:
See data your way → As different people and teams use centralised data, it’s common to make views, so they can see the information in a way that makes the most sense for them. Before, when a substantial number of views were created, it would heavily impact the performance of the doc. Soon, we’ll be much smarter about how views work, so you can add hundreds (or even thousands) of views without worrying about slowing your doc down.
Only load the data you need → While centralising data is useful for standardisation, you usually only want to work with data filtered for yourself, your team, or a specific project. Before, even if you were viewing a heavily filtered set of data, we’d still eventually load everything in the doc behind the scenes. Soon—and in conjunction with the data layer updates from my friend Fil, we’ll load only the data needed to show you what’s on the page you’re viewing. This should allow for a much faster experience in larger docs—even on mobile!
And, as I’m sure many of you may have guessed, more granularly loading data is also an important step to delivering on our secure sync-page milestones. We’re hard at work making your docs faster, more secure, and easier to use.
Many thanks to this community for your continued feedback and partnership as we work toward this ambitious goal. We’ll continue to share updates as we have them and I’m looking forward to hearing your thoughts, so please sound off in the replies!
welcome to the community Thanks for lifting the veil on what’s happening at Coda & Grammarly. To be honest, we were starting to worry a bit. I’m now really excited to explore the refreshed UI and the dedicated data layer. And the acceleration driven by a growing engineering team is awesome. Looking forward to Coda 5.0!
Thanks for the thoughtful update — it’s exciting to hear that performance improvements are underway to support “millions of rows” and more app-like experiences.
I was curious if that scalability goal also applies to sync Coda tables, or if it’s primarily referring to integrations with external sources like Snowflake. As far as I know, sync tables still have a 10,000-row limit, and I didn’t see anything in the post that directly addressed whether that might change.
Could someone clarify if increasing the row limit for sync tables is on the roadmap?
I so appreciate hearing from all of you! Thanks for taking the time to share what you can at the moment. Please know that we’ll be staying tuned for what’s next - it’s great to know there’s so much more Coda magic waiting for it’s release
@Chris_Williams1 yes, with the investments and updates we’re making to our infrastructure, this creates opportunities for us to substantially increase how much data tables in Coda can hold—including Pack sync tables.
Optimizations in this part of the product will be greatly appreciated. Given that we know so little about what actually occurs behind the views, we tend to abuse this capability and that quickly leads to unhappy users.
I would be alot more positive about these announcementsif they came with a road map. The last 5 years has been alot of talk about ideas, and concepts of what you want coda to be. Then you announce some change in direction and purposefully list vague ambitions with no mention of timing or any expectations of when these features will be available.
Can we expect these features to be developed similarly to single page sharing? Should we expect 4 years of talk about the feature, some incremental updates and then radio silence as newer hotter features get discussed?
Something we often hear from our community and beyond is that Coda can feel intimidating or confusing for those newer to the product - whether they are building new docs or using those made by others. I’m really excited that our team is taking a fresh look at our product through the eyes of these new makers and collaborators to make Coda feel approachable and intuitive from day one.
Our refreshed interface will offer a clean look with minimal distractions, while making it easy to access the most common and frequently used actions for key tasks. And the power features you know and love will have a dedicated space in the settings panels! We also think these updates will help reduce the burden on our expert makers, like many of you, to create guardrails in your docs or explain complex concepts to your collaborators to enable them to do what they need.
As an example, here’s a sneak preview of what the new doc experience could look like:
How about actual translation abilities for text? If I create a page or a table in English, I’d love a toggle or a google translate type browser extension to automatically translate my English text to one of our many other languages such as Spanish, French, Italian, German, etc?
Again, this is not for international teams. It’s a solution that helps people with teams in one region/country. You need to allow each user to display dates, times, and numbers in the way they prefer while maintaining the data underlying it. Why shouldn’t my European colleagues be able to see dates in the format that makes sense to them while I see it in my chosen format?
I’m super excited to open this Beta feature up to you all — you can sign-up 
It’s closer than it’s ever been and I’m excited to start giving you all access very soon.
Everyone!
Thanks for lifting the veil on what’s happening at Coda & Grammarly. To be honest, we were starting to worry a bit. I’m now really excited to explore the refreshed UI and the dedicated data layer. And the acceleration driven by a growing engineering team is awesome. Looking forward to Coda 5.0!
I’m Shelley, from the product team.