The low-code conversation has two camps, and they're both wrong. The first camp says low-code is a toy — real engineers write real code, and any business serious about scaling will rebuild in code eventually, so you might as well start there. The second camp says low-code is the future — code is going away, the next generation of "engineers" will be drag-and-droppers, and there's no reason to write any code at all if a Bubble app can do the job.

Both are caricatures. Low-code occupies a specific phase of the company lifecycle, and the failure mode in either direction — starting with code when you should have used low-code, or staying on low-code when you should have moved to code — costs real money.

Let me describe the phase boundaries.

**Phase one: the experiment.** You don't have a product. You don't have customers. You don't know if anyone wants what you're considering building. You need to run a few experiments to find out. In this phase, low-code is not just acceptable, it's strictly correct. Building the experiment in custom code is a waste of time that produces no additional value. Bubble, Glide, Softr, Airtable, Notion, Zapier, Make, Retool — pick a stack, ship the experiment, measure what happened. The output you care about is *evidence*, not *architecture*.

The traps in this phase aren't about the choice of tool; they're about confusing the experiment with the product. Some founders ship a Bubble app for an experiment, get traction, and then spend six months adding features to the Bubble app *as if it were the product*. That's the wrong move — the Bubble app was a test instrument; once it's served its purpose, the next phase has different requirements.

**Phase two: early product-market fit.** You have some evidence the business works. Maybe twenty customers, maybe a hundred. The product is becoming real. The economics look promising. In this phase, low-code is still often the right answer, but the calculus changes.

Specifically: if the product can run on low-code without hitting one of the known walls (more on those in a second), staying on low-code lets you iterate fast, learn from the next batch of customers, and avoid the expense and discipline overhead of running a custom-code production system. This is where most founders get it wrong by *rebuilding in code too early*. They look at their Bubble app, feel embarrassed, and decide it's time to "build properly," spending six months rebuilding what they had, with no new customer-facing features, while no-code competitors who didn't rebuild ship past them. Six months later, the rebuild is done, it works, it does the same things as the old app, and now the company has used up its runway on a no-op.

So the right answer in phase two is: *stay on low-code unless you have a specific reason to leave it.* The reasons to leave are real, and they cluster.

**Phase three: scale.** Now you have a real business. Customers count in the thousands. Revenue is meaningful. The low-code platform is starting to hurt. You're hitting limits — performance, integration complexity, control over data, vendor risk, cost. *Now* is the time to rebuild. And by now, you know what to build, because you've operated the low-code version long enough to understand which workflows matter, which fields you actually need, which user paths convert, which features got built and never used. The rebuild is informed instead of speculative.

So when do you leave low-code? Here are the specific walls.

**Performance wall.** Most low-code platforms scale to a few hundred or a few thousand users fine. Past that, page load times start to creep up, database queries get slow, and there's no good way to optimize because you don't control the substrate. If your usage is hitting these limits and the platform's "performance tier" pricing is now competing with the cost of an engineer, you've hit the wall.

**Integration wall.** Low-code platforms generally have decent built-in integrations and weak custom-integration stories. If your product needs to integrate deeply with five external services in non-standard ways — webhooks, custom auth flows, real-time sync, complex retry logic — the low-code platform will fight you. Some can do it; most do it poorly. Once you're spending engineering time on the integration glue layer, you might as well control the whole substrate.

**Data wall.** When your product becomes data-heavy — millions of rows, complex queries, real reporting needs, regulatory compliance about data residency or audit logs — low-code platforms become limiting. They generally don't expose the underlying database to you, you can't run arbitrary queries, you can't enforce custom indexes, and the data export story is usually a CSV download that doesn't scale to your size. If you need real database control, leave.

**Cost wall.** Low-code per-user pricing or per-record pricing scales linearly with your usage. Custom-code infrastructure scales roughly logarithmically with usage. There's a crossover point. Most founders are surprised by how *late* the crossover comes — Bubble at $529/month covers a lot of usage — but for some applications (very high event volume, very large user base, very low per-user revenue) the crossover happens earlier. Run the math.

**Customization wall.** This is the most common reason teams leave. The product needs something the platform can't do. Custom UI components that the platform's component library doesn't support. Complex permissions models that the platform's auth doesn't accommodate. Custom workflows that the platform's logic builder can't express. When you find yourself fighting the platform on every feature, that's the wall.

**Hiring wall.** As you grow, you need to hire engineers. Engineers want to work on real code, not Bubble. This is partly snobbery, partly practical — engineering careers are built on code that translates to other jobs, and "I shipped a Bubble app" doesn't carry the same weight as "I shipped a Django service." This affects recruiting, retention, and ultimately your velocity if you can't hire well.

A specific test I use with founders. I ask: when you've added a customer-requested feature to the low-code product recently, did it take an hour or a week? If it took an hour, you're still in the sweet spot — low-code is providing value. If it took a week, you're fighting the platform, and your engineering investment in the rebuild will pay back faster than you think.

A few specific low-code recommendations as of 2026.

**Bubble.** Most flexible, steepest learning curve, can build genuinely complex apps. The right choice when your product is genuinely product-shaped (not just internal tools or marketing).

**Webflow.** Best-in-class for marketing sites and product landing pages. Can do some commerce. Not the right choice for actual apps.

**Softr** or **Glide.** Layer on top of Airtable or Google Sheets. Excellent for internal tools, simple consumer apps, and MVPs where the data structure is mostly tabular.

**Retool.** Specifically for internal tools — your team uses it, not your customers. Best in class.

**Zapier / Make / n8n.** Workflow automation. Glue between services. Use these heavily in early-stage products; you can replace them later with code as the workflows stabilize.

**Airtable.** Database masquerading as a spreadsheet. Excellent for many MVP backends. Can scale further than you'd expect with the new API and views.

**The AI low-code wave (v0, Lovable, Bolt, Cursor-for-non-engineers).** These are the new wave. They generate code rather than abstract over it, which means you can leave the AI-tool and keep the codebase — different model from Bubble. Worth experimenting with, especially for founders who want code-as-output but can't code themselves. Maturity is still mixed in 2026; the gap between "generates something" and "generates something maintainable" remains.

The biggest mistake in this whole space is binary thinking. Founders ask "should we be a low-code company or a code company?" That's the wrong question. The right question is "where in the lifecycle are we, what tool fits this phase, and what's the trigger that moves us to the next phase?" Most successful companies that started low-code rebuilt parts in code as they scaled — not the whole thing at once, just the bottleneck pieces. The Bubble app might still run the dashboard while the new Go service runs the high-volume event processing. Mixed-mode operation is fine and often optimal.

Build with low-code while it's the right tool. Leave when it stops being the right tool. Stop trying to make that decision in advance.