Debunking the Low-Code/No-Code Myth: A Real-World Perspective from a Custom Tooling Agency

We focus a lot on MVP's and custom tools for small businesses at Cause of a Kind. Many people ask me why we aren't embracing more no code and low code tools. For me there are a few parts to that answer and one of which involves the recent "AI revolution (and yes, I'm cringing as I write that too)."

The other day I saw a tweet talking about how two programmers were pitted against one another. One leveraged a series of low code platforms, the other wrote all their code from scratch. The author boasted how the low code developer cost 1/10th the price and delivered in 1/4 the time. They said they were done with "coders" and instead wanted people that embraced low code and no code tools entirely.

This rubbed me the wrong way because as an agency owner and operator, I have a vested interest in faster development at a lower cost. The problem is, I have not found the above to be true. Perhaps if pitted against a programmer that is truly writing every piece of code from scratch, but this is not a realistic depiction of how we build custom tooling for people.

I've experimented a lot with tools like Webflow, Bubble.io, Framer, and ReTool all with the hopes of increasing the speed of our process. Three things seem to happen all the time:

1. They are never as easy as they appear in the instructional videos.
2. The time spent learning to build components in them is time I've already spent building these exact same things in code over the years.
3. There's some odd legacy system, integration, or need that doesn't fit perfectly into the tool itself, leading me to question if it can be done at all.

The Learning Curve Problem

Let's start with the first issue, learning curve. In my experience these tools are still too hard for someone with zero technical knowledge to use. The reality is many people find Shopify and Squarespace hard to use when they don't have the right mental model for how they work. These tools take that sophistication to another level but this puts them in a bit of a no man's land. Too hard for someone that's non-technical but not powerful enough once someone obtains the skills to code. Therefore they end up being liked by some, but loved by no one.

The other issue with spending time learning a proprietary tool is it's not transferrable knowledge to other tools. So when you have a client that can't use a tool for certain reasons you end up having to find a new tool and repeat the process of learning it all over again. This could be because of the tools capabilities, performance constraints, or the pricing of the tool itself.

When it comes to pricing, those of us that have bought SaaS tools long enough are no stranger to a company suddenly changing it's price tiers or removing options. I'm not faulting them for doing this, every business needs to become profitable at some point, but it's become standard practice to start with unsustainable prices and then gradually raise them as investors demand you show some profit. Any customer of a headless CMS over the last 5 years has seen this happen. There's two classes of customers free and really freaking expensive. I worry about this same phenomenon happening in low code tooling and your product coming too far to turn back. Now you either pay the new price or spend the money building the whole dam thing anyway. Vendor lock in with a single service or component is one thing, but locking your entire platform in like this feels too risky.

The Easy to Build Components

The next advantage I've heard is it's so easy to build things like authentication, charts and graphs, slideshows, animations and more! The problem with this is, I'm not building these things from scratch anymore either! Saying low code helps with auth and log in is cool, except is anyone actually building their own encryption and authentication packages from scratch? After a number of years everyone likely has a library of components, modules and packages they re-use over and over again across projects.

The best part is when there are differences or integrations that need to happen, we know these components inside and out and have full access to modify the internals on a case by case basis. No vendor lock-in, no road blocks.

Some may say, "but you have to maintain those components!" To them I say, sure, but how much maintenance have you needed to do to your regular components over the years? Our authentication libraries rely on a combination of custom code and packages that receive regular community updates all the time. I'm willing to bet that these same packages sit underneath your favorite low code editor too you just don't realize it.

I've even noticed most of these low code and no code tools make you even less efficient over time that written code. While it's easy to drag and drop boxes around often faster than writing the code the first time for these things, you now need to repeat this process over and over again for each new project. So you gain speed up front, but sacrifice the re-use of those components across projects and sometimes even within environments (staging and production) on the same project.

What I've found is people greatly underestimate the amount of code re-use of an experienced developer or organization over time. They also underestimate the value of someone truly understanding how all the pieces fit together as well as being able to mirror environments exactly and end to end test all components thoroughly.

