The app crosses the line long before anyone notices
A Power Platform app crosses from personal convenience to organizational dependency long before anyone in a position to do something about it notices, and by the time someone does notice, the person who could explain how it works has usually stopped thinking of it as their project two teams ago. The pattern is close to identical every time I hear it, whether the app tracks visitor badges, return authorizations, or shift swaps. Someone in operations gets tired of a spreadsheet or a paper log failing them the same way every week, builds a canvas app over a weekend or two, and points it at a SharePoint list because that is the fastest way to store the data they already have.
It works. Their manager notices, mentions it at a leadership meeting, and a second team asks if they can use it too. There is no reason to say no. The maker adds a filter for the new team, maybe a second screen, and feels good about it, because for the first time in a while, their work has an audience that says thank you out loud.
Eighteen months in, the side project is now infrastructure
Eighteen months later the badge tracker, or whatever it has become, is open on fifty desks across four departments. Security checks it before letting a contractor into a restricted area. HR pulls a report from it every month to confirm which contractor badges expired on schedule. Reception in two other buildings uses it because someone forwarded the link and it solved their version of the same problem. Nobody planned this spread. It happened one request at a time, and each request seemed too small to say no to.
None of the plumbing changed to match the load. The app still lives in the maker's personal environment or the tenant's default environment, built and edited directly against the live version, with no earlier copy to restore if a change goes wrong. The Power Automate flow behind it has grown to a dozen conditions, each one added to handle a single edge case a specific person reported, none of it documented anywhere but in the maker's memory. The connection it runs on is tied to the maker's own credentials, so it stops working the day that account is disabled.
This is not a story about someone doing bad work. The canvas app almost certainly does its job well, which is exactly why it kept growing. The failure sits in the organization, not the code. Nobody drew a line and said, past this many users or past this kind of data, the rules change. The environment strategy question and the source control question should have come up at ten users, not fifty.
The maker has good reasons not to let go
I have sat across the table from enough of these makers to know the reluctance is not possessiveness for its own sake. Most of their other work is invisible by design. A shift schedule that runs cleanly draws no attention. The app is different. People stop them in the hallway to say it saved their morning, and for someone whose job rarely gets that kind of feedback, the app becomes the thing colleagues associate with their name.
From where the maker sits, handing the app to IT costs them the recognition it earned, not just the maintenance work they think they are giving away. They picture a formal request queue replacing the two-minute conversation they used to have with a coworker who needed a new field added by lunchtime. They have watched other requests sit in a backlog for months, and they assume their own app will meet the same fate once someone else owns the priority list. Some of them are also quietly aware that the flow underneath has grown messy, and a formal review feels closer to an audit of their judgment than to support.
IT has good reasons not to take it either
The reluctance runs the other way too, and it is just as reasonable. The app arrived without the intake conversation a supported system would have had. There is no documented requirement, no named data owner, no record of why the flow has the branches it has. A platform team asked to support it is being asked to answer for a dozen decisions they did not make and cannot see the reasoning behind.
Supporting one team's convenience tool and supporting the record fifty people and an HR audit depend on are different jobs, even when the file looks the same in the maker portal. If IT absorbs the app exactly as it stands, they inherit every failure with none of the design authority that would let them prevent the next one. That is a bad trade for a team already stretched, and it is why most requests to take an app over stall in the same meeting where they get raised.
The signals show up long before the resignation letter
The moment worth watching for has a shape, and it shows up before anyone leaves. A second department starts using the app for a purpose the maker never designed for, not just one team's manager asking for another license. The app's numbers start turning up in a report that goes to a director who has never heard the maker's name. A value the app writes lands in a table another team already treats as its own source of truth, so a change made for one department can quietly corrupt a record a different department relies on.
It also shows up as a support pattern. When the helpdesk gets a ticket about the app and the honest next step is to message one specific person directly because there is no other name on file, that is the moment, whether or not anyone has said so out loud. I have seen it show up hardest during a two-week vacation, when the app breaks on a Tuesday and stays broken until the maker is back online, because nobody else has ever owned the recovery.
Start the ownership conversation while the maker is still there
The fix does not require IT to seize the app or the maker to walk away from it. Most of what works is closer to a small center of excellence taking over the platform mechanics, the environments and the release path, while the maker keeps the product decisions they are actually good at, now with a second person trained on the flow and named as backup. That conversation, and the release checklist that comes with it, is far easier to have while the maker still wants credit for the app than after they have handed in their notice.
So run the count this week, not after the next resignation. Open the Power Platform admin center, find the app, and check how many people outside the maker's original team opened it in the last thirty days. If that number is bigger than a handful, or if the app writes to data another department already owns, the transfer conversation is overdue, and the best person to have it with is still sitting at their desk.
