No-code takes you to 80% and then it blocks you: when (and how) to call someone who actually develops

The 80% that looks like a success

No-code did you a real favour, and it’s fair to admit it before criticising it: it let you build something — an app, an internal tool, a product — fast, spending little, without a development team. You put up 80% of what you needed in a few weeks, and for a while it looked like a full success. It worked, customers used it, the business ran. You wondered why anyone spends so much on “real” development when with no-code you do everything in an afternoon.

Then the wall arrived. One day you needed that thing — a particular kind of permission, an integration with a system, a performance the app no longer holds, a document generated a certain way — and no-code said no. Not “it costs more”, an actual no: it can’t be done inside the tool. And that’s when you discovered the uncomfortable truth of no-code: it takes you to 80% downhill, and then it slams you into a wall on the 20% that’s missing. And that 20% isn’t a detail: it’s almost always the part that distinguishes your company, the part you need to grow, the part you play customers on.

This article is for whoever built something in no-code and hit (or is about to hit) the 80% wall. It isn’t a piece against no-code — which to validate an idea or for internal uses is often perfect. It’s about what to do when it blocks you: how to recognise the wall’s symptoms, the lock-in problem (your data in a tool you don’t really leave), and how you move to something more solid without stopping the business and without throwing away everything you’ve learned.

The wall’s symptoms: permissions, performance, integrations, PDFs

The 80% wall doesn’t arrive as a sudden collapse: it arrives as a series of “you can’t” that at first you work around and then you can’t work around any more. Recognising the symptoms tells you whether you’ve arrived. The most common:

• The permissions that don’t get done. You need a fine-grained handle on who sees and does what — this user sees only their data, this other one can approve but not edit, that role has access to one part and not the other. No-code tools handle simple permissions and give up on the complex ones, which are exactly the ones you need when you grow.
• Performance that gives way. As long as the data was little and the users were four, the app flew. Now that records are tens of thousands and users are many, the no-code app slows down: pages take time, operations get stuck, users complain. No-code tools aren’t built to hold serious volumes, and past a certain threshold the slowness becomes structural.
• The impossible integration. You need to connect the app to a system — the ERP, a particular service, a specific API — and no-code either doesn’t do it, or does it halfway with fragile joints that break. Every integration that falls outside the planned plugins is a wall.
• The document that doesn’t come out the way you want. It sounds trivial, and it’s one of the most frequent blocks: you need to generate a PDF done a certain way — an invoice, a contract, a report with a precise layout — and the tool won’t let you do it as needed. A “small” thing that blocks an entire process.

Each of these, on its own, looks like a technical snag. Together, they’re the signal that you’ve reached the tool’s limit: no-code does the standard case very well and stops on your specific case, which is exactly the one that counts. It’s the same 80% wall I talk about for no-code sold as a product when you need a real product: excellent to start, tight when your distinctive 20% becomes essential.

Lock-in: your data in a tool you don’t leave

There’s a symptom more insidious than the others, because it doesn’t show until you try to leave: vendor lock-in. Your data — customers, orders, all the work done — lives inside the no-code tool, and when you think of getting out you discover that exporting it for real is much harder than you believed. There’s the “export” button, sure, but what you get is a raw file that doesn’t contain the logic, the relationships between the data, the real structure. You have the data “on paper”, but rebuilding a working system from there is serious work.

This lock-in has a heavy consequence: the more you grow on no-code, the more expensive and risky it becomes to leave it, and so the more you’re a hostage. The tool knows it, and has no interest in making it easy — on the contrary, at some point it might raise prices, and you, stuck, pay. Building the heart of your business on a platform you don’t really leave is building on someone else’s land: as long as it goes well, it goes well; the day you need to go, you discover how tied you are.

It’s the same reasoning on owning what’s yours — code, data, infrastructure — that holds for every product that becomes the heart of the business: a real asset is yours and portable; a rent on someone else’s platform is convenient until you try to move. Lock-in isn’t a detail to read in the terms of service: it’s the measure of how free you are to change when you’ll need to.

Tear out the critical piece vs rebuild everything

When you hit the wall, the instinctive reaction is “then we rebuild everything from scratch, properly”. Sometimes that’s right, but often it’s excessive and expensive. The intelligent question is: do I have to rebuild everything, or tear out only the piece that got stuck?