The Edge Cases

The third problem is the unknown barriers issue. Every person moving into low code / no code has to attempt to do an up front analysis of the most complex components in the system and see if they are possible. We have to evaluate the technology with all the pressure of a waterfall build, the perennial "just tell me how much it costs," problem.

The argument I usually hear about this is, "everyone re-writes their MVP anyway." I have not found this statement to be true. While I will agree that most people do end up re-writing their core platform, you can either set your customers up to do this in an evolutionary manner or a revolutionary one. In the case of a low code or no code code base, this has to be done more on the revolutionary side. This means your re-write is often happening in parallel to a system that's already strained by a growing customer base that finds value in your tool.

All this being said, with these tools you're trying to estimate things up front that are just not easily estimated. Prior to gaining product-market fit you won't be able to see around very corner as you evolve your MVP. To think you can see all the edge cases before selecting the tool is a folly. Existing frameworks with great developer experiences and many robust, community supported packages is the safer bet. You can work in an agile fashion and don't have to spend time worrying if you've come too far into using one tool that you can't pivot back to something custom should the need arise in the product discovery process.

It's important to remember product market fit can take months and years to establish not weeks. Most founders are way more optimistic than reality, thinking if they get their prototype out in weeks the flood gates will open and the world will realize the tool they've been pining for is finally here. The reality is far more bleak. We advocate releasing as fast as possible so you can see how wrong you were early and use that early feedback to massage your product into the place it needs to be in the market quickly. We don't try to predict where the problems are, we want to expose them and pivot away from them early. It's quite hard to code yourself into a corner, but easy to choose a tool without a critical ability you need later in the process.

The Rise of AI Driven Programming

I wanted to touch on this part as its own section. One thing that was not the case before a few months ago was genuinely effective AI assisted programming. Tools like GitHub Copilot and ChatGPT are fast becoming a developer's secret weapon when authoring code. As a person who both designs interfaces in figma as well as codes them I personally have found myself preferring a simple description of what I want and letting my Github Copilot assist me in authoring a component. When you have this power in your toolbox drag and drop tools like Figma feel tedious!

You're already seeing a plethora of tools come up in the form of prompts for these GUI driven development tools, but the power you gain when it's working inline with your code is second to none in terms of speed. I'm hedging that the GUI is no longer going to be the best method to bridge the gap between what we picture in our minds and what shows up on the screen. Humans have evolved alongside character driven languages for ages. It's going to be hard to compete with natural language and typing speed.

I think a great project to watch is Darklang, where they've embraced the idea of the programming language being the right medium to build applications quickly alongside integrated visual tools. Recently they've all-in on AI as the next evolution of their language and platform. I'm truly excited to see where this takes us.

Conclusion

For us, it's easy to see why people take the short route and opt for early speed gains with no code and low code tools. These are great platforms for a great many use cases, but they aren't a great fit for our clients looking to build new software platforms. The speed gains for us are negligible and become speed bumps as the software grows over time. The time spent learning one platform doesn't transfer well to another and locks our customers into expenses that are not easy to predict or exit from when the time is right. Vendor lock-in is very real and virtually impossible to escape once you've gone all in on one of these platforms.

These platforms are not a replacement for sound solutions architecture. They still require quality logic and for complex systems they are not going to enable lay folk to take shortcuts without risk. Most of my value comes from discussion, listening, and problem solving with the lightest touch possible and consideration for the future of the tool. We want to be able to solve these problems with all the power of the most appropriate solutions at our disposal in the marketplace. We don't want to be restricted to a platform or a template. Today, the low code and no code solutions I have seen can enable initial speed, but hamstring us. You spend more time thinking about what could be done rather than what needs to be done.

In a world where our efforts can be assisted by AI, the GUI as a means to shortcut learning seems superfluous. Nobody wants a magic wand with buttons they want the magic to flow from our thoughts, in anticipation of our actions. It’s why copilot feels so magical, relegating drag and drop coding to the level of guitar hero.