Before anything critical: no-code got you a working product without hiring anyone, and that is a real achievement rather than a compromise to apologise for. You found out whether people wanted the thing, which is the only question that mattered, and you did it for a fraction of what a build would have cost.
The no-code versus custom development question is not about which is better. It is about whether you have hit one of four specific walls, because everything else has a cheaper answer than rebuilding. Most people who think they need to move do not, and most who genuinely do have known for a while.
No-code vs custom development: the four walls
- Cost at scale. These platforms price per user, per record, per action or per workflow run, and the pricing is generous at the start and steep later. The wall arrives when your monthly bill has become a number that would fund development, and it usually grows fastest exactly when the business is going well.
- Logic the tool cannot express. Not features, logic. Pricing that depends on several interacting rules, scheduling with real constraints, anything conditional in a way the builder was not designed for. The tell is that you have built something elaborate and fragile to fake it, and only one person understands it.
- Performance with real data. Fine with a thousand records, slow with fifty thousand, and there is often no lever to pull because you do not control how queries run. This one arrives suddenly rather than gradually.
- Ownership and where the data sits. Usually not a problem until a customer's procurement asks where their data lives, or you want a security review, or you need something the platform does not offer at any price. Then it is not a performance issue, it is a commercial one.
Notice what is not on that list: the site looks like it was built with the tool, a developer told you it is not real software, or you would prefer to own it. None of those justify a rebuild on their own.
The signs you are getting close
- Your monthly platform bill is now a meaningful line in your accounts rather than a rounding error.
- One person understands the workaround, and everyone else is afraid to touch it.
- Changes take longer than they used to, because each one risks breaking something elsewhere that nobody can see.
- You have started saying we cannot do that about things customers ask for, more than once a month.
- Something is slow and there is nothing you can do about it.
- A customer has asked a question about security or data location that you could not answer.
One or two of these is normal and is not a reason to move. Four or more, particularly if one of them is the bill, and it is worth doing the arithmetic properly.
The cheaper answers people skip
Before a rebuild, three options that cost far less and solve a large share of cases.
- Fix the pricing tier problem. Sometimes a different plan, or restructuring how records are stored, changes the bill substantially. Worth an afternoon with someone who knows the platform well before assuming the cost is fixed.
- Build one piece alongside it. Keep the tool for everything it does well, and build only the part it cannot do, connected to it. Frequently a fraction of a full rebuild, and it is reversible if you are wrong.
- Move the heavy part only. If the problem is performance on one large table or one slow process, that specific piece can often be moved out while everything else stays. You are not obliged to migrate all or nothing.
The middle option is the one we recommend most and the one nobody offers, because it is a smaller job. Ask any supplier proposing a full rebuild what the partial version would look like, and judge their answer.
Compared over time
| Stay on no-code | Build one piece alongside | Rebuild properly | |
|---|---|---|---|
| Up-front cost | Nothing | $10,000 to $40,000 | $40,000 to $150,000 and up |
| Monthly | Platform fees, rising with use | Platform fees plus hosting | Hosting, plus people who can maintain it |
| Speed of change | Fast, until the workaround breaks | Fast on the platform, normal on the built part | Normal, and predictable |
| Who can change it | You or anyone who learns the tool | Both, and you need both skills available | Developers |
| Ceiling | Real, and you meet it suddenly | Pushed back considerably | Whatever you build |
| If you are wrong | Cheap to change direction | You lose one piece | You have spent the money |
Illustrative ranges from the kind of work we quote, not a price list. The bottom row deserves more weight than it usually gets: the asymmetry between being wrong on no-code and being wrong on a rebuild is large.
Do the arithmetic before the argument
This decision is usually made on feeling and then justified afterwards. It becomes much easier when the numbers are on paper, and the exercise takes an afternoon.
- Work out your platform cost over three years at your expected growth, not at today's usage. These pricing models scale with users, records or actions, so project the number rather than reading it off this month's invoice.
- Add the workaround tax. Hours a month spent maintaining the elaborate thing that fakes what the tool cannot do, plus the cost of the risk that only one person understands it.
- Add what you are not doing. The features you stopped attempting and the customers you did not pursue. Hard to quantify, and worth an honest estimate rather than a zero.
- Against that, set the build plus three years of maintenance, at roughly 15 to 25 per cent of the build a year, plus the months during which you will be rebuilding rather than improving.
- Then look at the partial option, which usually beats both: the platform cost as it is, plus one piece built properly, plus its maintenance.
In our experience the middle column wins this comparison more often than either extreme, and it is the one that never gets calculated because nobody proposes it. If the arithmetic is close, stay where you are: the cost of being wrong is far lower on that side.
Migrating without losing what you learned
If you do move, the valuable thing you own is not the software. It is the accumulated knowledge of what your users actually do, which is embedded in the thing you built, and it is easy to throw away by treating a rebuild as a fresh start.
- Document the current behaviour before touching anything. Every screen, every rule, every workaround and why it exists. This is the specification, and it is more accurate than anything you would write from imagination.
- Get your data out early, before you commit, and check that what came out is complete. Some platforms export less than you expect, and it is better to find out now.
- Write down what you would not build again. Two years of use has taught you which features nobody touches. A rebuild that faithfully reproduces everything, including the dead parts, is a wasted opportunity and a larger bill.
- Move in pieces, not all at once, running both alongside each other. All-at-once migrations of a live product are how businesses lose customers during a switchover.
- Keep the platform running until you are certain. The subscription for a few extra months is the cheapest insurance in the project, exactly as it is when leaving any platform.
If what you have was assembled with AI tooling rather than a no-code builder, the gap is different and often narrower, and is our AI-built app production ready covers what closing it involves. And if you are earlier than all of this and simply weighing what to build first, how much does an MVP cost sets out the bands.
One further point about timing, since it is the part founders get wrong most often. The worst moment to rebuild is while you are still winning customers quickly, because a rebuild takes months during which the product barely changes, and you will spend that time watching competitors ship while you reproduce things you already had. If growth is strong and the walls are still some way off, buy time with the partial option and rebuild during a quieter period, on your own schedule rather than under pressure.
Not for you if
The test we would apply: write down the specific thing your tool will not let you do, in one sentence, without using the word scale. If you cannot, you have not hit a wall yet. If you can, and it is one of the four above, you have a real decision rather than a frustration.