Liveness

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, 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.

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’re shrink-wrapped. Developers dictate the features, then users are stuck with what comes out of the box. Low-code platforms grow the supply of 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 common problems that lots of people have.

But business processes are rarely common. 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 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 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 Coda.

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.

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 Excel and the spreadsheet you create on top? 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 , properties, collections, and values that users actually care about. Shrink-wrapped apps forfeit vast amounts of power when projecting data 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 Coda 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 an old thing. There’s a revolution here worth staging, but it’s less in how we build apps, and more in how we use them.

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 we’re 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 mgummelt@plato.io. I’m hiring a small founding team of extraordinary engineers and designers.

Michael Gummelt, CEO @ Plato