Low-Code vs Custom Code in 2026: The $44 Billion Question

Gartner now sizes the low-code development market at $44 billion by end of 2026, growing roughly 22% year over year. Retool raised at billions. Bubble has a hundred-thousand-plus paying users. Microsoft Power Platform is the largest individual line item in many enterprise IT budgets.

And yet half our inbound this quarter is “we built it in low-code, it’s breaking, please help.”

Both things are true. Low-code is a real, useful category. It also has very predictable failure modes. This post is the boring rulebook for when to use low-code, when to ditch it, and what migration actually looks like.

What low-code does well

Let’s be honest about the wins before the criticism. Low-code earns its market cap on real value:

• Internal CRUD apps. Inventory tracker, simple admin panel, customer-facing portal where the data model is 3-5 tables and the workflow is “list, filter, edit, save.” Retool, Appsmith, or even Airtable + interface block can ship this in 2 days where custom would take 2 weeks.
• Forms and intake flows. Typeform, Tally, Jotform. Genuinely no reason to build custom forms in 2026.
• Internal workflow automation. Zapier, n8n, Make. Sales-ops trigger emails, Slack notifications, basic ETL between SaaS tools. A custom backend for these is overkill.
• MVPs to test an idea. Bubble or Lovable can put a clickable product in front of users in a week. If the product doesn’t get traction, you saved months.
• Prototypes for stakeholder buy-in. A working low-code prototype gets executive sign-off faster than a Figma deck. Ship the prototype, get the budget, then decide whether to keep or rebuild.

Used in these five buckets, low-code is one of the highest-ROI technology categories in modern software.

Where low-code consistently fails

Then there’s the other side of the inbox. Here are the five failure modes we see over and over:

1. Complex business logic crammed into a visual builder

The moment your “if this then that” logic gets nested four layers deep, the visual representation becomes harder to read than the code it’s replacing. The drag-and-drop workflow that was supposed to “let non-engineers maintain it” is now a 200-node spaghetti graph that only the person who built it can decipher, and that person left in March.

Bubble apps with this problem are the hardest to migrate. The logic is half-documented across visual flows, half-encoded in plugin behaviors, and there’s no test suite because low-code platforms rarely have first-class testing.

2. Performance at scale

Most low-code platforms are fine at 10 users and 1,000 records. At 5,000 users and 5M records, you hit one of three walls:

• The database is the platform’s database. You can’t add indexes, can’t tune queries, can’t shard. You pay the platform for a bigger plan and pray.
• The pricing curve is exponential. Bubble, Retool, Mendix all have plans where the cost goes up nonlinearly with usage. We’ve seen $400/month low-code apps balloon to $8,000/month over 18 months of growth.
• The runtime is opaque. When a page takes 9 seconds to load, you can’t profile it. You can’t add caching at the right layer. You file a support ticket.

3. Vendor lock-in

Your code lives in their platform. If the platform changes pricing (Salesforce does this regularly), gets acquired (multiple low-code platforms have been acquired and re-priced in the last 24 months), or simply shuts down (Coda’s general-availability product, RIP), you have a forced migration on a schedule you don’t control.

Standard custom code on standard frameworks (Next.js, Postgres, AWS/Vercel/Fly) ports between providers. Bubble apps don’t port anywhere. There is no “export to standard code” button that produces a maintainable codebase, despite what some platforms claim.

4. Multi-tenant and security requirements

If you’re building B2B SaaS that needs proper multi-tenancy (row-level security, tenant isolation, per-tenant configuration), low-code platforms are uniformly bad at this. They were designed for single-org internal use. Bolting tenancy onto them produces either security holes or unmanageable complexity.

Same for SOC 2 evidence. Auditors want logs, access controls, encryption, code review history. Low-code platforms produce maybe half of what’s needed. You end up writing custom controls around them and the audit becomes harder than it would have been for a custom app.

5. Hidden costs that compound

The headline cost is the platform fee. The real cost includes:

• Platform-specific specialists. A senior Bubble developer is more expensive than a generalist who can work on Next.js, because there are fewer of them and they cost real money to retain.
• Plugins and third-party add-ons. Each one is a monthly fee and a future failure point.
• Workarounds to escape platform limitations. Webhook bridges, sidecars, custom code wrappers around the low-code app. By the time you’ve added these, you have a hybrid system and the worst of both worlds.

The boring rule: when to ditch the platform

