Many organizations have made SharePoint and Microsoft 365 lists the core of business processes: requests, tracking, approvals. That is understandable. The tool is already there, low-code moves fast, teams adopt it. Then volume grows, rules intertwine, audits arrive, and the list shows its limits.
When low-code becomes shared debt
Low-code is not the problem. The problem is handing it, without architecture, what requires reliable history, fine-grained rights, performance, and change without breakage. A list that grows without a clear data model becomes shared debt. Nobody wants to touch it. Everybody depends on it. It is a variant of the custom or SaaS debate: where market shape is enough, and where it breaks.
Warning signs are familiar: unreadable calculated columns, fragile Power Automate flows, no business logging, manual exports for reporting. At that stage an application layer, like Portana on SharePoint lists, can make the process governable without throwing Microsoft 365 away. You keep the ecosystem. You regain a sturdier shape.
Collaboration versus critical system
Collaboration and critical systems also need to be distinguished. A shared document library does not have the same requirements as a budget approval circuit. Confusing the two leads to over-engineering the first and under-protecting the second. The right criterion is the consequence of an error, not familiarity with the tool.
So the useful question is not SharePoint or not. It is which part of the process is still collaboration, and which part has become a critical system. On that boundary, a clear-eyed look often avoids rebuilding too early, or too late. For the product, see also portana.io and the Portana catalog entry.