Tearing out the critical piece means identifying the specific part that no-code doesn’t hold — that process that needs fine permissions, that module that has to hold the volume, that impossible integration — and rebuilding only that in a solid way, leaving the rest on no-code as long as it works. It’s a surgical approach: you solve the block without throwing away the 80% that still works. Often the wall is concentrated in one or two points, and facing those unblocks you without the cost and risk of a total rebuild.

Rebuilding everything makes sense when the no-code is rotten at the core: not one or two blocked points, but the whole system creaking, lock-in that makes it impossible to evolve, a base so fragile that every piece you touch breaks another. In that case patching is putting money down a well, and it pays to rebuild on healthy foundations — keeping, though, everything that can be saved (I’ll get there). It’s the same repair-vs-rebuild analysis that holds for every system that has reached its limits: it depends whether the problem is localised or structural.

The rule: don’t rebuild by reflex, analyse where the wall is. If it’s in two points on an otherwise healthy base, tear those pieces out. If it’s everywhere and the base is a dead end, rebuild. Whoever tells you “let’s rebuild everything” without looking at where you’re blocked is selling a big project; whoever looks first at where the wall is is solving your problem.

What to keep: design, copy, learnings

A mistake to avoid when you leave no-code is thinking “we start from zero”. It isn’t true: from the work done on no-code there’s a lot to keep, and it’s a heritage that makes the switch much less expensive than a project from scratch.

The design and the experience: the look, the flows, the way the app is organised — if they work, you keep them and reproduce them in the new system. There’s no reason to redesign what users already use well. The copy and the contents: the texts, the labels, the messages, everything you’ve tuned talking to real users, you take with you. And above all the learnings: this is the real treasure. On no-code you learned what you actually need and what you don’t, which functions users use and which they ignore, where the process jams, what the edge cases are. All this knowledge — which a from-scratch project would have had to discover the hard way — you already have, and it’s gold.

In this sense, no-code played its role perfectly: it was a living MVP that validated the idea and taught you what to build. When you move to real code, you aren’t throwing that work away: you’re collecting the fruit of what it proved, to build the solid version of something you already know works. It’s the natural cycle I talk about for the MVP that validates before you build the complete product: no-code was your MVP, and now you build the product knowing what you actually need.

How not to stop the business during the switch

The biggest fear, rightly, is: “if I change, do I stop the business?”. Because you work on the no-code now, there are customers now, and you can’t afford weeks of darkness. The good news is that the switch is done without stopping anything, if it’s done well — in layers, not with a leap into the void.

The principle is continuity: the no-code keeps working while the new piece is being built, and the switch happens when the new is ready and tested, not before. If you’re tearing out a critical piece, that piece is built to the side, tested, and replaced when it works, while the rest still runs on no-code. If you’re rebuilding more, you proceed in phases: one piece at a time moves from no-code to the new, with the data staying aligned during the transition, until the no-code isn’t needed any more and you switch it off — without a terrifying “big day” in which everything has to work on the first shot.

This takes attention to the data (migrating it well from no-code, which as we’ve seen doesn’t let it go easily) and a thought-out switch plan, but it’s absolutely feasible and must never mean “we switch everything off and hope”. A good switch from no-code to code is invisible to your customers: they keep using the app, and at some point it’s simply faster, more robust, and it does that thing that before “couldn’t be done”. Continuity isn’t a luxury: it’s the condition for you to get out of the wall without paying in downtime.

The costs: you already paid for 80%, now you pay for 100%

Let’s talk money, because there’s a psychological aspect that confuses decisions. The temptation is: “with no-code I spent little, and now you’re telling me I have to spend much more to redo it? Then no-code was a mistake?”. No, and the right way to see the costs is another.

No-code got you to 80% spending little: it was a great deal to validate. But that cheap 80% served exactly to discover that the idea works and what you actually need — enormous value, obtained at a low price. Now, for the 20% that’s missing (and to make the rest solid), you pay the “full price” of real software. It isn’t that you paid twice: you paid little to validate, and now you pay the right amount to build what you validated. If you’d started immediately with real code, you would have paid the full price also to discover the idea — more expensive and more risky.

