Custom software vs no-code: when each wins, the limits and the real costs over time

Use no-code or low-code when you need an internal tool, a prototype or a simple workflow quickly, and the platform's limits will not matter for the life of the app. Build custom software when the product is what customers pay for, when it needs logic, performance, integrations or security the platform cannot give you, or when usage-based fees and lock-in start to outweigh the speed you gained. Many good products use both: no-code to learn fast, custom code once the product and its requirements are proven.

This guide is for founders, operations leaders and product owners choosing between a platform such as Bubble, Airtable, Power Apps or Zapier and a custom build. It explains where each genuinely wins, the limits teams usually hit, how lock-in works on these platforms, how costs change as you grow, the security questions to ask, and how to move from one to the other without losing what you learned.

What no-code, low-code and custom actually mean

• No-code platforms let people build applications through visual editors, without writing code. Examples include Bubble and Glide for apps, Airtable for databases with interfaces, Webflow for websites, and Zapier or Make for connecting services. The platform runs your app, and its building blocks define what is possible.
• Low-code platforms such as Microsoft Power Apps, OutSystems or Retool combine visual building with the option to write code for parts the visual tools cannot express. They are often aimed at internal business applications inside larger organisations.
• AI app builders generate code from prompts. Unlike classic no-code, many produce a real codebase you can export, but the result still needs review by an experienced engineer before it handles real users, data or payments.
• Custom software is designed and written for your needs by engineers, using mainstream languages and frameworks, and runs on infrastructure you control. You can change anything; you also have to maintain everything. Our custom software development guide covers this route in depth.

These tools have moved into the mainstream. Back in 2021, Gartner forecast that by 2025, 70% of new applications developed by organisations would use low-code or no-code technologies, up from less than 25% in 2020. Whatever the exact share today, the question for most businesses is no longer whether to use these tools, but for which jobs.

Three situations, three answers

Custom software vs no-code side by side

When no-code is the better choice

No-code is the right answer far more often than software studios tend to admit. Choose it when most of these are true:

• You are validating demand. A clickable, working version built in days can tell you whether anyone wants the product before you invest in engineering.
• The app is internal. Approval flows, inventory trackers, simple CRMs, onboarding checklists and dashboards for a team of users are classic no-code territory.
• The logic is simple. Forms, lists, filters, notifications and straightforward rules fit visual builders well.
• Volumes are modest and predictable. A few thousand records and a known number of users stay comfortably within most plans.
• The people who know the process can build it. Letting an operations lead build their own tool removes a hand-off and often produces a better fit.
• You are connecting existing services. Moving data between a form, a spreadsheet, a CRM and email is exactly what automation tools are for.
• You can live with the platform's limits for the life of the app. If the tool will never need to do much more than it does today, there is no reason to pay for custom code.

When custom software is the better choice

• The product is what customers pay for. Your differentiation should not be limited by the same building blocks every competitor can use. Our guide to custom software vs off-the-shelf explores this utility-versus-differentiator test.
• The logic is complex. Pricing engines, scheduling, matching, multi-step calculations and permissions with many roles quickly become fragile chains of visual workflows.
• Performance matters. Public-facing products need fast pages on mobile networks and quick responses under load, which requires control over the frontend, queries and caching.
• You handle sensitive or regulated data. Payments, health data, financial records or public-sector data bring requirements on data location, access control, audit trails and testing that many platforms cannot fully meet.
• You need integrations the platform does not offer. Legacy systems, industry APIs and real-time data flows often need code.
• Several people must work on it safely. Version control, code review, automated tests and staging environments let teams change software without breaking it.
• You need native mobile capabilities. Offline use, background processing, device sensors and polished iOS and Android experiences are easier with a native or cross-platform build.

A no-code platform is a set of decisions someone else has already made for you. That is its strength while those decisions suit you, and its limit from the day they stop.

The limits teams usually hit

Every platform is different, but the walls tend to appear in the same places, usually once the app has real users and a growing backlog.

• Data volume. Some platforms cap records per database or per plan. Airtable's plan comparison, for example, lists record limits per base that rise by tier, from 1,000 on the free plan to 125,000 on the self-serve Business plan, with higher limits only through sales.
• Workflow complexity. Long chains of visual steps are hard to read, test and debug. A change in one place can break another without warning.
• Performance tuning. You cannot usually optimise the queries, caching or page rendering that the platform generates.
• Interface control. Precise design, complex interactions and accessibility requirements can be difficult when the platform controls the markup.
• Testing and environments. Automated testing, separate staging environments and safe release processes are often limited compared with a code workflow.
• Collaboration. Several builders editing the same app at once, with review and rollback, is harder than in a code repository.
• Integrations. When there is no connector, you are left with webhooks, custom API calls or a separate service, which is custom code in all but name.

Lock-in: own your data, rent your app

Lock-in is the most important difference and the one most often misunderstood. On most no-code platforms you own your data and can export it, but the application itself (its logic, workflows and screens) exists only as a configuration inside the platform. Moving means rebuilding.

Bubble is unusually candid about this. Its FAQ explains that because apps are built visually and run on the platform, there is no traditional codebase to export; it offers a raw export of application logic as a JSON file to help with migration, says users can export their data as CSV files, and commits to releasing its source code under an open-source licence if it ever shut down. That is a fair and clear position, and it is typical of the category: your data can leave, your app cannot leave as a working product.

