The True Cost of No-Code Lock-In: Moving to Laravel and React

The bill is the part you can see

Open the billing page on whatever platform you're on and you get a number. Sometimes it's just a plan fee. More often it's the plan fee plus a charge per seat, plus the second app you spun up for the ops team, plus the add-ons that quietly became load-bearing. The form builder. The auth provider. The workflow tool that fires your webhooks.

That number is real, and it's the one people put next to a rebuild quote when they're deciding what to do. It's also the smallest cost you're carrying.

The expensive parts of no-code lock-in don't appear on an invoice. They show up as decisions you can't make, work that takes far longer than it should, and a growing gap between what the business needs and what the platform will let you build.

The costs nobody invoices you for

Your data exports, but not cleanly

Every platform has an export button. That's not the same as owning your data.

What usually comes out is a set of flat files shaped around how the platform stores things, not how your business thinks about them. Relationships between records turn into opaque internal IDs. Fields that were computed on the fly aren't in the export at all, because they never existed as data. File uploads sit behind signed URLs that expire. Anything the platform treated as configuration rather than content (your workflows, your permission rules, your email templates) simply isn't included.

You can rebuild all of that. It just takes real work, and it's work you pay for at migration time rather than when you built it.

Your business logic lives in a canvas nothing else can read

This is the big one. The rules that make your product yours (how a quote gets priced, when an order flips to fulfilled, who's allowed to see which record) are drawn as boxes and arrows in a proprietary editor. No other tool reads that format. You can't diff it. You can't put it in version control in any meaningful way. You can't hand it to a new developer and say "read this".

The practical effect is that the logic only exists in two places, inside the vendor's product and inside the head of whoever built it. When that person leaves, you're reverse engineering your own business by clicking through screens.

Rate limits start making your product decisions

Platform quotas are a design constraint whether you asked for one or not. A report you want to run nightly gets restructured because the API won't let you pull that many records. A feature ships as a manual export instead of a live view. Batch jobs get split across hours to stay under a cap.

None of those decisions get written down as "the vendor made us". They get written down as product choices, and a year later nobody remembers why the thing works the strange way it does.

The price changes and you don't get a vote

Platform pricing shifts. Plans get renamed, limits get repackaged, a feature that came with your tier moves up a tier. That's normal for a business, and it's fine when you can leave. The problem is that lock-in and price changes compound. The harder it is to move, the more of a price change you'll absorb, and the vendor knows the difference between a customer who can walk and one who can't.

The hiring pool gets smaller, not bigger

Ask what happens when you need a second developer. For Laravel or React, you're hiring from a huge pool, and any competent developer can read the codebase because it's just code. For a specific visual builder, you're looking for people who know that platform, at that level, and who are still working in it. That pool doesn't grow with your company, and it can shrink as attention moves to the next tool.

What no-code is genuinely good at

This isn't an argument that no-code is a mistake. It's usually the right first decision.

If you're testing whether anyone wants the thing, a visual builder gets you to a real answer fast, and a wrong answer is cheap. Internal tools are a great fit too. Admin dashboards, approval queues, the little app the ops team lives in, all of that can happily live on a platform forever.

The trouble starts when the prototype becomes the business. The thing you built to answer a question is now taking payments, holding customer data, and shaping how your team works. The constraints that made it fast to build are now the constraints on your company.

That's the moment to move. Not before.

What a Laravel and React build replaces, and what it doesn't

Custom code replaces the platform's editor, its database, its workflow engine, its hosting, and its seat-based billing. Your logic becomes readable code in a repository you own. Your data sits in a normal relational database you can query, back up, and hand to anyone. Adding a user costs nothing. Integrations aren't limited to what the vendor's marketplace offers.

Here's what it doesn't do, and it's worth being straight about this.

Custom code doesn't maintain itself. You still need hosting, backups, monitoring, security updates, and someone who picks up the phone when something breaks. A rebuild doesn't fix a product people don't want, and it doesn't make a confused workflow make sense. If the current app is a mess because the process behind it is a mess, you'll get a faster, more expensive mess.

It also isn't instant. Anyone promising a like-for-like rebuild almost overnight either hasn't seen your app or is planning to skip the parts that matter.

Move one surface at a time

The version of this that goes wrong is the big-bang cutover. Months of parallel building, one tense weekend, and a Monday where everything is new and nothing is proven.

The version that works is staged. Both systems run at once and you move one surface at a time.

Start with the surface that hurts most or is least entangled, often the public site, the customer login, or a single high-traffic workflow. Build that piece properly in Laravel and React, point traffic at it, and leave everything else on the platform. Data stays in sync between the two while both are live, usually with the new database as the system of record for what's moved and a sync job handling the rest. Then take the next surface.

Nothing about this is glamorous, and that's the point. Each step is small enough to reverse. You're never betting the business on one deploy, the team learns the new system gradually instead of all at once, and the platform bill drops in stages as apps and seats get switched off.

It also means you can stop partway if you want to. Some businesses move the customer-facing product to code and happily leave internal tooling on a platform for years. That's a perfectly good outcome.

A cheap first step

Before you commit to anything, it's worth knowing what shape you're actually in.

Our free site check scans any website for common security, performance and SEO issues, and there's no signup to run it. It's quick, and it'll tell you plenty about what your current setup is doing to you. If you want a proper look under the hood, the Full Code Audit is A$299 on its own, or A$150 if you're on a plan.

For the work itself, we run monthly retainers, which suits staged migrations well. Starter is A$149 a month and Pro is A$299, credits map one to one with dollars (A$149 of plan buys A$149 of work), and unused credit rolls over up to a cap. You can see both on the plans page. Requests go through the client portal, you get a price in credits before anything starts, and you approve or decline.

Own the code. Move in steps. Keep the lights on the whole way.