Really excited about this feature! Will we be able to set different row layouts for each tab? And when creating an open row button, will we be able to reference the different tabs for different row layouts? Lastly, where on the road map is updating the timeline view so we can have more than one entry of the same type on the saw line?
1 Like
Sooo true…
I’d just like to ask: how does the Coda team prioritize which features to develop or — sorry — which BUGS to fix?
It’s kind of crazy to celebrate this tiny feature when you apparently have quite a lot of work to do on other, far more impactful issues.
(The absolute uselessness of your AI is, for example, a ‘small’ topic…
)
My intuition: you’re not prioritizing based on what your customers say, but rather there’s someone on your side — probably in marketing — who dictates whatever they personally feel is ‘important and urgent’ to work on…
Bad luck: they’re out of touch with the market.
So, how does this prioritization actually work?
4 Likes
@Shelley_Garg Have you begun rolling this feature out? My team and I are very excited to try it.
2 Likes
I’m hoping both elements can stay visible at top when scrolling through long tables, that would be incredibly helpful! I love the filter bar but in tables with many rows losing it from the top is extremely frustrating. By the time I scoll back up I forget what I wanted to filter. 
2 Likes
+1 This would be a welcomed improvement to the UI. @Shelley_Garg can you confirm if the filter elements will remain visible as the user scrolls down a table?
1 Like
Appreciate the time you take to share your honest and thorough feedback with us, Bertrand. We recognize that many users may feel the same and don’t speak up, so thank you for being that voice.
As someone who works on our product, I’m really glad to hear you love Coda and find it superior to Notion. That means a lot to me, and I know to the rest of our product team too.
This is exactly what I meant by “heard.” The Coda team sees what this community is sharing, including the specific items you’ve mentioned. Many of those items are shaping our current and future development plans. Totally understand the frustration around how quickly we’re shipping updates, and we’re working hard to address that.
2 Likes
Great question! We are planning to support different row layouts per tab, and you should be able to reference a particular tab’s layout from an open row button.
We’re actively working on other improvements to tables and timelines, but same line items on a timeline view isn’t part of our near-term plans right now. It’s really helpful for the team to know this would be valuable for your workflow.
1 Like
Fair question. Our prioritization comes from product and engineering teams weighing customer requests, technical dependencies, and strategic bets on where we think the product needs to go.
I hear your frustration, and I know this particular feature isn’t what you were hoping we’d focus on. This one is significant for many in this thread, while I understand it doesn’t address the issues most important to you.
Features like this ship alongside larger efforts—they’re not competing for the same resources, but I get that it can feel frustrating when the things you need most aren’t moving as fast as you’d like.
If there are specific bugs or features you’re most concerned about, I’d genuinely want to hear them. The product team does review community feedback regularly, and specifics help us advocate for what matters most to you.
3 Likes
Not quite yet, but excited to hear you’re excited 
You can expect an update before the holidays!
3 Likes
We have been doing some early exploration on a sticky table title, filter, and tab bar, but not for this launch. Helpful feedback to hear that it’s important to you both!
3 Likes
OK I took the liberty to delete my initial response which, as some wise man pointed out, didn’t add anything to the discussion. I’m still frustrated by “we hear you!” messages not followed by any action, but I’ll try to add more to the table than a ragepost only worthy of social media. So here we go.
In my opinion, the four pillars that currently define the value proposition for Coda, and that make it a much better product than Notion are:
- The Coda Formula Language (CFL) → that’s what allow power users to very quickly make Docs that actually look and work like apps. You need time to master it, but oh boy is it flexible and powerful.
- The “Packs ecosystem” → it allows Coda to connect to almost any tool in the Cloud, and is even more important in AI-driven times.
- The “Maker-oriented” pricing → not billing Editors is, in my opinion, very important. It’s a key differentiator and a selling argument.
- The Community → I’ve said it before many times, but outside of FOSS, I don’t know any other community out there that brings that much value. Massive respect and thanks to @Paul_Danyliuk, @Scott_Collier-Weir, @Agile_Dynamics, @Bill_French, @Nina_Ledid, @Christiaan_Huizer, @Pablo_DV, @joost_mineur, @Jono_Bouwmeester and countless others.
The reason why I say all this is because Coda / Superhuman is obviously at a turning point. I hope the CFL and packs are only going to get better (and the vague announcements about databases do give me hope), but I worry a lot when it comes to the pricing and the community. The Superhuman pricing seems to totally wipe out the Maker-oriented approach. And evidence over the years tend to show the community is not actually heard. I really, really urge Coda / Superhuman to listen to us in order to properly navigate those dangerous waters. For our benefit as well as theirs.
15 Likes
I fully agree, @Bertrand_Bouteiller ! I could sing hymns about CFL all day long - in particular regarding the fact that CFL is used both for functional formulas (ie “regular” formulas that compute values) as well as procedural formulas as run-actions (ie formulas with side effects).
That is very rare to see in a platform (ie Google Workspace uses Google Sheets formulas and Apps Script, Microsoft uses Excel formulas and VBA, etc).
So, learning one skill (CFL) unlocks double the capability. That is an aspect of Coda that imo gets way too little attention.
10 Likes
well said @Bertrand_Bouteiller
hear hear !
and i look forward to the coda / grammarly / superhuman response to this cry for clarity.
respect
max
5 Likes
Spot on! 
And when it comes to Excel, you could argue that if you’re serious about it, in addition to formulas and VBA, you also need to learn Power Query M - and may be Power Automate WDL?
Sooooo, let’s hope the time we invested in learning CFL will still be useful a few years from now! Right Codans? 
3 Likes
Hi All. Curious if we have an updated release date for the beta version? I thought I saw early December originally, but we are approaching mid-December
3 Likes
Indeed, and thanks for the mention and the inspiration to lean into the threat to the Maker species.
This is where the expanded definition of the Maker comes in. In this brave new world, the Maker isn’t just designing a table to track OKRs. The Maker is the Agent Orchestrator.
If Superhuman is smart, they will realize that they cannot build every vertical workflow their 40 million users need. They can’t build a perfect “Legal Review Agent” for a boutique firm in Chicago, or a “Supply Chain Optimizer” for a dropshipper in Miami.
But the Makers can.
Here is the blueprint for how Superhuman survives its own hype:
- Democratize the “Pack”: Historically, building a Coda Pack (integration) required TypeScript and a CLI. Superhuman must allow Makers to build “Packs” using nothing but natural language and logic. If I can explain a workflow to an AI, I should be able to package it as a tool that my team can use.
- The Maker as the AI Governor: Agents are hallucinating interns. We know this. The Maker’s role shifts from “building the schema” to “building the guardrails.” The Maker defines the context, the constraints, and the success criteria for the AI agents operating within the Superhuman suite.
- Monetize the Internal Economy: Keep the Maker license. In fact, double down on it. Make the Maker license the “Superhuman Builder” tier. These users get access to the deep API hooks, the agent SDKs, and the ability to deploy “mini-apps” to the rest of the organization (the free Editors).
We are at a crossroads.
In one direction, Superhuman becomes a “content slurry” machine—a place where AI writes emails to other AIs, with the output stored in docs that nobody reads. That is the utility trap.
In the other direction, Superhuman becomes an Operating System. It becomes a platform where a new class of “No-Code Engineers” (the Makers) build bespoke, agent-driven applications that run the modern enterprise.
Coda proved that people will pay to build. Superhuman needs to prove that people will pay to govern.
6 Likes
Thanks for sharing your thoughts @Bill_French ,
The concept of the Maker as an “Agent Orchestrator” is spot on. I would add that these Makers will also shoulder the responsibility of feeding the AI with curated and validated input. This effectively upgrades the Coda workspace to the ultimate source of truth in an AI-driven world.
However, while empowering Makers to build Packs is great, we shouldn’t let SaaS companies off the hook. Companies that own the APIs need to be encouraged to build and maintain their own connectors. Relying on volunteers works temporarily, but without official support, maintenance eventually suffers when the Maker’s motivation (or time) runs out. Since the revenue model for Packs is only interesting at massive scale, we need in my opinion first-party integrations to ensure long-term reliability.
Cheers, Christiaan
5 Likes
Hi,
I personally had access today.
2 Likes
Thanks Bill for your inputs, very valuable as always. I’m totally aligned with what you say, but there’s one topic where I’d be curious to know what you (and others) think. And that’s the free Editors.
I know I said in my previous message that not billing Editors was important, but I wanted to keep it simple… What I actually think is that it’s important not to bill Editors as much as Makers.
I’m convinced that the “free Editors” is a simple and effective marketing message. And I’m concerned that my NGO clients couldn’t afford to pay full price for their Editors (and if I remember correctly, I’ve seen others in the healthcare sector raise the same concerns). But I’m also concerned that Coda / Grammarly / SuperHuman can’t afford to have too many Workspaces with one or two paying Makers and hundreds of free Editors.
In my mind, the solution would be to have a pricing à la Softr (or any other app builder for that matter). I.e. something like “for each paying Maker, you get 20 / 50 / 100 / 1000 free editors” (number of free editors could go up with your Plan).
That would make perfect sense to me. Especially since in the past few years we’ve seen “database” tools and “app builder” tools converge. For instance Baserow now has an app builder, and Softr now has native database capabilities. In my opinion, Coda is uniquely positioned in the fact that it natively blends the database side with the app building side - once again thanks to the wonderful CFL.
Not differentiating Editors and Makers makes sense if your tool is ready to be used off the shelf. Or if you want everyone to be able to tinker. To a certain degree, I can see that working for Notion (with MANY caveats). But definitely not for Coda.
I’m looking forward to reading your thoughts on the matter (and even more so Coda / Grammarly / Superhuman thoughts )!
5 Likes
Hi @Bertrand_Bouteiller , thanks for asking.
I agree that the “free Editor” concept needs rethinking. In Coda, complexity is not optional, and I see several reasons to retire the model as we have it today—even more so in a future where AI plays a dominant role (a topic I explore in my next blog).
I’m a proponent of a model where every Maker seat includes a set allowance of Editor seats. I’d even take it a step further: imagine a “Master Maker” role above the standard Builder/Architect. This would offer advanced control without forcing teams immediately onto an Enterprise plan. For those of us in Europe, Enterprise often isn’t a logical step due to hosting and support realities, so we need that robust middle tier.
Ultimately, we all want Coda to remain a viable product delivering value to users and investors. Securing that shared interest likely requires a firm change in how we structure access.
Cheers, Christiaan
4 Likes