Choosing no-code well is a decision about speed, ownership and where your team should spend its attention. Treat it as a shortcut and it quietly becomes a liability.
When is no-code the right call?
No-code is the right call when the problem is well understood, the volume is modest, and speed to a working thing matters more than owning every layer of the stack. Internal tools, portals, intake flows, the first version of a product you're still learning the shape of — these are where a platform earns its place.
The trap is treating "no engineers required" as the whole argument. It isn't. You are still making architectural decisions; you're just making them faster and with less rope to hang yourself.
Where does it strain?
It strains at the edges of the platform's assumptions. The moment you need a data model the tool didn't anticipate, or a performance characteristic it wasn't built for, you start fighting it — and fighting a no-code tool is more expensive than writing the code would have been.
So the strategic question isn't "can this be built without code?" It's "will this live inside the platform's happy path for as long as we need it to?" If yes, move fast. If no, be honest that you're prototyping, and plan the exit before you need it.
Speed is real value. Just don't confuse renting someone else's constraints with escaping constraints altogether.