It’s the age of low-code, it’s the age of creativity, it’s the epoch of internal tools, it’s the epoch of user-facing products, it’s the season for general purpose apps, it’s the season of the vertical, it’s the spring of small business, it’s the summer of the enterprise, we’re all going to IPO, we’re all going directly the other way.

The low-code movement is big. I have a spreadsheet tracking a number of low-code startups. This morning it sits at 53. It’s nowhere near complete. There are hundreds more.

And it’s not just startups. Each major tech company from Microsoft to Salesforce is responding to the clamorous demand for low-code by heavily investing in their own product, the promise being that while traditional apps will continue to support common business processes, the last-mile of corporate software will increasingly be built by non-engineers — often, and, in the opinion of this author a bit patronizingly, called citizens — who are much closer to the problems that need solving.

But maybe, just maybe, this is all lipstick on a pig. Helping more folks build software is great, make no mistake, but the low-code movement has the potential to be something much more righteous. Today, most low-code platforms are merely helping a lot more people build the same sort of apps we’ve always built, when the real opportunity is in accepting that it’s high time we listen to those acid dropping graybeards from the 60’s and rethink how we interact with apps entirely.

“Low-code” is how we build, but it’s our day-to-day apps where we find the raw material. To build the last-mile of corporate technology, to usher in a new era of computing literacy, and to generally indulge the insatiable appetite of world-munching software, we need live apps that, like spreadsheets, are not treated as finished products, but as building blocks to be extended in real time using low-code techniques.

Shrink-Wrapped Apps

The support team at my last company needed a custom view of Slack channels, so that those customers waiting the longest for a response would be displayed first. The query was trivial, but the solution was not. We had to create an entirely new side app, research the Slack API, provision a developer token, brush up on React, then create the new view. It took a few days. But the list of channels was staring us in the face all along. Why couldn’t we just sort the damn thing?

Apps are designed to carry out specific tasks. They can be characterized as shrink-wrapped. Developers dictate the features, then users are pretty much stuck with what comes out of the box. Low-code platforms grow the supply of app developers, but, with rare exception, still have us building the same shrink-wrapped apps we’ve always built.

This isn’t too surprising. Most products are shrink-wrapped, and for good reason. I don’t need to mod my car much beyond maybe wrapping winter chains around the tires. I just need it to get me to my destination. As a rule, shrink-wrapped products solve simple problems that lots of people have.

But business processes are neither simple nor homogenous. Whether it’s project management, CRM, or inventory control, every feature in the software meant to support it — every data model, every dashboard, every workflow — reflects an assumption some product manager in the East Cut made about you and your company’s priorities, or, more accurately, your priorities diluted with those of 15,000 other customers.

Users today resort to two methods for extending their software: (a) APIs and (b) builtin extension systems.

APIs are built for engineers, but now even citizens use APIs indirectly. Low-code platforms like Stacker, Zapier, and Mulesoft act as thin frontends to APIs for creating new extensions.

But APIs are a deflated, lifeless diminution of an application. Extending an app through an API, even through a friendly GUI, forfeits all the context and meaning from the app’s own user interface. It’s trying to manipulate a radioactive rod from a hundred miles away with buttons and tongs. It’s blending up a home cooked meal and drinking it through a straw.

Builtin extension systems offer a remedy. These are the in-app features for adding new fields, automating workflows, designing dashboards, or otherwise molding apps to fit one’s needs. They too let users shape apps beyond native features, but unlike APIs, retain context by remaining embedded in the app itself. When lots of different customers start using a product, these extension systems grow to be more important than pre-packaged functions. At large companies, entire teams exist to customize Jira/Salesforce/SAP, and therein lies the problem. When learning basic Salesforce customization requires more training than a pilot’s license, something has gone awry. Extension systems are often tacked on deep into the product lifecycle and end up looking more like Frankenstein than LEGO.

It doesn’t have to be this way. Consider the most successful low-code platform of all — the spreadsheet. You don’t extend a spreadsheet with an API, and you sure as hell don’t need to be certified. You never leave the spreadsheet at all. You manipulate its contents directly. You dip your hands into the clay and mold it into whatever you need. Spreadsheets serve as a rare bridge over a longstanding gap between the power of programming on one end and the ease of use of UIs on the other.

Live Apps

Spreadsheets are the flagship example of live apps. Live apps are not finished products. They can be extended in real time using low-code techniques that blur the line between user and developer. Other examples of live apps include digital audio workstations (DAWs), CAD software, extensible text editors, and indeed some of the more forward looking of today’s low-code platforms such as Airtable and Notion.

Traditional apps have extension systems too, as we’ve seen. But live apps are very different. They’re as much development environment as they are application, with extension systems designed axiomatically, like programming languages, to be much more powerful. They’re complete in the Turing Complete sense. Sure, Atlassian gives you some control, but only for specific use cases they deem worth supporting. Jira is revered as a paragon of power, but go ahead and try to implement deeply nested subtasks or automate an async communications workflow and let me know how powerful you feel.

