Frank van Esch
Low-code isn't the opposite of pro-code. It's a sliding scale, and the question is always: where on that scale does this case sit. The answer is rarely at either end. Most of the solutions we build land somewhere in the middle, and they keep shifting over their lifetime too.
The tricky part is that the scale has no clear line drawn on it. You only notice you've crossed one when maintenance starts to pinch, or when a colleague asks something you can no longer answer in a single breath. Three checkpoints help us see that movement earlier, before it starts to hurt.
1. Can you explain it to whoever takes it over?
The first question is a handover test. If a colleague who isn't a developer can still follow the solution six months from now, you're in good low-code territory. It's traceable, and traceable means maintainable.
It tips over the moment formulas appear that nobody else dares to touch. That happens gradually. A filter that started as one line grows into a nested construction with If, AddColumns and a sort that happens somewhere in the middle. The app still does exactly what it should, but it has become code, with a low-code coat thrown over it.
At that point it helps to be honest about what it is. Treat it as code: put it in source control, write down what it does, and give it an owner. Not because low-code is sloppy, but because something you can no longer explain isn't low-code anymore, whatever you call it.
2. Are you fighting the platform?
One workaround is fine. Every platform has corners you work around, and there's nothing wrong with that. A workaround on top of a workaround is a different story. That's a signal.
The pattern is recognisable. You force a gallery to behave like a data grid, and to get that working you need a second trick, and to keep that standing a third. At some point you're spending more time outsmarting the tool than building the thing itself. That's when a PCF control or a Code App is often more honest than another layer on top.
The test is simple: are you still building with the platform, or against it? The first is low-code at its best. The second is an announcement that you're moving towards pro-code, whether you like it or not.
3. Performance and maintenance at scale
An app for ten people can be a second slower. Nobody notices. At a thousand users it's a different matter.
Scale changes the requirements. Queries have to stay delegable, so the database does the heavy lifting and not the user's phone. Changes have to be testable without discovering the problem in production. That's where pro-code wins, not because it's prettier, but because you have more grip on it: tests, versions, and a release you can roll back.
Low-code and pro-code side by side
It helps to see the two not as better and worse, but as answers to different questions.
Low-code is fast, sits close to the user, and has a low barrier: someone without a developer background can build along and think along. The price is that your grip loosens as soon as it gets complex.
Pro-code gives you control, testability and calm as things grow. The price is that you need developers and a lifecycle around it. Neither is better than the other. They fit a different phase, a different volume and a different team.
The exception
Sometimes we build low-code anyway, even when these rules point to pro-code. Namely when the team has to maintain the solution itself and there's nobody to keep the pro-code alive.
A solution nobody can maintain isn't a solution, however neatly it's put together. A slightly slower app the team can change itself is then worth more than a tidy codebase that stalls the moment its builder leaves. Maintainability is a form of quality too, and often the form that lasts longest.
The scale keeps moving, even after you've chosen. The craft isn't in the first choice, but in noticing when a case has shifted, and being honest enough to do something about it.