One of the internal applications I shipped this year took one day of analysis and between two and four days of work. Not a prototype — a thing in production, with corporate sign-in, a database, a deployment pipeline, and a gate that stops the deploy when a dependency turns up vulnerable.
That number is the whole argument of this post, because of what it used to be.
The skeleton used to be the expensive part
Sign-in, an API, a database, hosting, CI. Two years ago that was a fortnight of work before you wrote the first line anybody outside the project would care about. So when someone asked for an internal app, the low-code platform had an enormous head start — not because it was better at the job, but because it already had the boring half finished.
Take that fortnight away and the comparison changes. The platform still does everything it did; the alternative just got much cheaper. Nothing about the technology moved. The price of the other option did.
Four applications, none of them on the platform
Over the past year I built four internal applications for one client, alongside a CRM that has been running there for years: an approval workflow spanning departments, capacity and date planning, master data as a single source of truth for downstream systems, and the company org chart.
None of them runs on Power Platform. I am a certified architect on it and it has paid my bills for fifteen years, so that deserves an explanation rather than a shrug.
What actually decides it
Whose data is it? If the data belongs in the CRM anyway — if it should inherit that system's security model, audit trail and links to customers and deals — then building beside it is self-harm. Platform, no argument. Most processes that present themselves as "we need an app" are really the life cycle of a record that already exists in a system you own.
Is it a form over data, or is the interface the product? This is the most reliable test I know. A capacity planner is a surface you drag things across, where blocks overlap and the app has to tell you about the conflict. An org chart is a graph being drawn. Both can be forced into a platform grid, and the result is something people use because they have to.
Who uses it? The org chart has to be visible to every employee. Per-user licensing makes that a completely different calculation from an app for twelve people in sales. That single question settled the decision before technology came up at all.
Who maintains it? If an internal non-developer has to own it after you leave, the platform wins even when it loses on everything else. This is the strongest argument low-code has, and the one its advocates somehow mention least.
The question that is not about one app
The most interesting decision in that set of four was this: none of them was decided on its own.
The approval workflow is the closest to a textbook platform case. On its own, that is where it would have gone. But it was not going to stand on its own — it had to stand beside the planner, the master data and the org chart, with one sign-in, one visual language and one deployment. Two on the platform and two beside it would have meant two sign-ins, two places to look when something breaks, and two parties to coordinate on every change.
By the fourth application in a row, the question stops being "where does this one belong" and becomes "where does this set belong".
Why I am not building a starter kit
The obvious move at this point is to extract the skeleton into something reusable. Four applications of the same shape — why pay for it four times?
I deliberately do not. A starter kit was an asset while the skeleton cost two weeks. Once it costs a day, a shared library is a liability rather than an asset: it has to be maintained, versioned, migrated and explained, and all of that is spent to save something that is no longer expensive. With client-owned code the ownership question usually answers itself unfavourably too. What travels between engagements is not the code — it is the shape of the decision and what you know about it.
What did not get cheaper
The day of analysis did not. Working out what the process actually does, who works around it and why, takes exactly as long as it did five years ago. Everything around that day got faster.
Which is the same conclusion I reached writing about building with AI: the data model did not get cheaper, security did not get cheaper, and neither did what happens in three years when somebody else inherits it. Only writing the code did — and that alone was enough to change how one of the most common architecture questions should be answered.
So the question was never "custom or platform". It is what is genuinely expensive about this particular problem — and that answer moved, while most of the arguments I hear in these discussions stayed where they were.
If you are working out what belongs on the platform and what belongs beside it — or you suspect the call was made wrong — reach me at vit.lachner@email.cz or on LinkedIn.