No-code tools are great for building your MVP, but what happens when you get traction?

Every software has a scalability limit. My goal in this post is to help you predict when your no-code stack will hit that point. Then if you find you need to move to a code foundation, you know what to expect and can plan for it.

Impediments to scaling

To figure out your timeline for how long your stack will last, the primary variable is simply how much of your stack consists of no-code tools. For example, is your whole customer-facing app built without code, or just internal tools like spreadsheets and things that customers don't interact with?

After that variable, there are four key areas to focus on when assessing scalability:

• infrastructure failing
• lack of ability to build custom features
• nascent professional community
• lack of collaboration tools

The following sections will talk about each of these areas and why each has it's own scalability limit, which triggers the need to migrate your web app's foundation to a code-based system. They are centered around early stage startups (Series C and below) and SMBs using consumer-grade no-code tools.

(For larger companies using enterprise-grade no-code tools, some of the advice is different and I'll probably follow that up in a separate blog post at some point. If you're a larger company looking for advice, feel free to DM me on Twitter.)

How much of the app is on no-code tools

Simply put, the more of your app is built on no-code tools (versus code-based tools), the less it will scale. There are three primary ways I see people using no-code tools:

1. Marketing website - the marketing website (www.yourwebsite.com) is on Webflow or Wordpress, then the app is on a subdomain (i.e. app.yourwebsite.com). This is very popular these days.
2. Operations - part of the team has workflow automation tools like Zapier hooked up, Google Sheets or Airtable is often being used. Every company has some element of this.
3. Customer-facing app - whole stack is built on no-code tools, with some code sometimes peppered in-between. This is a new approach to development that has spurred the term "no-code".

When thinking about scalability, the first question is, how many of these ways are you using no-code tools? If it's just your marketing website, you can probably scale to nearly any volume you'll realistically need (unless you need the design to be highly custom or create thousands of dynamic landing pages). Your operations tools will usually last 1-2 years of exponential growth. Your customer-facing app may only last a few months depending on your growth rate, or it may be a non-starter.

Infrastructure

The most frequent reason for why no-code tools stop scaling is because of the database. Firstly, the data model usually gets setup poorly since it's not an experienced developer who's doing it. Then in addition to that, most no-code databases simply don't have great performance once they have tens of thousands of rows of data and calculations being performed on top of them. They weren't designed for people to build production web apps on top of them, or if they were, they're catering towards consumer users who are just getting started with their applications.

Often, I see no-code databases starting to slow down once they have 1-10k rows of data, and then they start to freeze entirely (for up to minutes at a time) somewhere around the 20-50k row mark. 

This might sound like a lot of data if you're just starting, but it’s barely enough to hit profitability if you’re a product-based business with a lower customer lifetime value (LTV) in the $100’s. Generally, the faster your company grows, the more users you have, and the faster your database will break down. So to ensure your growth doesn’t plateau because your no-code app can't scale anymore, you should have a migration plan to rebuild your app's foundation in code at least 2 months before you’ll hit 20k rows of data.

To make these matters worse, there are no aggregated reports showing performance metrics like your app's speed and error rate across your stack. So if I'm using an Airtable or Google Sheets database to serve data to my users, I could individually test how long the responses are, but I can't see what the average performance was yesterday, or this week.

If you're building a customer-facing web app, you can mitigate most of these infrastructure concerns by using enterprise no-code tools, which can scale  database up to millions of rows. That said, I have yet to see any startup or new business use enterprise no-code tools at the start. This is mostly because they're cost restrictive (often annual commitments and thousands per month) and often don't have the same integrations and slick UI/UX that you find with consumer no-code tools. Admittedly, I haven't explored enterprise no-code tools much lately, so maybe the integrations and UI/UX are better.

Features

You can build most standard features like user logins and payment processing functionality with no-code tools. When you need to build advanced features, there are a handful of custom addons to integrate into your app. A few of these more custom add-ons are:

• membership and signups with Memberspace or Memberstack
• forums and communities with Circle or Discourse
• custom API development with Standard Library
• internal tools with Retool and JetAdmin
• advanced filtering with Jetboost
• advanced instant search with Algolia
• multilingual support with Weglot
• machine learning-powered prediction modeling with Obviously.ai
  

That said, there always reaches a point when you want to provide a better user experience through a new or more customized feature, and the no-code tool can’t do it. At that point, you have to start writing code inside of the no-code tool. Often what happens is solutions get hacked together this way for awhile. Then, eventually, you spend more time writing code and maintaining it to support a feature than if you just coded the whole thing from scratch. But then your no-code tool can't scale any more, so you have to rewrite it in code next anyway.

When you start hacking solutions together with code, you should also immediately start planning to migrate your foundation to code.

Community

With any job, you can train someone internally or hire someone externally. If you hire internally, you have to budget for the team member learning how to use the no-code tools and build the app (unless they already know how, which is rarer these days).

If you hire someone externally, then they already know the software so you can move faster. Plus they have a degree of experience building a more complex and advanced app.

Currently, the supply of no-code developers and agencies is far greater than the demand. Anecdotally, I'd estimate in the high hundreds or low thousands of entities explicitly marketing themselves for this service. Then when it comes to ones who've worked on apps that have scaled 2-10x farther than yours (assuming you have a few thousand rows in your primary database table), there are far fewer. Most of the freelancers experience is centered around prototyping. All of these variables mean you'll be quoted in the range of ~$150+/hr for these freelancers. When it comes to full time employees, I have yet to see a job posting for a "no-code developer", so you'd be hiring someone from freelancing to a full time capacity.

Now looking at a code-based developer (like one who builds apps with Node or Rails apps), you can hire great ones for $50-100/hr. This is simply because there are millions of developers out there. Then when looking at their experience building apps that scale, 90%+ or more of these developers will have experience working at orders of magnitude higher scale (100x-1,000,000x or more) than you're currently at.

Collaboration

Once you get past two people, collaboration features become critical. A few of these features are:

• Version control: this quickly becomes critical, otherwise knowing what's changed becomes difficult with even just two people.
• Code review: or reviewing the update before it's pushed live to users.
• Permissioning: controlling which team members have access to develop on which pieces of the app or database.

To laser in on version control specifically, a few no-code apps have even simple version control tools built in. At most, there's nothing universal that can spread robust version control across your whole web app like Github.

To illustrate further, Zapier is the most popular workflow automation tool in the world with tens of millions of users, yet it has no version control features. You have to store your old workflows as copies of files yourself with labels like v1.1, v1.2, etc., which quickly gets messy, even with just one person working inside of Zapier. Not having this one feature translates to reduced business efficiency and higher costs of development over time.

Without going into code review, permissioning, and others, you can probably see how a lack of features here can only take you so far.

Takeaways

So should you build your prototype on a no-code stack? Most likely, yes! You won’t get the same speed and agility in a coding environment while you’re small. It could mean the difference between getting the company off the ground or not.

If you're already on a no-code stack, should you plan to migrate the foundation to code? That depends on how big your ambitions are.

Post supported by Content Allies

Content Allies produces thought leadership content. They interview you, and then turn the interview into articles, podcasts, videos, and social posts. Learn more at ContentAllies.com

‍