Power Platform ALM when the team is one person

A solo Power Platform builder needs two environments, dev and production, managed solutions in every environment except dev, and Power Platform Pipelines to move changes between them without a manual export ritual. That's the whole setup: no Azure DevOps, no YAML, no release board. The rest of the ALM documentation is written for a team with a release board and a change advisory process, and most of it doesn't apply until you have one.

Why building straight into production always goes wrong, even solo

Working directly in a production environment feels harmless when you're the only maker. There's no one to argue with about a change, no approval to wait on, no ticket to raise. That's exactly the problem. Nothing stops you editing a live table structure, changing a flow's trigger, or renaming a field that three other formulas depend on, five minutes before someone needs to use the thing you just touched.

An unmanaged solution in production writes those changes straight into the base layer. There's no clean undo. If a formula breaks a form, or a connection reference points at the wrong environment after a change, you're debugging in front of whoever's trying to use the app, on the app they're trying to use. That's true even when the only person affected is you, checking a job costing sheet from a ute on site with no signal to troubleshoot on.

The other trap solo builders fall into is the Default environment, the one that's already there when you first sign up, shared across the whole tenant. It's tempting because it needs no setup, but it has no environment-level admin control, anyone with a licence in the tenant can see what's in it, and Microsoft's own guidance is not to build anything real there. A dedicated environment costs one extra step and buys you the ability to govern who touches what.

The minimum viable setup: dev and production, nothing more

Microsoft's ALM guidance for larger teams recommends dev, test and production as three separate stages. For a solo builder, the test stage's real job, catching a problem before a user does, is already covered by you clicking through the change yourself before you promote it. Skip it until skipping it costs you something.

What you do need is a real split between where you build and where the business runs. The Power Apps Developer Plan gives any work or school account backed by Entra ID up to three free developer-type environments, full Power Apps, Power Automate and Dataverse, at no cost, built for exactly this. Microsoft disables one after 30 days of no activity and its terms rule out using it for real production work, which is fine, because that's not what it's for.

Your production environment is the one with a Dataverse database the business depends on. If you're licensed for Power Apps per user, per app, or through Dynamics or Microsoft 365, you likely already have one, or can create one from the admin centre. Which Microsoft 365 tier you're on decides more of this than most people expect, and I've gone through what each Business plan does and doesn't include in Microsoft 365 licensing for a small firm.

One caveat: if what you're building is a canvas app or a flow against SharePoint with no Dataverse involved, none of this applies to you yet. Solutions, managed or unmanaged, are a Dataverse concept. Exporting and importing an unmanaged canvas app by hand at that scale is already about as simple as this gets.

Environment type	Free to get	Good for
Developer	Yes, up to three per user	Building and breaking things
Production	No, needs a paid Power Platform or M365 plan	Running the real thing
Trial	Yes, for 30 days	Evaluating a feature, not building on
Sandbox	No	The staging tier a solo builder doesn't need yet

Managed or unmanaged: decide once and stop relitigating it

Unmanaged only in your dev environment, managed everywhere else, no exceptions once a solution leaves dev. Managed solutions install as a locked, removable layer on top of the target environment. You can uninstall one cleanly, upgrade it without fighting your own old customisations, and nobody, including you at 11pm, can accidentally edit a component that a client's staff are relying on right now. Unmanaged solutions write directly into the base layer of wherever they're installed. That's what you want while you're iterating in dev, and a liability anywhere downstream of it.

There's one case where the other choice is fine: a true single-environment tool, something small enough that you haven't set up the dev and production split from the last section at all, built for you alone. If there's no promotion boundary because there's only one environment and one user, managed versus unmanaged doesn't matter, because there's nothing to protect. The moment that tool does a real job for the business, or a second person opens it, go back and build the dev and production split, and this exception is gone.

Getting changes across without a manual export ritual

The old-school way to move a solution from dev to production is exporting it unmanaged, converting it to managed, then importing that file by hand into the target environment, checking dependencies each time. It works, and it's exactly the kind of ceremony that makes a solo builder decide ALM isn't worth bothering with.

Power Platform Pipelines is Microsoft's answer for teams that don't want to run Azure DevOps. It's a first-party app you install into a host environment, where you connect your dev and production environments as deployment stages. From there, deploying is a button in the maker portal: pick the solution, pick the stage, deploy. Pipelines exports it, converts it to managed, and imports it into production for you, and runs solution checker automatically on the way through, flagging performance and reliability issues before they land in front of a real user rather than after.

In February 2026 Microsoft extended pipelines to unify pro-code and low-code deployment in one pipeline and gave custom apps native governance, DLP policies and Entra ID security instead of treating them as an outside system. What a solo builder needs from it stays the same: a deploy button that doesn't require learning a build pipeline language.

Reach for Azure DevOps or GitHub Actions instead when you need automated builds triggered by a code commit, source control across several makers working in parallel, or Power Platform components deployed alongside real code, like an Azure Function or a custom API, in the same release. For most firms at five, ten, even twenty staff with one or two people doing the building, that's never. Pipelines does the job with fewer moving parts than the documentation makes it sound like, and it's the setup I run for my own tools and for the Power Platform and Copilot Studio work I do for clients, most of which is on the work page.

Once the dev environment and the solution exist, they are also what makes an AI coding agent safe to use on the schema. Microsoft's Dataverse skills for coding agents enforce the same environment-first order: change it in Dataverse, export and unpack the solution, then commit.

What to add only when a second person joins

A second owner is also what saves a flow on the day the builder leaves; that case is worked through in the flow that broke the day its builder left.

One reason to add a second owner early is that Microsoft only emails a flow's owners and co-owners when it is about to be switched off; see the 14-day and 90-day rules that turn a flow off.

Everything above holds until there are two makers instead of one. That's when a few extra pieces start paying for themselves.

• Environment groups and rule sets, so governance settings like DLP policies apply consistently across dev and production instead of you remembering to set them twice.
• A proper test stage in the pipeline, now that two people can promote conflicting changes on the same day and someone needs to catch it before production does.
• Source control for solution files, unpacked with the Power Platform CLI into a Git repository, because two people editing the same component without it is how a merge conflict turns into a rebuild.
• A dedicated application user with least-privilege access running the pipeline, instead of it running under your personal login, so a second person's changes don't depend on your account being logged in.

Skipping all of that is fine while it's just you, and stops being fine the day someone else can deploy. That's deployment. The governance side of this, DLP policies, who's allowed to build what, is a related but separate decision, and I've covered it on its own in Power Platform governance for a small business.

The same risk at the level of the whole business, not just flows, and the handover pack to ask for, is in what happens to your business software when the person who built it leaves.

Who can build and administer, as opposed to who can see which rows, is in Environment Maker, System Admin or Power Platform Admin: what to give a contractor.

Common questions