The email arrives on a Monday morning. A key employee has left, and with them goes the institutional knowledge behind three business-critical apps. No documentation. No handover notes. Just a collection of Power Apps that run payroll reconciliation, vendor onboarding, and field service scheduling. Apps that nobody on the remaining team fully understands.
This isn't a hypothetical. It's the situation I walked into with three separate clients this year alone. In each case, the apps worked. They just couldn't be touched without breaking something. And the business was completely dependent on them.
That's the trap. Power Apps makes it easy to build something that runs. It doesn't make it easy to build something that lasts.
The Problem Nobody Talks About Until It's Expensive
Power Platform democratises development. That is its value proposition, and it's genuine. But democratised development without guardrails produces something specific: a portfolio of apps that each live in their own universe, built by different people, at different times, with different assumptions baked in.
When there's no environment strategy, no separation between development, test and production, every change becomes a live experiment. A maker tweaks a flow in what they think is a safe space. That flow touches a shared connector. The connector is used by four other apps. Two of them break silently.
The IT manager finds out on Friday afternoon when a department can't submit expense reports.
What This Actually Costs
Here's a realistic scenario I've seen play out:
A mid-sized company has 40 Power Apps in production. No ALM pipeline. No environment separation. A new IT director inherits this portfolio and is tasked with adding SSO enforcement across all apps.
The project was scoped at 3 weeks. It took 5 months.
Why? Because without proper solution layering, every app had to be opened, manually inspected, and partially rebuilt to accommodate the new authentication model. Connectors were hardcoded. Environment variables didn't exist. One critical app had been built directly in the default environment and couldn't be exported cleanly.
At a conservative blended rate of £75 an hour for internal IT staff and external consultants, that unplanned extension cost roughly £60,000, for a project that should have been a configuration exercise.
The root cause wasn't the SSO requirement. It was the absence of an environment strategy from day one.
Red Flags You're Already in This Situation
- Your makers build directly in the default environment because "that's where everything is"
- You have no documented inventory of what each app does, who owns it, or what data it touches
- Promoting an app from test to production means manually recreating it, or just hoping nothing breaks
- Connection references are hardcoded to specific user accounts, some of whom have left the company
- You've had at least one incident where a "small update" broke an unrelated app
- No one can tell you, with confidence, how many apps are actually in production right now
If three or more of those are true, you're not managing a Power Platform portfolio. You're managing a liability.
What Happens When It Breaks (A Real Pattern)
One client, a logistics company with around 200 employees, came to me after their warehouse intake app stopped working mid-shift. The app had been built by a consultant two years prior. The consultant was gone. There was no documentation. The Power Automate flow behind it was authenticating through a personal Microsoft account that had been deprovisioned when that consultant's licence expired.
Rebuilding the app from scratch took four days. The operational disruption during those four days cost more than the original app build.
The deeper issue: nobody in the organisation knew this dependency existed. It wasn't visible in the admin center. It wasn't in any documentation. It was just there, silently, until it wasn't.
The Environment Strategy That Prevents This
A proper Power Platform environment strategy isn't complex. It does require intentional decision-making upfront.
What a mature environment strategy looks like:
| Environment | Purpose | Access Level |
|---|---|---|
| 🔴 Default | Personal productivity only | Restricted, no DLP exceptions |
| 🟡 Development | Maker sandboxing | Makers + IT oversight |
| 🟠 Test / UAT | Structured QA | Makers + business testers |
| 🟢 Production | Live business apps | IT-controlled deployments only |
- ALM Pipeline: Pipelines or Azure DevOps → solution-aware deployments
- Documentation: CoE Starter Kit → automated inventory and governance
- Ownership: Each app has a named business owner, not just a maker
This structure means a change in development never touches production directly. It means you can audit what exists. It means when someone leaves, the app doesn't leave with them.
Decision Framework: Where Do You Start?
If you're inheriting or auditing an existing portfolio, run this sequence:
- Inventory first. Use the CoE Starter Kit to generate a full app and flow inventory. Don't skip this: you can't govern what you can't see.
- Classify by risk. Which apps are business-critical? Which touch sensitive data? Which are owned by people who might leave?
- Identify environment violations. How many production apps live in the default environment or a dev sandbox?
- Assess ALM maturity. Is there any deployment process, even informal? Or is "go live" just opening the app and clicking publish?
- Define your DLP policy. Data Loss Prevention policies should be set at the environment level before you standardise anything else.
- Prioritise the critical apps for migration. Don't boil the ocean. Move your top 5 risk apps into a proper environment structure first. Use that as your template.
- Establish a maker governance process. New apps don't go into production without a solution file, a named owner, and documented connector dependencies.
This is a 60 to 90 day remediation arc for most organisations with fewer than 100 apps. Longer if the portfolio is large or the default environment is deeply embedded in daily operations.
The Uncomfortable Truth
Power Apps failures rarely look like technical failures. They look like IT credibility failures: a project that ran over budget, a department that lost access to a critical tool, an audit finding that nobody can explain.
The technology worked exactly as designed. The problem was never the platform. It was the absence of a strategy around the platform.
CTOs and IT directors who've been in the industry long enough have seen this pattern before: with SharePoint, with Access databases, with Excel macros running mission-critical processes. Power Apps is the current version of the same story: a powerful tool adopted faster than the governance to support it.
The organisations that get ahead of this aren't the ones with the biggest IT budgets. They're the ones that asked the right questions before the problem became a crisis.
Not sure where your organisation sits? Half an hour on Teams, no charge: we look at how your environments are set up, and I name the three biggest governance risks I see and what I would fix first. Send me a message.