Power Platform or a custom build: how to decide

Almost every business application project we see starts with the same question: should this live on Power Platform, or should we build it ourselves? Both answers can be right. Both can also be expensive mistakes when they are chosen for the wrong reasons.

This guide walks through the factors we look at with clients before a single table is designed. None of them decides the matter alone. Together they usually point clearly in one direction, or toward a hybrid.

Start with who uses the application

The first question is not technical. It is about the people who will open the app every day.

If the users are your own employees, already signed in to Microsoft 365, Power Platform has a strong head start. Identity, security groups, Teams integration and mobile access come with the platform. A model-driven app on Dataverse gives you forms, views, search and role-based security without writing that plumbing from scratch.

If the users are customers, partners, suppliers or the general public, the picture changes. External users need their own sign-up flow, their own branding and often a very specific experience. Power Pages can cover some of that, but a custom web application is often the more natural fit.

Licensing follows the users

Power Platform licensing is per user or per app, with separate models for external access and capacity. The cost of a solution grows with the number of people who need a license, not with the amount of work the app does.

For a team of thirty internal users, that is usually easy to justify. For several thousand occasional users, it deserves a careful calculation. We do not quote prices here because Microsoft changes plans and terms regularly. Check current Microsoft licensing for your exact scenario, including which connectors are premium, before you commit.

A custom build has a different cost profile: higher upfront development, then hosting and maintenance that scale with load rather than with headcount.

Look at the data

Dataverse is a capable relational store with security, auditing and business rules built in. For most line-of-business applications, the data fits comfortably.

Things get harder in a few specific situations:

• High-volume transactional data, such as millions of events or sensor readings per month. Dataverse storage capacity is licensed, and heavy write loads run into service protection limits.
• Complex reporting queries that join many large tables. These often end up in a separate analytics store anyway.
• Data that must stay in a specific location or system for regulatory or contractual reasons.

PostgreSQL behind a custom API handles large volumes and complex queries well and gives you full control over indexing and schema. You also take on responsibility for backups, migrations and security that Dataverse would otherwise handle for you.

Be honest about UX requirements

Model-driven apps are efficient for data entry and back-office work. They are not designed to look like your brand or to guide a first-time visitor through a polished flow.

Canvas apps give more visual freedom, but they become hard to maintain once screens multiply and logic spreads across formulas. PCF components help fill specific gaps, such as a custom grid or a map control.

If the core of the product is the experience itself, a custom React or Next.js front end is usually the better investment. That applies to customer portals, self-service onboarding and anything where conversion matters.

Map the integrations

Power Automate and the connector catalog make many integrations quick to set up. Connecting to SharePoint, Outlook, Dynamics 365 or a common SaaS tool often takes hours rather than days.

The limits show up with:

• Systems that only offer SOAP, file drops or unusual authentication.
• Integrations that need precise error handling, retries and idempotency.
• High-frequency syncs where flow run limits and throttling matter.

For these cases we usually move the integration logic into Azure Functions or a Node service, even when the main application stays on Power Platform. A custom build handles them natively, but every connector you would have received for free now has to be written and maintained.

Think about ownership and the long run

With a custom build, you own the code. You can host it anywhere, hand it to another team or change direction without asking a vendor. You also own every security patch, dependency update and infrastructure decision.

With Power Platform, Microsoft runs the platform and ships updates on its schedule. You get less operational burden and a large pool of people who know the tools. In return, you accept platform limits, licensing changes and a degree of lock-in.

Neither is better in the abstract. The question is which trade-off your organization is ready to carry for the next five to ten years.

Who will maintain it

A practical test: who will change this application a year from now? If you have, or plan to build, an internal team comfortable with Power Platform, a low-code solution can evolve quickly. If your developers already work in TypeScript and PostgreSQL, a Power Platform app may end up as an orphan nobody wants to touch.

The hybrid option is often the best one

Many of our projects end up somewhere in between. A common pattern looks like this:

1. Dataverse holds the core business data and the internal processes.
2. Employees work in a model-driven app with role-based security.
3. A custom Next.js portal serves customers or partners, talking to Dataverse through a secure API layer.
4. Azure Functions handle heavy integrations and scheduled jobs.

This gives internal users the speed of the platform and external users an experience designed for them. It also limits licensing to the people who actually work in the back office.

The cost of a hybrid is architectural discipline. You need clear boundaries, one owner for each piece of data and a consistent security model across both sides.

A hybrid is not a compromise when it is designed on purpose. It becomes one when it grows by accident.

Common mistakes we see

• Choosing Power Platform because "we already pay for Microsoft 365", without checking which features actually need premium licenses.
• Building a custom app for ten internal users who would have been well served by a model-driven app in a few weeks.
• Pushing a canvas app far beyond its comfort zone until nobody can safely change it.
• Starting a custom build without budgeting for hosting, monitoring and ongoing maintenance.
• Treating the decision as permanent. A well-structured Dataverse model can later sit behind a custom front end, and a custom app can integrate with Power Platform where it makes sense.

A short checklist

Before you decide, answer these questions in writing:

• Who are the users, and how many of them are internal versus external?
• What does licensing cost at today's user count and at three times that? Check current Microsoft licensing.
• How much data will the system hold after three years, and how fast will it grow?
• Is the user experience a differentiator or a tool for getting work done?
• Which systems must it integrate with, and how do they expose data?
• Who will maintain and extend the application after launch?
• How much lock-in is acceptable, and what would an exit look like?
• Could a hybrid split serve each group of users better?

If the answers point in different directions, that is normal. It usually means the right design has more than one part, and it is worth spending a few days on architecture before spending months on code.