I read this postmortem today from a YC company that pivoted from their first idea as a no-code reverse-ETL tool. The post was interesting to me for a couple of reasons:
- My current company Census is in the same space trying to solve the same problem they pivoted away from
- The problem they ran into that ultimately led to their pivot is a problem I believe exists more generally for a number of companies specifically in the no-code space.
Regarding (1) Census actually ran into the same wall they hit but we have a very exciting solution that we are actively shipping and we’re confident this will turn into one of our greatest strength as a product. I’d like to write a post about that but for now I want to focus on (2) and it’s how I see this problem affecting no-code tools that exist today. The problem is this: no-code tools are sufficiently complex that non-engineers are unwilling or incapable of effectively using them while engineers are unwilling to use them because they don’t actually make our lives significantly easier where it matters.
No-code isn’t a new concept with products like Wordpress, Squarespace, Wix, Shopify, etc. pioneering the space in different ways. Historically, though, these tools focused on static sites or domain specific problems such as e-commerce. Recently there’s been a crop of new VC-funded tools like Webflow, Bubble, Thunkable, Adalo, and many more that aim to allow for the creation of general web and mobile apps with much more complex lifecycles and abilities. They’re interesting and they show promise but I believe they operate in an uncanny valley-esque situation where they don’t actually solve the hard part about building apps making them too difficult for most non-engineers and not useful for existing engineers leading to their TAM being quite small.
I first noticed this problem with tools designed to simplify the building of tech in high school. Both of my parents own small businesses and I have watched them on more than one occasion struggle to build websites through Squarespace and Wix. It didn’t matter that those tools were barely more than templates with customizable sections– not even flexible enough to be called drag-and-drop– it was still a challenge for them. After spending hours on a site they’d end up with dark font on dark backgrounds, overflowing paragraphs and images, misaligned buttons, etc. I consider both my parents to be smarter than average yet they are certainly not technical and those no-code tools to build simple static pages were still not easy enough. I’m not sure either of them would stand a chance with Bubble or Webflow which indicates to me that neither would at least half the population. Beyond just writing the code there are patterns and concepts around building a functional site that they didn’t understand at the time which meant their ability to use these no-code tools effectively was limited. In the end they both had someone else build the sites for them.
Since then both my parents have become more tech-literate and they’ve actually become quite capable at times especially when using things like Canva and Wix so I do not think these tools were failures– their success financially is well established– it’s just that at the end of the day they are used to build simple products. Creating an average web app with the features and capabilities expected by users today is an order of magnitude more complex than creating a static site with Wix. It may be that in time individuals like my parents will learn the concepts around building web apps and be able to use a no-code tool like Bubble effectively but I’m not convinced if for no other reason than because most people have no idea how to model data.
Fundamentally when you take away all the implementation details my job as a software engineer is to design a system to solve a specific problem under certain constraints. This amounts pretty much entirely to:
- Defining the shape and transformations of the data model
- What data is required versus optional?
- What do inputs and outputs look like?
- How does the data transform throughout its lifecycle?
- What relationships exist within the data model?
- Defining the characteristics of the system to allow for the necessary data model within our constraints
- What security is necessary?
- What availability and uptime is required?
- What performance is expected?
- What failure modes are acceptable?
- What should costs be?
The de-facto way to do the above tasks today is to write code, usually lots of it, which is complex and error-prone and yet it’s flexible and expressive and has had decades of smart people creating new languages and libraries and tools to help perform those tasks as easily as possible. I haven’t used a no-code tool that measurably improved my ability to perform any of the above tasks and they often make it harder. Often there’s no clear data modeling part of the tool at all; if there is then you’re probably limited on what types you can use or define. How the data is transformed and manipulated is not easily defined. Properties of the end-system like security and performance and errors are almost always non-existent. Performance and availability are usually just straight up functions of cost for what plan you’re using on a given tool and lack granularity.
The end result is that the difficult part about building full-fledged applications– the reasons why software engineers get paid so much– isn’t any easier which means it’s still a massive barrier to entry for someone who isn’t used to doing that sort of engineering. And for someone who is used to doing that sort of engineering it’s not a great value prop because that person probably already knows how to code and doesn’t find that to be their primary roadblock. To them the no-code tool becomes just another framework or language they need to learn to implement the system they’re envisioning and it’s less expressive and more proprietary with less skill-transfer than what they’re used to.
No-code isn’t destined to fail forever, though. There is certainly a type of person who is smart enough to model these systems and yet doesn’t know how to code or who does know how to code but doesn’t like to/isn’t very good who will find great value in these tools. I just think that’s probably a smaller market than most people realize and the success of these tools hinges upon expanding that slice of people. They can do that by trying to attract more non-programmers and teaching them the requisite knowledge around building systems (hard!), or attracting existing engineers by making their tools powerful enough to model systems as robustly as regular code (also hard!). It’s this second possibility that excites me, though, especially with things like GPT. As mentioned, writing code is slow, error prone, complex, and hard to maintain. It’s a distraction. I can envision a future where software engineering is quite literally just defining the properties of the system and a mix of AI and program synthesis does the work of actually implementing it. Lastly, I think for existing engineers no-code holds an interesting possibility in the front-end space. If I could design an entire front-end in a visual builder such as Figma but also have the tooling to seamlessly hook it up to my backend, manage state properly, handle data fetching, etc. then I think that has a chance to be wildly successful but nothing I’ve tried really nails this yet.
No-code has a future but I do not think it looks like the current rendition of what we’re seeing. At a certain level writing actual code isn’t the hard part around building apps and these tools need to lean more into empowering engineers to model their systems effectively while being interoperable. In the end I suspect the winners of this space will be much more low-code than no-code.