How do I build a no-code app that can scale to millions?

When you start out building your own logic to create your own business processes (eg. If my customer does this, then I want that and that to happen… etc) you may not have asked yourself a really important question: “Where should I build my logic and integration?”

In the long run, building a scalable no-code app requires a separate hub for the logic and integrations. By starting your build in a secure and separated layer, you can...

Re-use your processes with any front-end or database

Avoid data lock-in

Avoid costly rebuilds.

As you scale, the architecture of your no-code project is key to long term success. Building the right thing in the right place will give you the freedom to program as you want, to do and to redo, without expensive and time-consuming rebuilds.

It will also give you the flexibility to switch platforms and to control costs at crucial moments in your growth.

Many no-coders start out building an app that works at smaller scale but then later find they need to rebuild and are left praying for an investor to arrive at a vital moment in their business. The solution, is to build in a flexible and separated stack.

Traditional developers work with a separated stack where there are three separate layers, so the tools and coding language can be selected for each layer according to which is the best fit for the purpose.

When you start building with no-code, you may not notice if you are programming in the frontend or backend, some no-code tools combine all three layers on the same platform. In the beginning it’s tempting to ignore the idea of backend development altogether and just rely on a lot of blackbox connectors to connect to third party apps. These connectors come with their own pre-written backend programming so you never need to write, or interact with, their backend logic.

It’s easy, when working with no-code, to think you don't need a backend and just make your app work by getting the backend of third party apps to do all the heavy lifting.

Firstly, if you’re new to no-code and have no background in coding, it may not be obvious why you would want to use a backend at all.

The advantages of using a separate backend tool for developing business process logic and integrations are as follows:

Anything built in a frontend is viewable in the browser and hackable. So as a general rule, building any automated process that connects with an external source (e.g. third party apps) or requires handling private user credentials should not be done in a front-end.

Essential scheduled tasks that run routine operations should run in the background, independent of user interaction in the frontend. They often form a large part of the underlying day-to-day functionality of a platform. They should not be dependent on any frontend logic running in the browser.

As a business grows, it will usually end up with more than one frontend application; a web app, a mobile app, a customer app or an internal app. Logic programmed in a separate backend means you can re-use the same logical processes across all those frontend applications, saving a lot of programming time. You can also reduce the risk of doing something differently in one. For example, you can make just one update to your backend and it can be displayed across all your front end applications. Creating targeted notifications to different devices and collaborative working are just some of the other functions that should be designed and maintained in a common backend.

Keeping backend programming separate from your front-end will also allow you to switch to a new frontend app builder without needing to re-write or disrupt the core programming of your business. So if you don’t like their new pricing policy or if you want to new features for your website, you can take advantage of the latest and best-of-breed for your user interface. Your frontend applications can be updated as often as you like without disrupting your core workflows and vice versa.

A purpose-built backend tool will allow you to create and customise your connections with other systems without relying on blackbox connectors, allowing you to create processes that are more bespoke to your customers and can cater for more edge cases.

So, a separate back end will give you greater potential for precision in your programming and greater flexibility - essential in the long run if your business is going to be successful.

Apart from keeping logic and integrations separate from your frontend, it's also worth taking a look at why you would want to keep your logic and integrations separate from your database. In other words, returning to the traditional three layer stack.

There are three key advantages to keeping your integration and logic separate from your database as you scale up. Once again, this gives you a level of flexibility as the app grows:

Avoid data lock-in and having to migrate data.

You are free to choose to work with any database or any number of databases.

Go bigger, with databases that can scale to millions.

Why is this so important? Because as you scale you will want to swap databases in and out without affecting the logic you’ve spent so long building to create your business processes. How likely is it that you will want to change database? Very likely…

As you scale:

You will want a database that handles a greater number of records, higher volumes of customers and products.

You will need a database that handles a higher volume of requests across multiple copies of your data (high availability).

You may want to use a database that only charges you for the volume of data you are using (think pay-as-you-go rather than pre-pay).

You may need a database that backs up more frequently, to avoid losing valuable customer data, perhaps one that is capable of restoring to any point in time.

You may want to allocate resources (e.g. stock) based on data that notifies you of changes and is accurate to the millisecond (e.g. updates from a warehouse management system).

You may want a database platform that ensures compliance with regulations such as HIPPA or SOC2 or GDPR. eg. Supabase

You may want the ability to merge and keep all your raw data in one pace as a single point of truth.

A good backend tool should be the hub of your application development, allowing you to write and maintain the logic for functions that access all your current and future resources eg. databases, file servers, cloud services, line-of business systems and more.

tip

In a separated stack, your backend programming contains the secret sauce, the core processes unique to your business, where you can combine and handle multiple data sources in one API, where you have full control. By building the right thing in the right place, you can scale to millions without needing a total rebuild of your programming, you can build whatever you can think of and take your app to the next level.

The trend for using blackbox connectors to access Rest APIs means you are sending and receiving data in a pre-determined way, they often don’t offer all the functionality of the system you are connecting to, so there is little or no customisation/control for your application. For example, if you use Zapier or Make to connect your no-code app to another SaaS eg. Stripe to take payments from your customers, it will take your customer data in a prescribed way and return the data in a certain pre-formatted way. Using them limits your options to do anything different to your competitor who is using the same APIs. As a general rule, every time you use a blackbox connector you are reducing an element of control over your programming, so the more you use, the more this effect starts to compound and at a certain scale of interconnected processes this starts to seriously limit your options.

But, if you would like the freedom to bring your own ideas to life, by building your own functions from scratch without generic connectors, you will need to build your own APIs and your own logic in a backend.

Storing and handling personal data, especially if you are making decisions with algorithms you don’t want people to see, requires a separate backend layer. It also provides a way to avoid having either sensitive keys or credentials stored and exposed in the browser for anyone to hack.

Using a no-code backend platform allows no-coders to use more complex algorithms, calculations and more precise business rules. In general, the more complex your logical conditions, the more you can tailor your products and services to individuals and react dynamically to any change, even while catering for edge cases.

Moving from adding logic to blackbox automations to programming in a no-code backend tool, will allow a no coder to create a full SaaS platform, to target consumers individually and dynamically.

Switching up from basic automations to full no-code programming means you can create and shape the underlying logic that governs precisely when data is called from one system to another and how that data is manipulated/changed from one state to another. So, with visual programming, instead of choosing from a menu of pre-built connectors/APIs, the no-code developer can go beyond popular use cases to:

Connect to any existing system.

Make granular queries to pull any data from any system.

Transform that data in a customisable way.

Consolidate data in a customisable way.

Format data in a customisable way.

With Comnoco you can create logic with equivalent complexity to code.

Logic can be broken down into reusable discrete functions

The business processes created by these automated sequences can become the backbone of any business application and can be used and reused with any frontend application or any database.

Comnoco handles the deployment and the user only pays for what they use.

No need to choose CPUs and server size and then have to predict your requirements as you approach the limits.

Processes run as serverless functions.

Also installable in a private cloud.

Be ready to connect to any database you might need and avoid having to migrate data.

Allows developers to build queries without SQL

Makes more powerful databases accessible to no-coders

Handles realtime broadcast

Native integration with Supabase