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, and 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 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:
#NoCode: Complete abstraction from code. Ex: our visual editor that writes @reactjs & CSS under the hood.#LowCode = Small blocks of code only where necessary. Ex: custom logic, data connectors, etc...#ProCode = Editor + terminal + build tools + git + sprints + long backlog
— Clutch (@clutchcreator) July 9, 2021
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 fascinates me because it focuses on serving specific needs rather than fun with 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.
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.
This offering can initially be consulting - there is a problem here that initially has only a few vendors struggling with this divide. But later, tooling this concern will be 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.
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.
Photo by Chris Pagan on Unsplash