Low-code platforms and AI app builders vary more. Some generate standard code you can export and run elsewhere; others produce code that depends on the vendor's runtime or libraries. Before you commit, ask exactly what you can take with you, in what form, and whether it would run without the vendor. With custom software built on mainstream technology, in repositories and accounts you own, the exit question is about documentation and handover rather than rebuilding.

How costs change over time

No-code is almost always cheaper to start. The question is how the cost curve bends as you grow. Many platforms price on usage, seats or records, so success raises the bill. Some examples of how this works, from the vendors' own documentation:

• Usage-based capacity. Bubble measures the server resources an app consumes in workload units; its workload documentation explains that plans include an allowance and that extra usage is covered by pay-as-you-go overages or additional workload tiers.
• Per-task automation. Zapier counts each successful action as a task. According to its pricing page, with pay-per-task enabled, tasks beyond your plan are billed at 2.5 times the base rate on monthly plans or 1.25 times on annual plans, and usage stops at three times the subscribed amount; with it disabled, automations stop at your limit until the next cycle.
• Per-user request limits. Microsoft's Power Platform request limits give each paid licence a number of requests per 24 hours (for example 40,000 for most premium user licences and 6,000 for per-app licences), with add-ons for heavy users.
• Per-seat pricing. Many internal-tool platforms charge for each person who builds or uses an app, so rolling a tool out to a whole company can multiply the cost.

None of this is unreasonable; platforms run infrastructure for you and charge for it. But it means you should model costs at your expected scale, not today's. Custom software has the opposite shape: higher upfront effort, then hosting and maintenance costs that you control and that typically grow more slowly with usage. Neither is free to run: custom software needs ongoing maintenance, security updates and hosting, as our maintenance and support guide explains.

A worked comparison in effort, not money

Take a customer portal for a service business: login, a dashboard of orders, document uploads, a support form and notifications. On a no-code platform, one capable builder might have a working version in a couple of weeks. A custom build with a small team might take a couple of months to a comparable first release. In year one, the no-code route wins clearly. By year three, the picture depends on three things you can estimate now: how many users and records you expect (and therefore which pricing tier), how many changes the platform cannot support without workarounds, and whether a security review or enterprise customer will require controls the platform lacks. If all three stay small, no-code may win for the life of the product. If any of them grows, a custom build starts to look cheaper as well as better. Our cost calculator can help size the custom side.

Security and governance

No-code makes it easy for anyone to build an app connected to company data, which is both the point and the risk. OWASP maintains a Citizen Development Top 10, originally published as the Low-Code/No-Code Top 10, listing the most common risks in apps built this way. They include account impersonation, authorisation misuse, sensitive data leakage, security misconfiguration, vulnerable and untrusted components, asset management failures, and logging and monitoring failures.

In practice, that means checking whose credentials an app's connections use, who can see and share each app, where data is stored, whether access is logged, and whether anyone keeps an inventory of the apps people have built. Platforms provide many of these controls, but someone must configure and review them. Custom software carries its own security work; the difference is that you design the controls rather than inherit them.

Hidden and forgotten costs

Questions to ask before you commit

For a no-code or low-code platform

• What exactly can I export (data, logic, design, code), in what format, and would it run anywhere else?
• What are the limits on records, users, requests or automation runs on each plan, and what happens when I exceed them?
• What will this cost at ten times my current usage?
• Where is data stored, can I choose the region, and which security reports or certifications can the vendor share?
• How do I test changes before they reach users, and can I roll back?
• How do the platform's connections authenticate, and who can see and share each app?
• What happens to my app if the vendor changes pricing, is acquired or shuts down?

For a custom software partner

• Will the code, hosting and accounts be mine from day one?
• Which mainstream technologies will you use, and how easy will it be to hire for them?
• How will my non-technical team edit content and settings without a developer?
• How do you plan to migrate data and users from our current platform with minimal disruption?
• What does maintenance after launch involve, and what will it take in effort each month?

Moving from no-code to custom without losing what works

A well-used no-code app is one of the best specifications a custom build can have. It shows which screens people use, which workflows matter and which data is real. A sensible migration looks like this:

1. Document what exists. List screens, workflows, data structures, integrations and automations, and note which ones users rely on and which are workarounds.
2. Decide what to keep, change and drop. Migration is the moment to remove workarounds and fix the things the platform never let you do well.
3. Design the data model properly. Map the exported data into a schema built for your future needs, not a copy of the platform's tables.
4. Build in phases. Start with the part that causes the most pain or cost, often the core customer workflow, and keep the rest on the platform for now.
5. Run both in parallel. Migrate data, test with real users, then switch over on a date you choose, with a rollback plan.
6. Keep no-code where it still fits. Internal tools and simple automations can stay on a platform even after the core product moves to code.

If you are still at the idea stage, our guide to scoping an MVP helps decide what the first version needs, whichever way you build it.

How Authect approaches this

Authect is a founder-led software development studio. You talk to the founders who develop your project, never a salesperson or account manager, and every project is led by a senior engineer. Conversations start online, and we meet in person later in a project where it helps. We build web and desktop SaaS platforms and iOS and Android apps, using AI to accelerate delivery with an engineer reviewing every line, and we cover what comes after launch through fixed-price projects, monthly sprints, and support and evolution.

Clients own the code, infrastructure and designs from day one, so moving to custom software does not mean swapping one form of lock-in for another. If a no-code tool will serve you well for the life of your app, we will tell you to keep it. If you have outgrown one, or are deciding whether you will, tell us what you have built so far.