We use a simple checklist. If you can answer yes to 3 or more of these, plan a migration to custom now, before the cost grows further.

1. You have 5 or more workarounds. Custom plugins, webhooks to external services, manual data syncs. The platform isn’t doing the job anymore; you’re holding it together.
2. Page-load or transaction times exceed 3 seconds on real data. And you can’t fix it because you can’t access the runtime.
3. Your monthly platform bill has doubled in the last 12 months. And projected growth keeps that trajectory.
4. You need true multi-tenancy. Different customers, different data, hard isolation.
5. A compliance audit is on your roadmap. SOC 2, HIPAA, ISO 27001.
6. Two or more engineers can’t safely make changes. The platform allows only single-editor flows for some logic, or changes break invisibly.
7. Your investors are asking about platform risk. Series A and later, this comes up in due diligence.
8. The platform’s roadmap doesn’t match yours. They’re going where you don’t need them to go.

Three or more yeses, you’re past the breakpoint. Five or more, you’re paying for two systems and getting one.

Migration patterns: how to leave gracefully

Most low-code escapes are painful because teams try to migrate in one shot. The pattern we use instead is strangler fig: build the new system alongside the old, migrate one workflow at a time, and turn off the old platform only when nothing depends on it.

Concrete steps:

1. Audit the platform. Document every workflow, every external dependency, every business rule. Time-box this to 1-2 weeks.
2. Pick the highest-pain workflow first. Usually the one with performance problems or compliance pressure. Build the custom replacement for just that workflow.
3. Run both in parallel. New requests hit the new system, old data lives in the old system. Bridge with read APIs.
4. Migrate data in batches. Don’t try to move everything at once. Move what’s actively used; archive the rest.
5. Repeat workflow by workflow. Each step independently shippable, each step shows ROI immediately.
6. Cut over the platform last. When no workflow depends on it, downgrade to the free tier or cancel.

Typical migration timeline for a mid-size low-code app: 12-20 weeks. Typical cost: $40K-$120K. Compared to “stay on the platform and pay $8K/month forever,” the migration pays back in 12-18 months.

When custom is right from day one

There’s also the inverse case: when you should not start on low-code at all, even for an MVP.

• The product is software. If you’re selling a SaaS product where the UX is the differentiation, building it on someone else’s UX framework limits your differentiation and locks you in.
• You expect to raise venture capital. VCs flag low-code platform dependency in due diligence. Series A and later, the question gets sharper.
• Multi-tenant from day one. Don’t start on a single-org platform and pretend you’ll migrate. You won’t, until it hurts.
• AI-native applications. Most AI products need custom prompt management, eval pipelines, model routing, and cost controls. Low-code platforms have shallow support for any of this.
• Performance-sensitive UX. Trading platforms, real-time collaboration, anything where users are watching the loading spinner.

In these cases the day-one cost of custom is higher. The 24-month cost is dramatically lower because you skip the migration entirely.

Honest pricing comparison over 24 months

A representative example. A B2B SaaS product, growing from 50 to 1,000 customers over 24 months:

Low-code path:

• Year 1 platform fees: ~$24K
• Year 2 platform fees (growth): ~$90K
• Specialist developer time (1 senior, partial allocation): ~$80K
• Migration to custom at month 22 (forced): ~$90K
• Total: ~$284K, and at the end you’re starting custom.

Custom from day one:

• MVP build: ~$60K
• Year 1-2 maintenance retainer: ~$40K
• Hosting and tooling: ~$10K
• Total: ~$110K, and at the end you own a codebase.

The custom path is roughly 60% cheaper over 24 months if the product takes off. If it doesn’t take off, the low-code path was correct, because you discovered the no faster and cheaper. This is why low-code is great for validating ideas and terrible for scaling them.

The Softronic position

We build custom for businesses where software is the product. We don’t try to talk every client out of low-code; for internal tools and prototypes, we’ll recommend it. For SaaS products you’re selling, we won’t. Owned code on standard frameworks beats platform code on a managed runtime over any timeframe that matters.

We’ve migrated 14 codebases off low-code platforms in the last 18 months. The common thread: every one of them wishes they’d switched 12 months earlier.

Ready to ditch the platform?

We’ll audit your low-code setup and give you a real migration plan with a fixed price. Or we’ll tell you to stay on the platform — that happens too.

Start at custom software or read about our full services.