Replit: What Packs Wants to Be

Or certainly, what some of us might like it to be.

I have often envisioned a Coda solution while away from my office. These inspirational thoughts entice me to walk through the approach and invariably I arrive at the threshold of Packs. And that’s when I begin to see constraints that I wish were not there.

In contrast, when I conjure a new approach that doesn’t emanate from or for Coda per se, there are no constraints except my own skill gaps. And even that is easily dealt with through marketplace dynamics. For every skill gap I may have, there are a few dozen very skilled developers ready to help me and one of them is Ghostwriter. This is the realm of Replit.

Build software collaboratively with the power of AI, on any device, without spending a second on setup.

The Coda Packs development environment is essentially Replit without the steroid-like immersive development experience that includes pretty much everything you could need for creating good software. This approach will soon be common place as the planet transitions from a few tens of million developers to well over a billion developers.

As I continue to learn and use Replit, many of my observations about AI’s existential threats to job displacement seem to be increasingly validated. This one in particular comes to mind ( PREDICTION: AI Will Trigger an Explosion of New Software Developers). It was penned without influence from a deeper awareness of Replit, but certainly inspired by AI itself. Dan shipper awoke my need to draw similarities to Coda’s Pack development model. In his recent essay (What Comes after SaaS?) he exposes a growing pathway to software development that seems both logical and already occurring.

Bespoke apps for everyone—customized by AI

Ergo, millions of markets of dozens. Or, a billion markets of one.

Simple enough.

What’s This Article Really About?

As much as I would enjoy a narrative about ways to make Packs better, my objective here is to explore how custom apps for everyone could happen. And why Coda needs to embrace this new horizon without hesitation.

Replit’s founders believe AI will transform everyone with an idea to become a software developer. A good example is NodePad, a simple marrying of AI with mind-map-like visualization. This is not much different from @Mario_Mijic’s AI At Work template (AI Mind Maps). NodePad is an ideation tool that uses mind-map-like visualizations. Mario’s template can be used for ideation as well with one big shortcoming - manual integration steps required to actually render the mind map.

With NodePad, the ideation process is unsurprisingly AI-driven. This is an ideal use case for artificial general intelligence. But the entire solution begins and ends in the visual spectrum of nodes in a brainstorming topic.

I suspect Mario would leap at the chance for his Coda template to be equally visually interactive. And I’ll bet that was on his mind as he broke new ground developing a pathway that blends Coda AI with mind maps. I have as well and both of us probably came to the same realization.

You can’t Get There From Here

If anyone can explain to me how Mario (for example) could create a unified AI-driven mind mapping solution that avoids the fractured steps of copying and pasting between AI outputs and rendering inputs, that would be wonderful. I’m pretty sure it’s not an easy path or possible at all.

Saleh Kayyali, the creator of NodePad is an interaction designer, not a software engineer. Replit transformed him into a software developer and Replit not only helped him manifest his idea as an application, it provided the underlying AI integration needed for the app features. And it provided him with all of the infrastructure elements seamlessly and ready to support his app vision.

Beyond SaaS

While Packs are similar to Replit in a few ways, Coda templates are a lot like Replit as it begins to chip away at current SaaS business models. As Shipper points out…

Making the app available for many users at once requires a lot of up-front effort. You need to build login systems, a database architecture and code that accounts for multiple users, you need to deal with keeping user data secure, and you need to build lots of settings screens so that customers can configure the product. The more time goes on, the more money and effort you’re going to expend building customizations for users, instead of building core product improvements.

Coda Templates are well-positioned to take advantage of the move toward millions of markets of dozens, and even a billion markets of one. Templates can shape-shift to meet specific requirements without the burden of SaaS dependencies standing in the way. Individual innovation thrives.

Data Sciencey Stuff

I’ve often said that Packs should support Python. As a computing society of people, data science is seeping into everything we do. New demands are already at our doorstep with the need to transform data into shapes and aggregations that are suitable for LLMs. Packs are woefully unprepared to support these new requirements.

Packs need to be more like Replit. Or, perhaps Coda should consider how to fully embrace Replit.



Thank you @Bill_French for this post. :+1: The links are very interesting. I did not know NodePad until now.

Since pack development is not part of the hackathon, I didn’t look into it further. I tried a few things and also wanted to see how far I could get with the existing options. I had already played around with Canvas and other methods to get it to work that way.

I was helped a lot by a 15 minute call with Coda support. But also the YouTube videos from TheCodaGuy


Just searched the SDK doc and saw that Coda can render SVG images.
A simple ‘solution’ would be:

  • AI creates Markdown from user prompt (or later from other sources like documents etc.)
  • A Pack component passes the Markdown payload to a REST component
  • An SVG image is returned and rendered.

Something similar happens on the homepage and the GitHub repo.
I haven’t tried SVGs in Coda yet and can’t say anything about their interactions or whether this is possible.


