Software is eating the world, but only 0.5% of the world can write software. On the other hand, over 2 billion people know how to use a spreadsheet.

With mature platforms like Zapier and Airtable, no-coders are now everywhere — much to the anxiety of developers. But in order for no-code to work at scale, no-code platforms must start giving developers the primitives they need too.

In 1979, the most powerful no-code platform ever built was released. VisiCalc, the precursor to Excel, allowed non-developers to finally build their own programs in a point-and-click fashion. This was lightyears better than the default experience: typing commands on a command line.

VisiCalc wasn’t as easy to use as pre-packaged accounting software at the time. Early reviewers noted that this was a key benefit, “because VisiCalc is not pre-packaged, it is infinitely more powerful and flexible than such programs."

In other words — having a lower-level, horizontal no-code platform allowed users to solve countless other use cases. And yet, developers still dunk on Excel. All the time.

VBA (Excel’s programming language) has been one of the most hated languages for years, according to StackOverflow’s annual developer survey. Searching for Excel on Hacker News returns war stories about migrations gone wrong. These tools lack key primitives that developers come to expect: version control, testing — the list goes on.

Developers see Excel, and no-code systems at large, as prototyping platforms that could never scale up to serve business-critical workflows. And when no-coders take them to production, they hate being the responsible party for putting out a dumpster-fire at scale. Simple Excel errors have lost companies literally billions of dollars, or led to 100,000s of potential COVID cases due to improper tracing.

For the record: this is not an essay where the conclusion is “code > no-code”.

No-code platforms are extremely empowering. They activate potentially billions around the world to solve their own problems. The real issue is that no-code platforms aren’t extensible and scalable after reaching production, despite how critical they’ve become to how companies operate.

Why developers dismiss no-code

By 2024, 80% of technology products and services will be built by non-developers, according to Gartner. Spending on low-code software is expected to grow to $45.5 billion by 2025, a 2.5x increase from 2020.

Developers view these trends pessimistically:

The NoCode movement really should be renamed to EventuallyYouWillNeedSomeCode

— I Am Devloper (@iamdevloper) November 19, 2021

Developer Twitter piled on:

Many times the conversation starts “We have an Access database and a few spreadsheets. We upgraded the server and now we can’t invoice. Can you help?” It’s like shoving an arm into a bucket of live snakes, recently enraged by weasels, who are still in the bucket.“ –@CharlesRandles

No code is the flat Earth society of software development. – @ch8nya1

Of course the topic of no-code inflames developers. Its name alone implies that developer jobs will be automated away.

But, this couldn’t be further from the truth. Even with the advent of open-source, the API economy, and countless technologies that allow developers to operate at a higher abstraction, the shortage of engineers in the U.S. will exceed 1.2 million by 2026 according to the US Bureau for Labor Statistics. A McKinsey survey from earlier this year additionally reported that 87% of businesses are already seeing a developer shortage, or anticipate one in a few years.

Looking past this concern around automation, developers voice genuine concerns about what’s missing from today's no-code platforms.

I avoid no-code, I'm not afraid of it. I'm just waiting for no-code solutions to be open source, and integrate well with TypeScript. Can't wait to move past the SalesForce era of proprietary tools that don't easily integrate with custom apps. – @EricVicenti

I would say "none of the No Code platforms I've seen are fine", because all the ones I'm familiar with have either inadequate testing or no testing at all. The problem is that apps built without testing don't scale past a certain level of complexity — and so complex projects built with No Code tend to fall apart as they become successful. – HN

As developers rightfully point out, most no-code MVPs hit a "complexity wall", with no escape hatch. When no-coders hand off MVPs to developers for further enhancements, developers either have to write lots of brittle middleware, or just re-platform entirely. For example:

• No-coder uses Airtable. Airtable becomes their preferred way to manage data. Eventually, no-coder wants to read data from an existing Postgres DB into Airtable too. Developer is blocked by Airtable’s severe rate limiting. Developer can opt for a mass migration from Airtable to a database, but must also replace the no-code logic + UI layer too.
• No-coder uses Zapier. Eventually, no-coder has dozens of Zaps. This becomes costly and unobservable at scale. Developer wants to layer in version control and tests, but Zapier lacks any support for these primitives. Developer must rebuild everything in Zapier to AWS lambda.

Poor Toad.

The complexity wall found in most no-code platforms prevents their use at scale.

How no-code can become more scalable

I’ve chatted with hundreds of CTOs and developers about their attitudes towards no-code platforms, and what they wish they had.

Most felt that no-code has a net-positive effect on their companies, because they free up precious developer time to focus on core product. No-code also allows their business users to reach clarity about what is “actually” needed from a systems perspective, before needing to build something expensive.

But they all hated using no-code at scale. The concerns can be summarized into two themes: extensibility and evolvability.

Extensibility

Extensibility describes how easy is it to add new functionality to a production system. How easily can you add "one more step" to a workflow? Do you have to write middleware? Or re-platform entirely?

Here's how the next generation of no-code tools should embrace extensibility:

Interoperability through good APIs and Webhooks

Let's say that I want to read from my product metrics database into an Airtable CRM. I want to keep my Airtable views + workflows while enriching them with user metrics. To make this happen, lots of middleware is required. Depending on how many users I have, this might even be impossible given Airtable's row limits and API rate limits.

This can trigger re-platforming on its own. Hence, why moving Airtable to SQL is one of the most viewed questions on Airtable's support forum.

