No-Code: Just The Hard Parts
No-code gets a lot of ink as a revolution in how we all can build. I think of it more incrementally and in the context of jobs and demographics that I have discussed elsewhere. But to think of it incrementally is to think of a spectrum of tooling. That requires analysis beyond just how friendly Webflow's user interface is.
My sons contrast their block coding on the likes of Tynker with "type-coding" they see me do. I did not realize until recently that there is a term of art out there specifically to contrast with no-code: pro-code. Clutch, a visual code generation service, explained the distinction to me:
Note how all the tricky bits go into "pro-code." Issues of planning and version control are in this last category. This links with the "just do it" culture that I see in quite a bit of the no-code builder community.
The marketing of no-code tools essentially fits this model. I keep seeing "easy" and "fast" as selling points for no-code offerings. The flip is the implication that they are "flimsy" and "unscalable." Notwithstanding the capabilities of the underlying product, the marketing in one will lead to the perception of the other.
And for rapid prototyping, why not ignore the complex parts? I have talked with several would-be entrepreneurs who are building a "quick demo" in one no-code tool or another with the expectation that they need to raise money to create a "real" application after that. The theory, just like in the tweet, is that the complex parts of making it "real" go hand-in-hand with "type coding."
A second use case for no-code is going to be the customer of one. Using no-code tools to build an infrastructure or app for oneself is a typical second project for people learning to work with no-code tools. (The first is cloning some banal service as part of a tutorial.) But I have seen a couple of cases of building an app for a single person.
This utterly bespoke approach at the app level fascinates me because it focuses on serving specific needs rather than the fun of creation. Your customer-of-one does not care about what you can do, but only what you can do for them.
The tooling shifts the focus from technological wrangling to need fulfillment. This focus on one customer means that the solution snugly fits the one user like a Saville Row suit. They perceive it - and themselves - to be powerful. If one can bend the power-usability curve through customer segmentation, moving to a segment of one generates extraordinary returns. I saw this approach using Glide to make the app-for-one.
Another "customer of one" approach is the rat's nest of back-end or marketing automation that a consultant or enterprising employee wires up for a department or organization in Zapier, Integromat, Power Automate, and the like. These connections are often measured on creating value - now. The aggregate complexity piles up fast.
So the trade-off of using no-code could be the lack of utilities that facilitate scale through prototyping or bespoke delivery.
But just because problems are complex does not mean they have to go with terminals and keyboards. Github offers through its web app and desktop apps a no-code interface. Unit testing may be more challenging with a no-code structure, but end-to-end testing is relatively straightforward. Pipelines from development to testing to production would make building far less risky, and often these are administered today through tools that do not themselves require code.
These hard parts are internally no-code. To connect with other parts of the development pipeline, they require (wince) pro-code. I see a latent market for no-code DevOps. Connect no-code expressed intent with best practices for continuous integration and delivery. Achieve scale.
No-code DevOps is a field that doesn't exist yet. It will start as so many industries have: bespoke consulting. There is a problem here that initially has only a few vendors struggling with this divide. As best practices emerge, the discipline will productize. Tooling this concern will become critical to deploying no-code tools for more than prototyping or the "customer of one." Making the whole spectrum accessible without "type-coding" is how we further shrink the day-to-day importance of pro-code and gain value distribution.
As Yogi Berra once said, it's tough to make predictions, especially about the future. That said, I suspect that some no-code platforms will surface features to make principles of continuous integration and delivery available to their customers. Legacy fully-integrated packages will find that opening the door for better staging introduces significant technical concerns, while some new entrants will be DevOps-first. We are already seeing no-code platforms position themselves as upmarket relative to established players; I think Xano has this relationship vis a vis Airtable. Others are enterprise-native, such as Microsoft's PowerApps product line.
In "The Jobs of No-Code," I suggested the domain expertise rather than strict software development training would drive maximum value. It seems that looking at what is still hard in the pipeline of value and determining which bits can get the no-code treatment will let us become better experts and our customers better served.
Special thanks to Joel Christiansen, who gave fantastic feedback via the Foster community.
Photo by Chris Pagan on Unsplash
