Can No Code Tools Finally Deliver on the Custom App Promise?

For several decades technologists have pursued the dream of non-technical people wiring together components to build custom applications. Unfortunately, it has proven to be little more than a dream. These tools are great for demos, prototypes, and very vanilla apps, but eventually you hit the “functionality ceiling” and it hits so hard that you end up scrapping the app and rebuilding from scratch. Are the current crop of low-code/no-code (LCNC) tools destined to hit this same ceiling? I believe that a couple of innovations may help them break through that ceiling and democratize app building. 

A Historical Perspective

The dream of LCNC goes back to the mid-1960’s with Mathematica Products Group. But the real hype-cycle started in the mid-1980’s with Apple Hypercard and Joe Firmage’s Serius Corp (acquired by Novell and renamed AppWare before being sold off). I knew Joe when he was at Novell in the mid ‘90’s, before his alien encounter; which is an interesting story by itself.

In the 2000’s we got PowerBuilder, and then later PowerApps, Mendix and OutSystems. And of course, today we have two new trends in this realm: vibe coding and flow-based agentic AI builders. My company, ComponentFactory.AI, is merging these two latest trends. In every case thus far, the solutions have delivered great demos, prototypes, or even MVP apps, but have fallen down in building an enterprise-capable app that can evolve over time.

Theory vs. Reality

As a long-time software product guy, one of my go to truisms is: “Do you know the difference between theory and reality?” “In theory, there is no difference, in reality there is.” In theory, LCNC tools should be flexible, powerful, simple, etc. They should be able to build enterprise applications, but in reality they couldn’t. It all comes down to the functionality ceiling. LCNC tools trade flexibility for ease of use. In my experience, that tradeoff makes sense for a demo, prototype and even minimal viable product (MVP). The problems arise when you get to versions 2+. That’s when you start discovering that the pre-packaged components cannot do what you need them to. This is when no-code fails. These components are little black boxes that you cannot modify. You can default to low-code to extend things, but at some point even those hit limits and you realize that you’ve painted yourself into a corner. Eventually, you bite the bullet and rewrite the whole app…ugh!

The 90/10 Rule of Software

Another truism of the software development business is the 90/10 Rule that says: “The first 90% of a software project takes 90% of the time, the last 10% takes the other 90% of the time.” Of course, many of us chuckled to ourselves when Chamath Palihapitiya of the All-In Pod launched 8090 claiming to deliver 80% of the features for a 90% discount. This is basically the 90/10 Rule meets vibe coding. If you are willing to accept 80% or 90% feature complete, great, easy. But how does it get to 100% and evolve over time? How do you get under the covers and tune performance? This is where theory runs headlong into the reality ceiling.

The Devil is in the Details

There are a number of reasons LCNC solutions have historically fallen short. Here are a few of the details that derail them:

1. Unhappy Path: Users don’t think like developers in a simple linear workflow. They try different paths that can leave them unhappy because LCNC doesn’t handle flexibility and unhappy paths well.
2. Use Cases: Software is built to address use cases. We recently built a tool for accessing lockers that stored sports equipment. The initial version was limited to one locker access at a time. You could get a soccer ball OR traffic cones. But what if you want both, because you need the traffic cones to outline the field? This sort of use case clashing with reality needs to be addressed. This is often called corner cases or edge cases. Over time, they become the majority of the work on software.
3. Performance & Scaling: You used LCNC to build an app and user adoption spikes, but the app slows down in key functions. How do you crack open the black-box components and start tuning? How do you shard the database to spread the load? How do you create materialized views to reduce joins? You don’t.
4. Vendor Lock-in: You are beholden to the vendor to add the new features you want, it is not in your control. Even in open source solutions there are hoops to jump through and your changes may not get merged and maintained, or they might merge something that breaks your app.
5. Securely Integrating Data Sources: You might have proprietary data sources you need to access or exploit, good luck, get in line. 

I could go on, but you get the idea.

Flow-Based Tools & Vibe Coding: Similar Problems

Flow-based LCNC tools have the same issues, they are only as flexible and powerful as the components you are wiring together. The structure these provide is nice, they guide you through the process, making it approachable to anyone. For agentic AI, they are quite nice, but as you start hitting the issues above, the standard components will hit the functionality ceiling. This is where you’ll need to build custom components, meaning more coding.

If you talk with people doing vibe coding it does a great demo, prototype and even MVP. This may be fine for testing product market fit (PMF) with initial users. At some point you run into the functionality ceiling when you try to evolve it, tune performance, etc. The good news is that you have the code, so you can drop down into the code to start working on it, assuming you have those skills. In this case at least you are not painted into a corner where you have to rewrite the whole thing.

With both of the above tools, accessing legacy applications and data stores is a problem. Model context protocol (MCP) provides a standard mechanism for accomplishing that, so that too is a piece of the puzzle that is now solved.

The Chocolate & Peanut Butter Moment

I often refer to the old ads for Reese's Peanut Butter Cups where two people collide mixing one person’s chocolate with the other person’s peanut butter…an awesome combo. The core vision of ComponentFactory.AI is that vibe coding and flow-based LCNC tools are the killer combination. This combo could finally break the functionality ceiling that has continually crushed the hopes of techno-optimists for a democratization of app building. Let’s breakdown why I believe this combo may do the trick.

Vibe coding, basically prompting AI to create the code to define your application is a great start. It enables you to build a very cool prototype or MVP, but this model lacks the structure of pre-built and re-tuned components. In other words, you have the blank canvas issue of where to start. What most users want and need is the outline of an app that they can fill-in. They want a little more hand holding.

Flow-based tools are pretty good fit for building AI agents. They combine the structure of components you can wire together. AI adds some flexibility to the app. The components provide the deterministic (consistent results), complementing AI’s strengths in the realm of the probabilistic (creative, but inconsistent results). But you still need to code custom components to address corner cases or new functionality. The functionality ceiling still exists. ComponentFactory.AI provides the structure and guidance, think paint by numbers, for building these custom components using vibe coding. This approach delivers a 45X - 60X speed improvement, while enabling non-coders to build custom components. You describe what you need and it builds it. Behind the scenes it leverages components templates, AI-powered testing, transcoding to various different tools, and more. In essence the paint-by-numbers is overlaid on your prompts and the testing ensures that the resulting components actually run without error in each flow-based tool. This is the chocolate and peanut butter combination that solves the functionality ceiling. The performance and scaling issues can also be addressed by leveraging AI for reflection. Reflection is basically the AI monitoring the app to recommend or implement optimizations for scaling and performance. Because AI has costs, reflection can also be used to optimize AI costs by moving some processes from LLMs to SLMs and other such optimizations.

Does this truly solve all LCNC problems today? No. It isn’t a one-time event, it’s a process. But this combination does start us down the path to democratizing building agents. Those agents will start by implementing custom workflows that interact with existing applications and data sources, breaking down silos. Eventually, they will start to eat monolithic applications by breaking them down into a series of custom agents. We may be at the cusp of delivering the vision of the pioneers like Joe Firmage.