Power Apps vs custom software development: which one should build your internal business app

Three different forks get discussed with the same words, and mixing them up is how companies end up comparing the wrong two things. If you are deciding whether to commission anything at all rather than license a packaged product from a vendor, that is the build-versus-buy question and it is answered on Power Apps versus buying off-the-shelf software — start there, because everything below assumes you have already decided that no product on the market fits your process. This page answers the fork that comes next: having decided to have something built, do you have it built on Microsoft’s low-code platform or written from scratch by a development shop. (A third variant exists where the product on the table is Microsoft’s own — that one is Power Apps versus Dynamics 365 for a small business.)

The two options are more different than the quotes suggest. A Power Apps build is an application assembled inside a tenant you already own, using an identity system, a hosting platform, a data service and a mobile client that are already running and already paid for. A bespoke build is an application written for you — a front end, a database, an authentication layer, a hosting environment, a deployment pipeline and a backlog of dependency upgrades — delivered as source code that becomes your asset and your responsibility on the same day.

Both are legitimate. What follows is the case each one genuinely wins, stated by someone who only builds one of them: every Microsoft behaviour below was checked against Microsoft’s published documentation on 18 September 2026, and each claim links to the page it came from. Costs are deliberately absent — the money conversation belongs on what a Power Apps build actually costs, and quoting a bespoke agency’s numbers back at you would not be evidence of anything.

The question that separates them in one sentence

Does the requirement fit inside the envelope the platform already draws? That is the whole test. The envelope is specific and knowable: people sign in with a work account, the data is business records rather than a high-volume transactional stream, the interface is a screen or a form rather than a public web experience, and the integrations are to systems a connector already reaches. A requirement inside that envelope is cheaper, faster and safer to build low-code, and paying for bespoke code buys you a rebuild of things you already own. A requirement outside it cannot be tuned into fitting, and trying is the most expensive version of this decision.

Notice what the test is not. It is not complexity — a genuinely intricate approval and inspection process sits comfortably inside the envelope. It is not size of company. It is not whether your team “deserves real software”. It is the shape of the requirement against a boundary Microsoft publishes and does not move for individual customers.

What the platform supplies before anyone writes a line

The reason the two quotes differ so sharply is that half of a bespoke quote is work the platform has already done. Sign-in, multifactor and conditional access come from Microsoft Entra ID, already configured for your staff. Hosting, scaling, patching and backup are Microsoft’s problem. The mobile client exists and is in both app stores. Audit, data residency and tenant-level security policies are inherited rather than implemented. Connectors to SharePoint, Outlook, Teams and hundreds of other services are supplied rather than integrated.

None of those are line items on a Power Apps scope. Every one of them is a line item on a bespoke scope, and most of them are recurring line items rather than one-off ones — which is the part that tends to be under-discussed when the bespoke quote is presented as a single number. It is fair to say that a low-code build spends its budget on the parts of the problem that are actually yours: the data model, the screens, the logic, and who is allowed to see which rows.

The three limits that honestly rule the platform out

Any consultancy that sells low-code and cannot name its limits is selling you something. These are the three that end Power Apps projects, all of them documented by Microsoft, and all of them cheaper to discover now than in month four.

Delegation on large data sets

This is the one that surprises people, because it fails quietly rather than loudly. Power Apps tries to hand your query to the data source to run. When the query uses something the source cannot do, Microsoft’s guide to delegation in a canvas app (opens in new tab) states that Power Apps instead retrieves the first 500 records and processes them locally, a limit you may raise as far as 2,000. Its own worked example is blunt about the consequence: with a data source of a million records and a non-delegable filter, “only the first 500 records are scanned. If the record you want is record 501 or 500,001, Filter doesn’t find or return it.” An average over the same column averages 500 rows and presents the result as though it were the answer.

The honest reading is neither “Power Apps cannot handle large tables” nor “this never matters”. Delegable formulas over a delegable source — Dataverse, SQL Server, SharePoint — work against millions of rows perfectly well. But the ceiling is real, it constrains how the logic may be written, and the discipline of staying delegable is a skill rather than an accident. If the requirement is heavy aggregation across large volumes, bespoke code against a database has no equivalent constraint, and that is a legitimate reason to choose it. The data-layer half of this is worked through in Dataverse versus SharePoint lists for a Power Apps build.

The premium-connector licence requirement

Apps built on standard connectors run on rights already seeded into most Microsoft 365 business plans; Microsoft’s licensing FAQ confirms there is “no limit on the number of applications” customers can run that way. Step outside that set and the position changes in a single sentence from the same Power Platform licensing FAQ (opens in new tab): “A standalone Power Apps or Power Automate plan license is required to access all Premium, on-premises, and custom connectors.” SQL Server, the Azure services, Dynamics 365, the on-premises data gateway and any custom connector are all on the far side of that line.