The point is to compare the cost of the switch not with what you spent on no-code (which was something else: validating), but with the cost of staying stuck: the opportunities you don’t catch because the wall stops you, the customers you lose because the app slows down or doesn’t do that thing, the lock-in risk. If the wall is costing you growth, the switch pays for itself. On how to evaluate what you’re buying when you commission a serious build, and how not to get ripped off, everything I say in the guide to buying custom software holds.

The wall’s bill, in figures

Let’s put some numbers on the cost of staying stuck, because that’s what you compare with the cost of the switch — not the no-code spend. There are three line items, and none of them appears on an invoice.

The lost opportunities: the customers (often the biggest and best-paying) you can’t serve because the app doesn’t do that thing — company permissions, the integration with their system. If the wall stops you from closing even just a few important contracts a year, that’s the biggest line item, and on its own it justifies the switch.

The customers lost to performance: when the no-code app slows under volume, users get impatient and some leave. A churn rate that grows with slowness is revenue walking out the door, in silence.

The rising cost and the lock-in risk: no-code plans cost more as you scale (more records, more users, more functions), and you’re stuck — if the tool raises prices, you pay, because leaving costs. It’s a cost that rises exactly when you’re doing well, plus the risk of depending on someone else’s decisions.

Line item	Effect
(Large) customers you can’t serve because of the wall	often the biggest item
Churn from a slow app under load	invisible lost revenue
No-code fee that rises with scale + lock-in	rising cost, dependency

The right comparison, then, isn’t “cheap no-code vs expensive code”: it’s “how much the wall costs me every month vs how much it costs to knock it down once”. When the wall is blocking your growth and making you lose customers, the switch isn’t an expense: it’s the removal of a brake that costs you more than the switch itself.

When no-code stays (and that’s right)

The honesty that closes the circle: not everything should be taken off no-code, and sometimes no-code is the definitive answer, not a phase. It would be wrong to read this article as “no-code is bad, everyone move to code”. No: no-code remains the right choice in several cases, and recognising them saves you from spending where it isn’t needed.

No-code stays when: it’s an internal tool used by few people, where performance and fine permissions aren’t a problem and no external customer depends on it; when the volume is low and will stay low, so you’ll never hit the performance wall; when it’s a secondary process, not the heart of the business, and it’s enough that it works without having to grow it; when you’re still validating and you don’t know if the idea will hold (then it’s premature to move to code, no-code is doing its job). In all these cases, no-code is perfect, and moving to code would be a waste.

No-code should be left behind only when it becomes the heart of the business and hits the wall on what counts: performance under load, serious permissions, essential integrations, an experience that distinguishes you, and freedom from lock-in. The rule is always the same: how much of your value sits in that 20% that no-code doesn’t do? If the heart sits there, it’s time to call someone who actually develops; if no-code covers well what you need, keep it and don’t spend more. Distinguishing the two cases is the job, and whoever pushes you to rebuild “always and anyway” isn’t looking at your interest.

A typical case: from the wall to a solid base

A typical profile, architectural, no names. A company had built its product on a no-code platform: in a few months it was online, the first customers used it, and for a year it had been a success — fast, cheap, effective. Then growth: more customers, more data, and the request for functions the tool didn’t allow (articulated permissions for company customers, an integration with their ERPs, a volume the app struggled to hold). The 80% wall in full. And the discovery, trying to evaluate the exit, that the data was stuck in the tool more than they thought.

What was done. First the analysis: where was the wall, exactly? Not everywhere — it was concentrated in two points (permissions and the integration) plus the volume theme. The decision was to tear out the critical pieces, not to rebuild everything: rebuild in a solid way the permissions and integrations part, and the data handling that had to hold the volume, keeping the rest as long as it worked. They kept the design, the flows and — above all — the year’s learnings on no-code, which made the build much more targeted than a from-scratch project. The switch happened in layers, with continuity: customers kept using the product, which at some point simply became faster and did the things that before “couldn’t be done”.

At regime, the difference wasn’t “we rebuilt the app”: it was that the wall had fallen — serious permissions, real integrations, volume held — and the data was finally theirs, portable, without lock-in. No-code had done its job (validate and teach), and real code had built the base to grow. The honest note: it wasn’t necessary to rebuild everything, as instinct suggested — it was necessary to tear out the two right pieces; and no-code hadn’t been a waste, it had been the MVP that made the rest possible.

