No code vs low code vs custom code: what each can carry as your business grows

What is the difference between no-code and low-code?

If your business keeps its jobs in an Airtable base, or runs approvals through an app someone in operations put together, it already runs on no-code. The question that follows is whether those tools can keep up as the business grows, and whether the next app should be built another way.

Microsoft, which sells tools of both kinds, draws the line simply: low-code development needs some custom coding, and no-code development doesn’t need any (read November 2026). Three ways of building follow from that:

• No-code: apps put together from the platform’s ready-made blocks, by the people who use them. Microsoft describes no-code platforms as letting business users with no knowledge of coding meet their own needs.
• Low-code: the same visual building, with formulas, scripts and connectors where the blocks run out. Microsoft says low-code platforms are most often used by IT professionals with some coding skills.
• Custom code: software written by developers in a general programming language, running on hosting the developer sets up, with no platform’s blocks underneath it.

In practice the line between the first two blurs, because a no-code tool can have a low-code layer. Airtable is an example. Its support pages list native integrations, connections through Zapier and Make, and CSV import and export as its no-code options, and its scripting extension, script steps in automations, incoming webhooks and Web API as its low-code ones (read November 2026).

What is a no-code app builder, and what can it build?

Microsoft defines a no-code app builder as development software that lets people create apps without knowing how to write code. The trade is in the same page: because these tools are made of prebuilt blocks, users can’t add code of their own, connect to custom data sources or create their own integrations with other systems (read November 2026).

Within those limits, a no-code app builder does real work:

• Trackers and shared databases: jobs, leads, inventory or projects in one place, with a view for each team.
• Forms and intake: requests, applications and orders that arrive as records the team can sort and track.
• Simple internal apps: an approvals screen, a checklist, a staff directory, a booking sheet for equipment.
• Prototypes: a working version of a new process, to learn what it needs before anyone writes code.

Each builder has its own center. Airtable builds databases with interfaces, forms and automations on top. Bubble builds web and mobile apps without code (read November 2026). Microsoft Power Apps builds apps on Microsoft’s platform and carries a low-code layer for developers. Choosing between them starts with the kind of app you need.

What do low-code development platforms add?

Low-code development platforms keep the visual builder and add a way for someone technical to go further. Microsoft’s Power Fx shows how. It’s the low-code formula language Microsoft Power Platform uses, and Microsoft describes it as covering the whole range, from people who have never programmed to professional developers, with no rewrite in between (August 2026). The same page is frank about the visual side: the no-code tools never offer everything the full language can express.

What the code layer adds:

• Logic the blocks can’t express: formulas and scripts for calculations, checks and rules.
• Connections to other systems: custom connectors let Power Fx call any REST web service, which is how a low-code app reaches a system the platform has no block for (August 2026).
• Steps inside automations: Airtable’s scripting extension runs JavaScript against a base and can call outside services, and an automation can run a script as one of its steps (read November 2026).
• A path to a developer: the person who built the app in the visual editor can hand a hard part to a developer without moving platforms.

A low code application development platform is still a platform, though. The app runs on the vendor’s service, under the vendor’s plans and limits. The code layer widens what you can build without changing who you depend on.

How do no-code, low-code and custom code compare?

The three differ most in where each one stops.

For internal tools in particular, the choice between building and buying has its own guide: build vs buy internal tools.

Can a no-code app grow with your business?

Up to the platform’s limits, and those are written down. On Airtable’s plans (read November 2026):

• Records per base: 1,000 on Free, 50,000 on Team and 125,000 on Business, counted across every table in the base.
• API calls per workspace each month: 1,000 on Free, 100,000 on Team and unlimited on Business.
• Automation runs per workspace each month: 100 on Free, 25,000 on Team and 100,000 on Business.
• API speed: 5 requests per second per base. Past that, the API answers with an error (HTTP 429) and the caller has to wait 30 seconds before its requests succeed again.

A worked example shows how soon those numbers arrive. A business that books 200 jobs a week, each with four line items kept in a second table, adds 1,000 records a week. That’s 52,000 records in a year, past the Team plan’s 50,000 per base before the year is out.

At the limit there are three moves. You can archive old records into a second base, move up a plan, or move the data into a database the app reads from. The first breaks the links between old and new records, the second buys time until the next ceiling, and the third is where custom code usually begins.

A team that still runs on spreadsheets meets the same question from the other side: spreadsheet to web app covers that move.

What are the risks of building a business on a no-code platform?

The risks are real, and most of them can be seen coming:

• Lock-in: the app may not leave the platform. Bubble says its apps run only on the Bubble platform and can’t be exported as code, so moving off means rebuilding the app’s logic, while your data comes out as CSV files or through Bubble’s API (October 2023).
• Limits met late: record caps, API calls and automation runs are easy to ignore at 500 records and hard to ignore at 50,000.
• Prices you don’t set: the vendor decides what each plan costs and what it includes, and can change both.
• One builder: an app one person built in spare hours may have no written record of how it works, and then it stalls the day they leave.
• Control of the data: who can see and change what depends on the permissions the platform, and your plan on it, provide.

Each of these is a reason to know which of your apps the business can’t run without, and to treat those differently from the rest.

When should you use custom code instead of no-code?

Custom code earns its extra build time when one or more of these is true:

• The app is the system the business runs on: customers, orders, money or jobs, where an outage or a cap stops the work.
• The volume is past the platform’s limits: or will be within a year, on the numbers you already have.
• The logic is the hard part: pricing rules, scheduling or checks that need tests, versions and review.
• The integrations aren’t on the menu: an older system, an internal database or an API the platform has no block or connector for.
• You need the software itself to move: to other hosting, to another developer, or along with the business if it’s sold.

Stay on no-code when the app is a tracker a team uses for a season, a prototype to test a process, or a tool whose afternoon outage costs nothing. Moving those to custom code spends money without changing much.

If a rebuild is on the table, the custom software cost page has the market’s ranges for building and running one.

What doesn’t help when a no-code app hits its limits?

Four responses keep the app running for a while and leave the limit in place:

• More automations on top: each one adds runs against the monthly cap, which is 25,000 on Airtable’s Team plan (read November 2026).
• Splitting one base into many: it gets under the record cap but breaks the links between records, and every report then has to stitch the bases back together.
• A second no-code tool bolted on: it brings its own caps and its own plan, and the data now lives in two places.
• Rebuilding in the same tool: a cleaner version of the same app meets the same limits a little later.

Where should you start?

Before choosing a way to build, take stock of what you already run:

1. List the apps you run on no-code and low-code tools: what each one does, who built it and who uses it.
2. Check each one against its plan’s limits: records, API calls and automation runs, today and a year from now.
3. Mark the ones the business can’t run without: those are the apps to plan for first.
4. Export the data from those and look at it: see what comes out, and what doesn’t, such as the app’s logic.
5. Decide app by app: keep it, move up a plan, add a low-code layer, or rebuild it in custom code.

Where an app still fits its platform, keep it, and give it someone who looks after it and a written record of how it works. When a no-code tool still does the job, we’ll say so. Where an app has outgrown its blocks, our no-code and low-code work rebuilds it on a low-code platform or in custom code, whichever it needs, starting with a 15-minute call.