No-code handles considerably more than most development firms admit, and it fails in ways most no-code advocates do not mention. Both statements are true, and the useful question is which specific properties of a project decide between them.
Feature count is not one of them. Plenty of no-code applications do a great deal. What pushes a project across the line is a different set of things.
The four triggers
Logic that branches on itself. No-code tools handle sequences well and conditions reasonably. They handle rules that depend on other rules badly. A pricing calculation with fourteen interacting conditions, or an approval flow whose path depends on the outcome of an earlier approval, becomes something nobody can safely change inside a visual builder. The rule is not that it cannot be expressed, it is that it cannot be reviewed.
Real permissions. Most no-code platforms model access as which records a user can see. If you need permissions that depend on relationships, meaning a manager sees their team's records but only during an active review period, and finance sees the totals but not the names, you are usually past the boundary. Getting this wrong is a security incident rather than a bug, and the platform will not warn you.
Pricing that scales with the wrong thing. Per-record, per-run and per-seat pricing is fine at small volume and can become the dominant cost of the system at scale, entirely disconnected from the value delivered. A workflow that runs a hundred times a month and one that runs a hundred thousand times are different commercial propositions on the same platform.
Data you cannot put there. Regulatory, contractual or customer constraints on where data lives will settle the question regardless of everything else.
If none of these apply, no-code is very likely the right answer, and building custom software instead is spending money to end up in the same place more slowly.
What no-code is genuinely good at
Internal workflows where the process matters more than the interface. Approval chains, request intake, simple record keeping, connecting systems that both have decent APIs, and reporting layers assembled from data that already exists.
It is also the best available way to find out whether a process is worth automating at all. Building the workflow in a no-code tool, running it for a month and watching what people actually do produces better requirements than any amount of specification, and it costs a fraction of a build. Several of the projects that reach us as custom development requests should start this way, and we say so.
What custom is genuinely good at
Anything where the logic is the product. Anything with permission rules that describe relationships rather than record ownership. Anything that has to run at a volume where per-operation pricing becomes the main cost. Anything you intend to own for years and change continuously.
Custom also wins on a less obvious axis: the ability to be inspected. Business logic in code can be read, tested, and reasoned about by someone who did not write it. The same logic spread across a visual builder's conditions and automations frequently cannot, and that is the property that determines whether a system can still be changed in year three.
The costs people compare wrongly
The usual comparison is a no-code subscription against a build price, which compares the wrong things.
No-code carries a build cost too, in the time of whoever assembles and maintains it, and that person is usually not tracking their hours against the project. It carries platform risk, since pricing and features change on someone else's schedule. And it carries a migration cost that arrives if you outgrow it, which is generally worse than a migration between conventional systems because the logic has to be reconstructed from a visual representation rather than read from source.
Custom carries maintenance as a genuine recurring commitment. Dependencies need updating, integrations break when the systems on the other end change, and a product that stops changing while the business changes becomes an obstacle. Ours runs $2,000 to $6,000 per month for products still actively moving.
Compare the two as total cost of ownership over three years, including the person maintaining the no-code build and the probability of outgrowing it. The answer changes materially depending on volume and how long you expect to keep the system.
The hybrid that usually wins
The best answer for most businesses is not one or the other. It is no-code for the workflows that are common to every company, and custom for the part that is actually yours.
That means using purchased and assembled tools for intake, notification, scheduling and reporting, and building only the mechanism that makes your business different. It keeps the custom surface small, which keeps it cheap to own, and it puts the development effort where the differentiation is.
It is also what most of our integration work is: connecting the tools a client already has, and writing the thin custom layer that makes them behave the way the business actually operates. That work runs $5,000 to $15,000 and does not require replacing anything.
Frequently asked questions
Is no-code cheaper than custom development?
Usually to build, and not always to own. The comparison has to include the time of whoever maintains the no-code system, the platform's pricing as your volume grows, and the cost of migrating if you outgrow it. Over three years the ranking often reverses at scale.
Can we start with no-code and rebuild later?
Yes, and it is frequently the right order. Running the process in a no-code tool for a few months produces requirements that are grounded in what people actually did. Keep the data exportable and document the rules as you add them, because reconstructing logic from a visual builder is the expensive part of the eventual migration.
What about AI features in no-code tools?
Fine for connecting a model to a workflow and getting an output in front of someone. The limits appear where any serious AI work concentrates: getting to data the platform cannot reach, and evaluating output quality systematically. Neither is well supported.
When should we definitely build custom?
When permissions depend on relationships, when the business logic branches on itself enough that nobody can review it, when per-operation pricing would dominate your costs, or when the data cannot live on a third-party platform.
Do we need developers to run no-code?
Not to build, but usually to keep it working. Someone has to own the system, understand what breaks when a platform changes, and hold the rules in their head. That role exists whether or not it appears on an org chart.
Where to start
If you are unsure which side of the line your problem sits on, that question is answerable in days rather than weeks. Our audit does it and produces a scope either way, starting at $3,000 and credited toward a build if one is needed.