But maybe someone can tell me if I can also include custom JavaScript libraries in Coda and build myself a canvas or similar element. Then the possibilities would be endless.


“Basically we use markmap-lib to preprocess Markdown into structured data, then render the data into interactive SVG with markmap-view.” from Doku Markmap

Coda SVG Images guides

Yep, and you will end up with a nicely integrated [static] rendering with a sizable development effort. In my view, this is just a prettier dead-end because mind maps are best used dynamically. Imagine a whiteboard covered with sticky notes that required you to go into the next room to move them around or change the writing on them, swap a color, etc.

It is. But I’m pretty sure making it dynamically update with in-place editing is not possible.

Yes, you can. You just need to build the Pack with the CLI. Works great.

I don’t think so. As such, you are off to Replit to build this tool and embed it into a Coda doc, and therein lay the tragedy. Embedded apps are sandboxed; you cannot inspect them or access their objects from Coda - all you can do is change the URL.

1 Like

I’ve often said that Packs should support Python


Coda+Python will be a formidable challenger to Notebooks/Streamlit/ you name it.
Unfortunately I don’t think this or anything you allude to in your post is on Coda’s radar at all.

Over the past few years, Coda’s strategy has narrowed from “Docs that are as powerful as apps” to “tool builder for small-ish product/project management teams in big corps”. While I am personally disappointed by this, I can totally see the wisdom from a business strategy point of view:

  • A coda doc is not fundamentally backed by a database. Changing this will involve a full rewrite.
  • Coda offloads nearly all of the compute to your browser, which keeps its costs low but also means languages other than the dreaded Javascript are out of question.
  • A business is much better off being reliably paid for dozens or hundreds of makers by stable and sticky corporate clients, than wagering on the shallow pockets of individual citizen-developers.

So my money is on us never seeing overtures from Coda to the data app builder community… But there is definitely room for a Coda-inspired, yes-code, functional (ie spreadsheet like), fully managed, data app builder in the market.


Great insights. But one thing puzzles me.

Given that Packs are ostensibly NodeJS apps built for server-side deployment and execution, wouldn’t support for Python be fundamentally similar?

I agree, but I wasn’t suggesting this either. My assertion is that Coda can expand revenues by expanding the universe of Makers. The current Pack development environment is not positioned to make this happen. To the contrary, Makers tend to avoid Packs because they must become skilled developers to build anything. Ergo, it seems that even if Coda desires to remain in a less risky enterprise envelope, it needs to support extensibility more like Replit.

Can you imagine an IDE in 2024 without integrated AI to streamline development and support for AI in every aspect of solution development. A development platform that does not support free and open access to LLMs. Or a restriction on endpoint domains.

If Coda is content with “ tool builder for small-ish product/project management teams in big corps”, these limitations won’t resonate.

Another puzzling question - how could a $100m+ equity structure accommodate a narrow target like small teams in big companies? No one raises that level of investment to solve for (x) where (x) is a tiny market.


Given that Packs are ostensibly NodeJS apps built for server-side deployment and execution, wouldn’t support for Python be fundamentally similar?

Fair point. I guess I never really bought into the idea of packs as a way to expand the the functionality of a single doc. It seems to me that packs were built to be distributed, but I want to quickly write code to use in a single doc.

I think of each doc as its own mini-app, and I just want a Server Functions tab, which I could jump to, write whatever function I need to solve the problem at hand which can’t be solved with Coda Formulas alone, and then have that function be immediately exposed in the CFL just like a pack formula/action would be. And if I could write my Server Functions in python, and get to pip install the packages that I need, I would happily pay more for the priviledge.

I really, really, like the instant and intuitive building experience of Coda, and I come to it when I need to build things fast and without knowing in advance what my schema will be. It usually starts off ugly, and then I iterate to get to something that works really well for me and my team. I would like the code part of my doc to be deeply integrated with the rest of the building experience and just as easy to iterate.

So I think I fall somewhere in the middle between where you’d like to go, and where Coda seems to be going: I wish Coda would embrace code more openly, and expose more of its underlying UI APIs to makers to customize the docs, but I also don’t think I really need full fledged IDE experience.


Yes, it’s a heavy lift if the pack is used only once. And all of the distributed agility is unnecessary when this is the outcome.

Yep - a convenient way to think about it. This is precisely how PubNub designed its micro-services layer. Taking that to the extreme, this approach would also make it more possible to host endpoints for a given document. And what might those endpoints provide in terms of functionality?

  • Custom APIs to access document data and content?
  • A JSON export of a table?
  • A custom import feature?
  • A real-time inbound or outbound data pipeline on MQTT?

Agreed. And to be clear, neither does the founder of Replit. The complexities of an IDE and software engineering must be removed if the body of developers must grow in the shadow of AGI. Replit has made some gains in this regard and a long way to go, but the vision is clear and it’s apparently shared by Google who was instrumental in making Google Apps Script stick. Replit (2025) is likely what comes after Apps Script and we can predict with confidence an acquisition in that time frame.