Call it what it is: a cliff rather than a slope. An app touching your line-of-business SQL database, or reaching an on-premises system through a gateway, becomes an app that every person who opens it must be licensed for, every month, for as long as it exists. That is not a reason to avoid it — it is frequently still the cheaper answer — but it must be counted per head before the build, not discovered after it. The arithmetic, with Microsoft’s published rates, is on Power Apps licensing for small business. Bespoke software has no equivalent per-user platform fee, and for a large user population that is a genuine point in its favour.

No anonymous or public access

Power Apps is for people who sign in. Microsoft’s documentation on sharing a canvas app with your organization (opens in new tab) describes sharing with named users or with a security group in Microsoft Entra ID, and states plainly that “you can’t share an app with a distribution group in your organization or with a group outside your organization.” There is no anonymous mode and no public link. If the screen has to be opened by a customer, a member, an applicant or the public, this platform is the wrong one at any budget.

That does not automatically mean bespoke code. Microsoft’s answer for the outside audience is Power Pages, described in its introduction to Power Pages (opens in new tab) as a platform “for creating, hosting, and administering modern external-facing business websites” over the same Dataverse data. So a requirement with an external audience usually splits into a low-code internal app and a portal rather than a bespoke rewrite of both. Which side of that audience line your project falls on is the subject of Power Apps versus Power Pages.

The dimensions that decide it, side by side

The rows below are the ones that change the answer in a 20-to-500-person company. No single row settles it; a clear majority leaning one way usually does.

What the requirement sounds like out loud

Scoping conversations resolve faster when the requirement is stated as a sentence rather than as a preference between technologies. These are the sentences that recur, and what each one implies.

Who keeps it running in year two

Buyers weigh the build and under-weigh the decade that follows, and this is where the two options diverge most. The fear is usually stated as a person: the developer who wrote it has left, nobody else understands it, and every change now costs a discovery exercise. That risk is real on both sides, but it is not the same size.

On a bespoke build, the surface you inherit is the whole stack. Source code in a language and framework someone must still know. Dependencies that reach end of life on a schedule nobody controls. A hosting environment that needs patching whether or not the app changed. A deployment pipeline that stops working when a credential expires. None of that is a criticism of bespoke software — it is simply the cost of owning something outright, and it lands every year, funded or not.

On a low-code build, most of that surface belongs to Microsoft, and what remains is configuration: a column added to a table, a view, a security role, a screen adjusted. Solutions are the mechanism for moving all of it safely — Microsoft’s overview of solutions in Power Apps (opens in new tab) describes them as the way to “transport apps and components from one environment to another”, exportable to a file, importable elsewhere, and now syncable to a Git repository. That is an application lifecycle a small IT team can actually operate.

Two honest caveats. A canvas app is still a program: its logic lives in Power Fx spread across screens, and the person who wrote it understands it best — which is one of several reasons the shape of the build matters, as set out in canvas apps versus model-driven apps. And low-code makes it easy to build something nobody designed, which ages exactly as badly as bad code. The platform removes a category of maintenance; it does not remove the need for engineering judgement.

The exit path if the app outgrows the platform

Ask any agency quoting bespoke work what happens when you outgrow low-code, and the implied answer is “you start again”. That is only true if the data was never modelled properly, which is a good reason to model it properly.

When the records live in Dataverse, the exit is incremental rather than total. Microsoft’s documentation for the Dataverse Web API (opens in new tab) states that it “implements the OData (Open Data Protocol), version 4.0, an OASIS standard”, usable “across a wide variety of programming languages, platforms, and devices” — and that because it is built on open standards, you can compose requests directly or use third-party libraries for whatever language you like. In practice that means a bespoke component can read and write the same tables the app uses, so a screen or a whole module can be replaced with custom code while everything else keeps running. The tables, relationships and security model survive the transition.

The sequencing matters more than the technology. A low-code first version settles the requirement while it is still cheap to be wrong, produces a clean data model as a by-product, and leaves a documented exit. A bespoke first version settles the requirement the expensive way. Where the platform genuinely will not stretch, the pattern we use most is a split rather than a migration: the platform keeps what it is good at — identity, records, screens, mobile — and bespoke code takes only the part that needed it.

How we scope this before anyone builds anything

On a scoped engagement this decision is made in writing before a designer or an editor is opened: the envelope test against the actual requirement, the delegation profile of the data, a per-head licence position for every premium connector in scope, who opens the screen and whether any of them are outside your organization, and who will hold the thing in year two. If that assessment says bespoke code, we say so — we would rather lose a build than sell one that hits a documented ceiling in month four.

Where the assessment cannot be settled on paper — usually because the data is messier than anyone admits, or because the argument inside the business is about confidence rather than capability — the cheaper next step is a time-boxed Power Apps proof of concept rather than either quote. One process, one working app your own people use, and a written account of what production would take, before a bespoke contract is signed.

When it says the platform fits, the work runs as fixed-fee Power Apps consulting: senior US-based engineers, typically two to four weeks, 30 days of hypercare after go-live, everything built in your own tenant and yours to keep. See how the fixed-fee process works, or send us the requirement and the quote you are weighing it against, and we will tell you which of the two it actually needs.