The Biggest Gap in Low Code: Fullstack Web Builders

The Biggest Gap in Low Code: Fullstack Web Builders

With all the buzz around low code, why is it still so hard to build interactive fullstack web apps?

We're all familiar with Airtable and Google Sheets, hooking them up to Zapier to build automated data pipelines and workflows. When it works, it's magic! We've all tried simple website builders like Squarespace, Webflow, or ClickFunnels. Maybe we've dabbled in eCommerce website builders like Shopify. And we're no stranger to CMS systems like Wordpress, the "king of no code", the most mature solution out there, boasting the largest and most active community and marketplace.

In the No Code Landscape above, it's easy to see how these solutions each fill an important gap.  Yet, smack dab in the center, the category "Full Stack Web Builders" seems strikingly empty, populated with only 2 products. And I've only heard of one of them.

There are roughly 27 million software developers around the world, according to the Evans Data Corporation Data’s Global Developer Population and Demographic Study. And they generally get paid pretty well because their skillset remains relatively scarce and valuable. You'd think there would be tremendous value in democratizing one of their core functions: the creation of interactive fullstack web apps. You know... things like Facebook, Reddit, Expensify, or any of these real-world React apps. Yet, besides Bubble, there's almost nothing else out there.

I believe full stack web builders is the biggest gap today in the low code landscape. However, I'm bullishly optimistic that will change. The reason why: the majority of fullstack web development is repetitive. There's a lot of CTRL+C CTRL+V going on that will eventually be automated or commoditized -- I'm looking at you StackOverflow!

Let's take the typical life of a fullstack React developer as an example. You're tasked to build an amazing SaaS app that uniquely solves a pain point for a target customer. Your dream come true, showering you in rocketship stock options galore! But instead of spending the majority of your time thinking through the app logic and iterating on it, your day-to-day reality is building out all the scaffolding and infrastructure around the core logic of your app. For example, scaffolding such as login, authentication, settings, billing, user and team database tables, sharing, admin dashboard, email notifications, routes, figuring out what libraries you want to use, deployment scripts, testing, hosting, pixel-perfect CSS, button transitions, and the list goes on. Sound familiar? Another example, if you want to use Redux the library, you need to structure how you want to bring it into your codebase. In fact, you may need to restructure your entire existing codebase just to accommodate this library.

Let's be even more specific, just to illustrate the point. Imagine you're building a TODO list app. Or if you think this is too simplistic, instead imagine building a PM tool (which is a glorified TODO list app anyway). First, you choose your stack. As any good developer would do, you've decided to go with what you already know — React + Nodejs on the backend. You start by copying the create-react-app template, which most developers don't deeply understand under-the-hood and will run into issues extending later on. Next, you bring in redux, reselect, redux-thunk, react-router, react-dnd, some fetch libraries, etc. Then, you structure your pages and actions and wire everything together and you have a pretty good architecture and page layout (after 1-2 weeks of work). Now you're thinking — I need "Users". They have an email, name, password hash, some stripe integration so I can charge them. So you make some React pages to handle authentication, client API calls mimicking what you have on the backend to handle sessions, then password reset, email confirmation, hooking up to an email provider, etc... all this boring scaffolding that you know and that you derisively mock as "easy", and which devise in rails does very fast (although obscurely).

Once you've made enough progress on all this scaffolding, you write your migrations, add a bunch of routes, replicate your API and client, test everything, spend another few days making sure you catch all the errors and transmit sane feedback to the User when things go wrong, and after a few solid days of work (perhaps a week or 2 for non-Senior engineers), hopefully you have a Users table and some authentication logic. Unfortunately, not much to show.

You haven't even started implementing any logic yet. Now the same story repeats and you add:

  • billing
  • team management
  • user settings
  • CRUD endpoints (replicating client and server logic)
  • background jobs
  • photo upload
  • deployment scripts
  • optimistic client updates
  • keeping data in sync
  • restoring from localstorage
  • .
  • ..
  • ...

