No code vs custom development: where no code stops

No code gets sold as custom software with the price removed, and custom development gets sold as no code with the limits removed. Neither description survives contact with a real project, and choosing on that basis is how teams end up migrating twice.

A more useful framing: no code trades control for speed, and it is an excellent trade right up to the point where the thing you need to control is the thing the platform decided for you.

What no code is genuinely good at

It is worth being specific, because the honest case for no code is stronger than its marketing. It is very good when the process is standard, the volume is modest, and the requirements are still moving.

That last one carries most of the weight. Requirements that are still moving are expensive to build against in code and cheap to change in a builder. If you do not yet know what the workflow is, paying an engineer to encode your current guess is close to the worst available option.

Google's own automation tooling is a fair illustration of the ceiling. The Apps Script guide for Sheets documents custom functions, menus, form-submit handling and time-driven triggers, which covers a surprising amount of internal tooling. It also notes that very large datasets, approaching ten million cells, need something else such as Cloud SQL or BigQuery. That is a clean statement of the pattern: broad capability, then a wall.

The four walls you hit, in the order you hit them

Almost nobody hits the volume wall first, which is the opposite of what people plan for. The data model wall comes first, and it arrives quietly. You add a second kind of record, discover the tool assumes one flat table, and encode the difference in a status field that three people interpret differently by the end of the quarter.

Permissions is the wall that turns into a real problem rather than an annoyance, because the workaround is usually to give everybody access and rely on restraint.

The migration cost is the actual decision

Everything above is manageable if leaving is cheap. Mostly it is not, and the cost is concentrated in two places that do not appear in any comparison table.

• History. Two years of records in a shape the new system does not have, including the fields people repurposed.
• Habit. The workarounds staff invented are now the process, and nobody wrote them down.
• Integrations. Each one was configured by somebody who has since left, and the credentials live in one person's account.
• Truth. Reports built on the old structure disagree with the new ones for a quarter, and trust in both drops.

The habit line is the expensive one. You are not migrating a database, you are migrating what forty people do on a Tuesday, and that is the part that overruns.

A test that settles most cases

Ask one question. Is the thing you are building the way you compete, or the way you administer.

Administration should be bought or assembled, almost without exception. Leave requests, expense approvals, an internal directory, a booking form. There is no version of those that wins you anything, and a builder will do them this week.

Where the logic is the business, in pricing rules, commission structures, allocation, anything a competitor cannot copy from your public site, that is where custom earns its cost. We worked the same distinction through a concrete case in when a stock spreadsheet starts costing more than it saves, and the build-versus-buy arithmetic in general is in how much a custom CRM costs.

The hybrid that usually wins

The framing as a binary is the main error. A large share of good outcomes are no code at the edges and custom in the middle, or the reverse: a bought system of record with one narrow custom piece doing the thing nobody else does.

The practical route is to prototype in a builder, run it in anger for a quarter, and let the walls tell you which part deserves code. You will have a specification written by usage rather than by meeting, which is worth more than either tool. What that scoping looks like in practice is in how to scope a software project, and the reasons these projects run long are in why software projects take so long.

The honest limit

Neither choice fixes an unclear process. A builder makes a vague workflow fast to change, and custom development makes it expensive to change, but both will happily encode the confusion. If two people in the room describe the current process differently, that disagreement is the project, and no tooling decision touches it.

That failure has a commercial twin worth reading if you are choosing tooling to fix a sales problem. BDG Labs argues the case in business development as a system problem rather than an effort problem, and the diagnosis transfers almost unchanged.