Live apps derive their power from the live platform on which they run. Though, true to the theme, there is no clear distinction between the two. Where is the line between a spreadsheet and Excel itself? To offer extensiblity de novo, live platforms deeply integrate with the apps they support. Traditional platforms treat their apps as black boxes. Your browser knows of div’s and span’s, but nothing of the meaningful objects — the tasks, messages, employees, notes, collections, etc. — that users actually care about. Shrink-wrapped apps forfeit vast amounts of power when projecting their objects onto the low-level bitmap that is a web page, but Excel knows about the cells in your spreadsheet, so can offer you low-code features to reshape them.

There does exist a small but impressive cohort of live platforms within today’s low-code movement, I’m happy to admit. Airtable and Notion are two fantastic products I use everyday. But their purview is limited. Both are walled gardens that let users create live standalone apps, but fail to effectively integrate with the existing data sources and systems that most companies have. They’ll continue to enjoy success, but the market for live platforms and the live apps they enable is mostly untapped.

Other low-code products by comparison are well intended, but uninspired. A better version of the wrong thing. There’s a revolution here worth staging, but it’s not in how we build apps. It’s in how we use them.


This idea isn’t new. It’s what the early pioneers of human-computer interaction were prophesying fifty years ago.

In 1963, Ivan Sutherland introduced Sketchpad, a precursor to modern CAD software, in which users could define new geometric constraints in real time with a stylus. And in 1967, Seymour Papert invented a language called Logo to teach kids geometry and physics. Children programmed a turtle to walk and turn and change course in real time as they modified their instructions.

These projects were live, certainly — they let users build new features — but they stopped short of providing a general purpose platform on which other live apps could be built.

The most stalwart gadfly of the new computing literacy, Alan Kay, was well aware of Logo and Sketchpad when he conceived of Smalltalk in 1972, which was, as far as I can tell, the first general purpose live platform. Smalltalk was one of the first object-oriented languages, but unlike its successors, Smalltalk was a full-fledged visual development environment. Objects were graphically represented on screen, and could be reprogrammed or swapped out for new modules in real time. Developers could build apps, but users always had access to the fluid platform underneath.

But mainstream often lags research by fifty years or more. It would take twenty years after their arrival in 1974 for personal computers to go mainstream, and would unsurprisingly take much longer for a new method of interacting with these machines to emerge. In the mean time, most computing media were direct translations of old things — docs, slideshows, etc.

The web blitzed onto the scene in the 90s when PCs were just beginning to go mainstream, but it wasn’t the app platform we know it to be today. “The internet was so well done, the web was by amateurs,” Kay says, by which he meant the architects of the web shortsightedly set out to build a hypermedia system, precipitating a 30-year slog to twist it into the application platform it should have been designed to be in the first place. Javascript in the late 90's made basic apps possible, then AJAX in the early 2000's enabled interactivity. All the while, more and more of the physical world was being modeled and served up on the digital network.

What’s Next

Only in the past decade has the web grown into an app platform. But we’ve seen its limits. Patrick McKenzie thinks we’ve realized about 0.01% of the true software market, and I agree. The only way we can fulfill the rest is if we begin to treat information workers as literate authors of their own tools.

For this, we need liveness. We need a new platform that offers the flexibility of spreadsheets to a much wider class of software.

Open an app. Hover over an object. Drag it into a new view. Drag objects from different apps for a single, integrated view. Navigate to an object’s data type. Add new fields. Create entirely new types that link to existing ones. Group objects into ad-hoc collections. Share those collections. Record an automation. Define a new keybinding for that automation. Append the new automation as a command to an existing object. View all properties of an object. Reference those properties in queries whose results remain visible and up to date. Keep all extensions private until you share them with others.

Clay Christensen is best known for The Innovator’s Dilemma, but he’s also done great work on modularity theory, or the theory that systems start out as integrated wholes, then develop standard interfaces and unbundle over time. Today’s apps are in the middle of this life cycle, and live apps are the natural next step. Standards follow sameness, and there’s already a high degree of sameness across our tools. By formalizing it where it exists, we unveil building blocks that open up new opportunities for creativity.

The medium is the message. Our tools don’t just express our thoughts, they also shape them, and that’s what’s so offensive about the shrink-wrapped apps on offer today. They’re not bicycles for the mind, they’re blinders. They’re a dearth of culture. They’re the Donnie Darko rails directing us where to go next.

The movement toward liveness will play out over years, if not decades. It’s difficult to say what form it will take, whether it’s open or proprietary, fragmented or consolidated, but I think building a radically new sort of platform to realize that future is the most exciting thing to work on right now, and that’s why I’m building Plato. Plato’s mission is to become the best platform for building live apps, and we start with internal tools. If you‘d like to learn more, you can contact me at I’m hiring a small founding team of extraordinary engineers.

Michael Gummelt

Founder, Plato