In this article (6 sections)
The question almost always arrives in the same shape: "I saw that this takes a week in Power Apps, why are you quoting me two months?".
It's a good question and it deserves an honest answer, which is not "low-code is no good". Low-code works, and works well. What happens is that it solves a different problem from the one most people think they're buying.
What each one is, without the marketing
Low-code / no-code. Platforms where you assemble an application by combining ready-made pieces: forms, tables, flows, screens. Microsoft Power Apps, Google AppSheet, Retool, Bubble, Airtable, Zoho Creator. The logic gets configured, not written, and the platform takes care of the rest.
Custom development. The code gets written. Everything the application does, it does because someone defined it, and there's nothing the platform decides on your behalf.
The real difference isn't "dragging versus typing". It's who controls the decisions you didn't make: the database, where the data lives, how people authenticate, what happens when a thousand users show up at once, and which version of all that you'll be running three years from now.
Where low-code clearly wins
There's no reason to write code in these cases.
- Internal tools for a small team. A panel for admin to enter something, an internal CRUD screen, a view over data that already lives somewhere else. Retool and AppSheet are made for exactly this.
- Forms and approval flows. A request that goes through two signatures and ends up in a spreadsheet. Configuring it takes hours.
- Prototypes to validate. Before spending on development, put something functional in front of real users. Cheap, fast and disposable on purpose.
- When you already live inside the ecosystem. If the company has Microsoft 365 and the data is in SharePoint, Power Apps is already paid for and already integrated.
In all of these, quoting custom development is selling someone something they don't need.
Where low-code hits the wall
The limits don't show up in month one. They show up when the project grows, which is the worst possible moment to discover them.
The logic ceiling. The platforms cover the usual 80% very well. The remaining 20% — your pricing rule with seven conditions, the tiered commission calculation, the validation that depends on three tables — either can't be done, or can be done with a workaround nobody understands afterwards. And that 20% is usually exactly what makes you different.
The cost per user. This is the most common surprise. Low-code is billed per user per month, and the number that was reasonable with 10 users stops being reasonable with 200. Custom development has a high cost up front and a marginal cost per user close to zero; low-code is the other way around. There's a crossover point, and it's worth calculating before, not after.
Performance at volume. These platforms work very well with thousands of records. With millions, they start showing limits you can't optimize away, because you don't control the queries.
Vendor dependence. This is the one that weighs most in the long run. What you built isn't portable: there's no code to take with you. If the platform changes its prices, discontinues a service or modifies how something works, you have no alternative but to accept it or rebuild from scratch.
The question isn't what it costs to get in. It's what it costs to get out, and whether you can pay that the day you need to.
Integrations outside the catalog. If the service you need to talk to has a connector, it's trivial. If it doesn't, you're into workaround territory, and that's where low-code stops being simpler than writing code.
The four questions that settle the decision
Answer them honestly and the answer shows up on its own.
1. How many people will be using it three years from now?
Multiply that figure by the platform's cost per user, by 36 months. Compare that number against the budget for a build. It's a two-minute calculation almost nobody runs.
2. Is what makes your operation special inside this system?
If the system is administrative and your edge is somewhere else, low-code. If the system is your edge — the way you dispatch, quote or assign — custom.
3. Are people outside the company going to use it?
Customers, suppliers, an external sales force. Here low-code gets complicated on two fronts: the license per external user, and the fact that the experience will wear the platform's face, not yours.
4. What happens if tomorrow you can't use this platform?
If the answer is "we reconfigure it somewhere else in two weeks", go ahead. If it's "we lose the operation", you're putting the business on top of somebody else's commercial decision.
The middle scenario, which is the most common one
It's almost never all or nothing.
What works best in practice: custom for the core, low-code for the edges. The system that holds up your central process gets built and is yours. The internal forms, the team dashboards, the vacation approval flow and the tools four people use get assembled in the platform you already have, and get changed without calling anyone.
This is also a good way to evaluate a provider. Someone who quotes you a development project for an internal approval form isn't looking at your problem, they're looking at their invoice.
And the other way round: if they tell you that your entire business system, with integrations and external users, gets solved in three weeks of configuration, ask them to show you a similar case running at your volume.
A cheap way to not get it wrong
When the decision isn't obvious, there's a path that almost always pays off: build the first version in low-code, even if you plan to migrate.
In a couple of weeks you have something running, with real users using it. Two things come out of that which no requirements-gathering session gives you: you discover the cases nobody mentioned, and you find out whether the platform's ceiling is far away or close.
If six months later the tool is still enough, you saved the build. If it isn't, you arrive at the build with the scope defined by real use instead of by a meeting, which is the difference between a quote that holds and one that stretches.
The only thing you have to get right on that path is not getting attached: the low-code version gets built knowing it may be disposable, and the data gets stored in a way that can be exported the day you need it.