Low-Code in 2025: When to Build, When to Buy, When to Hybrid

Low-code used to be the punchline of serious engineering conversations. "Real engineers write code." "Low-code doesn't scale." "You'll be locked in." I said all of those things, more than once, less than five years ago.

By 2025, all three are wrong often enough that the smart move is to drop them as defaults and replace them with a real decision framework. Low-code now anchors production SaaS at companies you'd recognize. The question isn't whether to use it — it's where.

The framework I use

I split every product surface into one of three buckets:

Bucket 1: Use low-code

These are the surfaces where time-to-ship beats deep customization, and where the platform's abstractions are good enough:

• Internal tools. Admin dashboards, customer support consoles, ops tooling. Retool / Internal / equivalents have made this a no-brainer.
• Customer-facing portals. Account settings, billing pages, simple workflow apps.
• Configurable workflows and forms. Things where the customer wants to change behavior without a code change.
• Marketing pages and CMS-driven content. Webflow, Framer, and the modern CMS layer have made hand-rolled marketing sites a waste of engineering time.

Bucket 2: Use code

These are the surfaces where you cannot afford to be at the mercy of a platform's roadmap:

• Differentiated logic. The thing your customers actually pay you for.
• Performance-critical paths. Anything where milliseconds matter.
• The data model. If your data model is your moat, it lives in your code, not in a low-code platform.
• Anything you'd be sad to lose if the vendor disappeared. Vendor risk is real; treat it accordingly.

Bucket 3: Hybrid

This is where most teams should land — a code-first core with low-code surfaces around the edges. The internal tools team uses Retool. The marketing team uses Webflow. Customer-facing portals use a low-code builder. The differentiated product engine is hand-rolled.

The trap most teams fall into

The most common failure pattern I see: adopting low-code by accident, then quietly migrating everything onto it. It usually goes like this:

1. Someone builds an internal admin tool in Retool to save time. (Good call.)
2. Six months later, half the support team's daily workflow lives in Retool, including some customer-facing operations.
3. A year later, the company is locked into Retool's pricing and roadmap for workflows that are core to revenue.
4. Two years later, leadership realizes the cost is unsustainable and tries to migrate. It takes nine months.

The fix isn't to ban low-code. It's to decide upfront which surfaces are low-code-eligible and which never will be, and to enforce that decision in code review.

Vendor risk in 2025

One more thing worth saying out loud: low-code vendors get acquired, change pricing, and deprecate features just like any other SaaS vendor. Build with the assumption that you might have to migrate off in three years. Keep your data exportable, keep your business logic documented, and keep your boundaries clean.

Adopt low-code with intent, not by accident. The teams that thrive are the ones that decide upfront which surfaces are low-code-eligible and which never will be — and revisit that decision every year.