Build or Buy a Power Platform App? A Decision Framework

Building is sensible when the workflow is distinctive, the organisation can own the product after launch, and the Power Platform constraints are acceptable. Buying is sensible when a supported product already covers the important requirements and its data, integration and exit terms are acceptable.

Neither route is automatically cheaper, faster or safer.

The useful decision is not simply build or buy. It is usually a choice between four shapes:

use an existing Microsoft 365 or line-of-business feature;
configure a product already owned;
buy a specialist product or add-on;
build and operate a custom Power Platform solution.

An LMS is a good worked example because it exposes the awkward questions quickly. It may need identities, content, completion records, reporting, reminders, accessibility, retention, integrations and support. A canvas app alone does not make that an operated learning service.

Start with the decision, not a product demo

Write a one-page decision record before asking vendors for demonstrations or opening Power Apps.

Record:

the users and job to be done;
five to ten requirements that would make the solution usable;
data sensitivity, retention and residency requirements;
integrations and who owns each one;
expected user groups and external-user scenarios;
availability and recovery expectations;
the person accountable for the service after launch;
an exit test, including how data and business rules can be recovered.

Keep must have, useful and out of scope separate. Without that separation, a custom build absorbs every suggestion while a product demonstration makes optional features look essential.

The nine questions that expose the real trade-off

1. Can an existing capability do the job?

Check what the organisation already owns before adding another product or application. This is not a request to force a poor fit. It is a check against paying to duplicate a usable capability.

Compare the whole workflow, not a feature list. A form, a SharePoint library and an approval flow may cover a small internal process. They do not become an LMS merely because they can store content and record a status.

2. How much variation is genuinely valuable?

Build where the unusual workflow creates real operational value. Buy where the differences are mainly preference.

If users can work effectively with the product's standard process, custom code or low-code configuration may add ownership without adding much value. If the workflow depends on unusual approvals, data relationships or integration rules, a custom app may fit better.

3. What does licensing look like for every user?

Power Platform licensing depends on the products, connectors, Dataverse use, environment type and how people run the solution. Microsoft advises customers to use the current licensing guidance and tenant-specific assessment because product terms change.

Do not price a build from maker licences alone. Identify makers, end users, unattended automation, service accounts, premium connectors, Dataverse capacity, Managed Environments and any external-user path. Then have the Microsoft licensing position checked for the proposed architecture.

A vendor subscription needs the same scrutiny. Check active users, guests, administrators, storage, API access, support tiers and renewal terms. Avoid copying today's price into a long-lived decision record.

4. Who owns the data and the exit?

Buying can create dependency on a vendor's contract, schema and export facilities. Building can create dependency on your tenant, connectors, components and the people who understand the design.

Ask both routes to prove an exit:

export representative records and attachments;
preserve identifiers and relationships;
document business rules and integrations;
state what is deleted, retained or inaccessible after termination;
estimate the work needed to move or rebuild.

"It is in our tenant" is not an exit plan.

5. Where does responsibility sit?

A bought product transfers some product engineering and service operation to the supplier. It does not transfer your responsibility for identity, configuration, data quality, lawful use, access reviews or integration failures.

A custom build needs named owners for product decisions, platform administration, support, security review, data, releases and supplier dependencies. If these roles are blank, the build is not yet a supportable option.

6. Can it move safely between environments?

Microsoft's application lifecycle management guidance treats planning, development, testing, deployment, operation and retirement as one lifecycle. Power Platform solutions are the normal mechanism for moving Dataverse-based components between environments.

For a build, prove that the app, flows, connection references, environment variables and required data can be promoted without manual reconstruction. For a bought product, ask how configuration changes are tested, released and rolled back.

7. What happens when a dependency fails?

List the services that can stop the workflow: identity, connectors, gateways, APIs, email, Dataverse, SharePoint, vendor services and scheduled flows.

For each one, define detection, user communication, retry behaviour, data reconciliation and the owner who responds. A happy-path demonstration is not reliability evidence.

8. What security and governance controls apply?

Map roles to the minimum data and actions they need. Review connector use, environment placement, sharing, audit needs and privileged administration.

Microsoft's current environment strategy guidance recommends treating environment design as an evolving operating model, not a one-off setup. Some governance capabilities, including parts of Managed Environments, have premium licensing boundaries.

Certification, a security questionnaire or a tenant location is useful evidence, but none proves that your particular configuration is compliant. Your organisation still needs its own security, privacy, accessibility and records review.

9. What will prove the decision after a pilot?

Use a representative pilot, not a friendly demonstration.

Test the hardest data shape, least privileged user, integration failure, recovery path, accessibility requirement, reporting need and export. Record observed results beside the requirements. Do not convert projected savings or vendor examples into measured outcomes.

A simple decision rule

Choose the least custom option that passes the important requirements and has an acceptable operating model.

Build when the distinctive workflow matters enough to justify ongoing ownership. Buy when the product fit and supplier responsibilities reduce work without creating unacceptable dependency. Configure what you already have when it genuinely passes the same test.

A hybrid answer can be right. For example, a specialist LMS may own enrolment and learning records while Power Automate handles a carefully bounded notification or HR hand-off. The integration then becomes a product in its own right, with an owner and failure plan.

For practical reviews of Power Apps architecture and ownership decisions, join the Power Apps Builders Space. Bring a sanitised requirement and the awkward constraint, not tenant secrets or real personal data.

Sources

These sources support the platform, lifecycle and licensing boundaries. They do not prove that building or buying will produce a particular cost, delivery date, adoption level or business outcome in your organisation.