Since no-code data stores can rarely be accessed like SQL, developers must write a lot of middleware to get data from one store to another, worrying about orchestration, and dealing with API rate limits + poor security along the way.

Interoperability can be improved if no-code platforms:

• Have good API coverage and better rate limits so developers can trigger actions in other systems more easily
• Have first-class support for webhooks or other “escape hatches”
• Build first-class data connectors from one store to another

Dropping down to code when needed

Developers will often want to drop down to code to handle a complex task in a workflow, without having to re-platform. Scripting is common in no-code platforms, but the best form of scripting would involve support for multiple languages (especially TypeScript for error-checking), support for libraries (npm modules), and version control.

As a stop-gap, Zapier allows users to trigger AWS lambda functions from Zaps. Airtable gives a scripting sandbox for simple JavaScript, but it's not a full-featured scripting environment.

The best example is Pipedream, which lets users connect APIs together with “code-level control when you need it — and no code when you don’t”.

In this example, Pipedream user can select one of Pipedream's pre-built steps in a no-code UI to connect to Google Sheets, then modify the code as needed. Pipedream also allows developers to use most other npm packages, unlike other code sandboxes that often heavily restrict what sorts of libraries can be used. Pipedream will also launch support for Python, bash, and Golang runtimes soon too.

Open-source, at the limit

Open-sourcing prevents vendor lock-in, allows self-hosting (which can be cheaper than many of the traditional SaaS offerings), and allows for more flexibility in modifying core attributes of the no-code platform.

We've seen some hyped open-source no-code platforms come to the fore:

• n8n offering an open-codebase Zapier alternative, operating under a fair-code system
• Supabase offering Supabase Studio, their no-code database CRUD GUI
• Nocodb offering an open-source Airtable alternative

Evolvability

The second theme, evolvability, describes how easy it is to iterate on a business-critical system once it's already in production.

Let’s say that we have to modify the Airtable schema to support a new workflow. This may trigger any number of downstream changes in Zapier logic + other platforms.

In order to test these changes holistically, I’d have to duplicate every single Zap in the logic chain. Then I’d prefix them each with [Testing] or [Dev]. Then, I’d need to load/make fake test data so that I’m not testing on production. Then I’d test every single Zap sequentially. If the tests look good, then I’d coordinate downtime so I could cut over to a new system in the middle of the night. If I notice any issues in production, I would then have to roll back.

Rolling back is extremely error-prone too. It involves hundreds of clicks in the UI to restore the old schemas and automations, and each action is an opportunity to misconfigure the system. So, in short, this process stinks.

In today’s no-code, it's easy to build a v0. But, it's extremely fragile and brittle to iterate on once in use as a production system. In practice, this means iteration does not happen at all.

This is one of the biggest reasons why today's no-code has been relegated to “trivial” workflows — not because it's impossible to build complex workflows, but because any non-trivial amount of complexity is unmanageable over time.

We need to bring more concepts from DevOps to no-code, starting with version control and observability.

Version control

Here's the ideal state: once a no-code workflow becomes business-critical and deployed into production, you should be able to version control it.

In order to do this, you should be able to 1) declare the configuration of a system (schemas, logic, etc.) as code, and 2) version control this with git.

This should be able to extend to as much of your system as possible — not just data structure, but logic, and even no-coded UIs. This borrows infrastructure-as-code / GitOps from the DevOps world.

Developers would be able to control the entire state of their no-code workspace as files in a git repo. This unlocks necessary features for evolvability:

• Developers can “protect” a no-code workspace used in production just like they would a master branch to prevent from one-off user-error in system changes.
• Making changes to this workspace can be done with branches.
• All production changes are documented.
• YAML files could also point to different environments for testing, staging, prod.
• Workspace changes get bundled up into a single atomic step.
• Rollbacks work. Testing works. Workspace history is visible.

Today's no-code platforms normally don't offer this. Airtable lacks even the API endpoints to create a new table, or create a column. Zapier lacks management APIs too.

But fortunately, we start seeing this shift at the enterprise level. Salto gives developers a way to declaratively configure hundreds of SaaS apps like Salesforce and NetSuite. In a world where enterprise customers can have as many as 874 SaaS apps, cross-app workflows can break all the time. Salto’s infrastructure-as-code approach would let developers bring no-code to scale.

Observability

When something breaks in prod, how easy is it to identify and root-cause the issue? In today’s no-code world, logic is wildly spread out across platforms. In addition to Zapier and Integromat, every no-code platform is building their own logic modules. There is no single pane of glass that helps developers understand the full butterfly effect of a data event.

This makes it further difficult to evolve the system over time. If you don’t even know what’s happening in the system - how could you possibly make improvements to it?

There is a huge opportunity for no-code platforms to offer up better observability and auditability. For example, Switchboard is building an error monitoring and incident management platform for Zapier and Integromat. I’d also advocate for existing no-code platforms to provide more logging and APIs that make it easier to integrate with alerting stacks like Datadog.

No-code, beyond just MVPs

There are 2 billion no-coders on the planet that can build software to solve problems. But everything built in today’s no-code platforms is handicapped. Heavily. And developers can’t extend or evolve these no-code workflows without a hard re-platforming journey.

No-code might be the highest levered tools that unlocks humanity’s capacity to effect change. We can make that happen, but no-code must give developers the primitives they need first.

This is an open call to any no-code platform founder. Make your platforms developer-extensible and evolvable, and no-code might become the defining movement of our generation.