It’s for you if / it isn’t for you if

It’s for you if: you built in no-code something that became the heart (or an important piece) of the business, and you hit the wall — permissions, performance, integrations, a document that doesn’t come out; the no-code app slows with volume; you discover you’re in lock-in and your data doesn’t really come out; the 20% you’re missing is exactly what you need to grow or not lose customers.

It isn’t for you if: no-code is an internal tool, at low volume, that does its job well and doesn’t have to grow (keep it); you’re still validating the idea and you don’t know if it will hold (no-code is doing its job, it’s premature to switch); your case is covered well by no-code and you haven’t hit any wall. In these cases, moving to code would be a waste.

Frequently asked questions

Was no-code a mistake? No: it took you to 80% spending little and it let you validate the idea and discover what you actually need — enormous value at a low price. It was your MVP. The 80% wall doesn’t mean you were wrong to start from no-code: it means you’ve reached the point where, to grow, you need a more solid base on the 20% that counts.

Do I have to rebuild everything from scratch? Often no. The wall is usually concentrated in one or two points (permissions, an integration, volume): you can tear those critical pieces out and rebuild them solid, keeping the rest on no-code as long as it works. Rebuilding everything makes sense only if the base is rotten at the core. Analyse where the wall is before you decide: don’t rebuild by reflex.

What do you save of the work done in no-code? A lot: the design and the flows (if they work, you reproduce them), the texts and the contents, and above all the learnings — what you actually need, what users use, where the process jams, the edge cases. It’s the treasure a from-scratch project would have had to discover the hard way and that you already have. Moving to code isn’t starting over: it’s building the solid version of something you already know works.

Will I stop the business during the switch? Not if you do it in layers, with continuity: the no-code keeps working while the new piece is being built, and the switch happens when the new is ready and tested. A good switch is invisible to customers: they keep using the app, which at some point is faster and does things it couldn’t before. Never “we switch everything off and hope”.

And my data locked in the no-code tool? That’s the lock-in, and it’s real work: the raw export the tool offers often doesn’t contain the logic and the real relationships. Migrating the data well is part of the switch and has to be done with care. It’s also the reason not to wait too long: the more you grow on no-code, the more the data gets stuck and the more it costs to leave.

How much does it cost to move to code? You pay the full price of real software for the 20% that’s missing and to make the rest solid. Don’t compare it with what you spent on no-code (which served to validate, something else), but with the cost of staying stuck: the lost opportunities, the customers lost because the app slows or doesn’t do that thing, the lock-in risk. If the wall is costing you growth, the switch pays for itself.

When instead should I keep no-code? When it’s internal and low-volume, when it’s a secondary process that doesn’t have to grow, when you’re still validating, or when it covers well what you need without walls. In these cases no-code is the right answer, not a phase, and moving to code would be a waste. The criterion is how much of your value sits in the 20% that no-code doesn’t do.

How do I know if I’ve reached the wall? From the symptoms: fine permissions that don’t get done, the app that slows with volume, an essential integration that’s impossible, a document that doesn’t come out as needed, and the discovery that the data doesn’t really come out of the tool. If you recognise two or three and they concern the heart of the business, you’re at the wall. If they’re snags on secondary things you can work around, maybe not yet.

In one line

No-code takes you to 80% fast and at a low price — and it’s a great deal to validate — but then it slams you into the wall on the 20% that counts: serious permissions, performance under load, essential integrations, a document that doesn’t come out, and the lock-in of your data. When you hit it, don’t rebuild by reflex: analyse where the wall is and often it’s enough to tear out the critical piece, keeping design, contents and — above all — the learnings (no-code was your MVP). The switch is done in layers, with continuity, without stopping the business. And if no-code covers well what you need (internal, low volume), keep it: leaving it behind makes sense only when it’s the heart of the business and it blocks you on what counts.

If no-code has blocked you on the 20% you need to grow, look at the projects I’ve built or drop me a line: we start from where the wall is, exactly, to see whether to tear out a piece or rebuild — without stopping the business and without throwing away what you’ve learned.