The list keeps getting longer and longer before you can move onto implementing your app logic. Remember what your app was supposed to do? I almost forgot — you're building a TODO list app or a PM backlog (same equivalence class anyway). When you finally reach that point, you realize it'll be fine to start with having a 'title', 'description', 'creator_id' and 'created_at' fields. So then, you move onto writing boilerplate CRUD endpoint for your newly created TODO item, then wire routes on the frontend to display all the items, filter them, delete, update them, include optimistic updates, replicate your API logic in the frontend (writing a mini API client mimicking CRUD endpoints you have on the backend). Eventually, you end up building your own mini framework and maybe decide to re-use it later or you just give up, forget about it, and copy paste it later for another project. Either you copy paste, or most often, fullstack developers end up with their own version of the framework consisting of the same libraries, wired slightly differently, a massively parallel fragmentation of the entire ecosystem! The javascript ecosystem fragments even further and you end up writing a long (140 chars) twitter message "JS SUCKS PLZ FIX".

Of course, you might say it's because the javascript ecosystem is so fragmented. Perhaps if it was properly fixed, you wouldn't be drowning in the choice of libraries. Just like that infamous supermarket study, too many options paralyzes you, indecision. But I doubt that's possible in a vibrant ecosystem — developers are excited to innovate and produce more libraries and that's truly what makes the ecosystem thrive and makes picking it up so easy that even non-developers can take some courses and start making apps — because there is so much information online.

It's true there are frameworks like Rails with more opinionated out-of-the-box modules and guardrails for the developer experience. But React is the most popular web app framework in the world, enabling developers to build far more interactive and responsive apps compared to Rails. Even if you use Rails as a backend API, you still have to wire it together with the React frontend — all of that is what I'm calling "scaffolding". In addition, Rails apps also tend to become a cobbled mess after a few "shortcuts" outside the guardrails. With Rails, whenever you want snappy interactive logic on the screen, you're stuck either integrating react views or writing a bunch of unmaintainable javascript snippets to change your green button to red, or to inject some error message dynamically. Yuck...

At this point, I've completely forgotten the app we were building... we've spent so much work, effort, time on the scaffolding instead of the app itself.

In conclusion: you're probably spending less than 20% of your time on the core logic of your shiny new SaaS app, the logic that makes the app uniquely differentiated and interesting in the first place. You spend most of your time building and debugging the scaffolding, which is largely repetitive from app to app. Yes, all the other React engineers in the world are doing the exact same thing, a mass-scale copy pasta. And honestly, we're all paid pretty well so why change the status quo. I'm reminded of the well-worn joke about data scientists — 99% is being a data janitor, cleaning up messy data sets, while 1% is the interesting machine learning work. Well, the joke's on us fullstack developers too. Most of our time is scaffolding; we spend relatively little time building our web app's unique logic.

Yet, the logic is the most important thing, defining what actually happens on the screen. And this is largely driven by your data model. If you have a "User" model, perhaps that "User" can have multiple "Followers" or "Todo" items. That "User" should also be able to login, change their password, and see their profile stats. The data model comes first, then what actions are possible.

In an ideal future world, I envision fullstack React developers liberated from all that mundane repetitive scaffolding, and able to focus on what a web app actually does, what the user sees and does, what happens nexts, and how the user experience can be improved. You might say, "Well, that sounds like a designer, not a developer!" Kind of... but it's really more like an Architect. Imagine for a moment there exists a fullstack app builder that intuitively unites the 3 primary layers: Data, UI, and Events. Instead of spending most of your effort building the scaffolding you need to power these layers (i.e. what you do now), you'd be able to focus on architecting your app's Data and UI and Events, and orchestrating them all together to enable your app's core experience. Because at the end of the day, the ideal developer experience is being able to efficiently build an app that does something useful. You shouldn't have to worry so much about all the library plumbing and wiring things together.

Companies like Bubble and Crowd Machine, the 2 mentioned in the landscape visual, are building towards this ideal future world. Yet, they both have a long, long, very long way to go. In another post, I'll detail their pros and cons and limitations. For now, I believe fullstack web builders is currently the biggest gap in the low code market, and I'd personally love to see more teams throwing themselves at this tough but invaluable problem.