Power Platform stops being the right tool in four situations, and I run into all four in real client work. High-volume transactional workloads that hit Dataverse's throttling limits. Public apps built for anonymous visitors, which need a different product with its own pricing model. Licence costs that outgrow the time saved once enough staff need access. And jobs an off-the-shelf product already does. I build on this platform for a living, and I still talk people out of it for all four, because getting that call right matters more than the build fee.
The migration-specific version of this list is on the Power Platform migration hub.
One specific version of the wrong-tool question comes up so often it has its own page: Business Central, or a Power App on top of Xero.
When the answer is "a proper database", the small-firm version of that choice is Dataverse or Azure SQL.
High-volume transactional workloads, and why they hurt here
Dataverse is the database sitting under most Power Platform apps, and it isn't built to be a high-throughput system of record. It protects itself with service protection limits: as at July 2026, Dataverse caps a single user identity at roughly 6,000 requests inside a rolling 5-minute window, with a combined execution time ceiling running alongside it. Cross either one and Dataverse returns a 429 "Too Many Requests" response and tells you, via a Retry-After header, how long to wait before trying again. On top of that, every licensed user or service account carries its own daily API request entitlement, and it's shared across every app and flow running under that identity.
This stays invisible in a normal internal app. A team of fifteen people filling in forms and running approvals will never get near it. It shows up the moment you point a flow or a service account at something with real transaction volume: point-of-sale data, sensor or IoT telemetry, financial postings arriving from another system, anything moving hundreds or thousands of records a minute. The platform starts throttling exactly the workload it was never designed for, and no amount of premium licensing removes that ceiling, it just changes the number.
If a job looks like "ingest a firehose of records reliably", the right shape is a proper database and a purpose-built API doing the ingestion, with Power Platform on top for the human workflow around it.
Public facing apps for anonymous users
Canvas apps and model-driven apps both need a licensed identity behind every user, which rules them out for anything the public browses without logging in. The Power Platform product built for that job is Power Pages, and it charges by visitor rather than by seat. As at July 2026, Power Pages is sold in visitor capacity tiers, in the region of USD 200 a month for a block of 100 authenticated users and USD 75 a month for a block of 500 anonymous users, with pay-as-you-go rates around USD 4 per authenticated visitor and USD 0.30 per anonymous visitor on top. Check the current numbers before budgeting, Microsoft moves them.
That model works fine for a bounded external portal, a supplier extranet, a client self-service page, where you roughly know how many people will show up in a month. It's an odd fit for anything meant to be genuinely public. A marketing site, a consumer-facing tool, a page you want traffic to find: the better it performs, the bigger the bill, which is a strange incentive to build into a product you want to succeed. Power Pages' page-and-template composition model also fits structured portal content well, and stretches for the freeform design most public products want anyway.
For genuinely public, anonymous-facing work, I build a normal website or web app and host it. Power Pages is the right buy for the bounded portal job it was designed for.
When the licensing maths beats the productivity gain
Power Apps Premium is licensed per user, per month. As at July 2026, list price runs around USD 20 per user per month, dropping to roughly USD 12 per user at enterprise volume (2,000 or more licences). Before you assume everyone needs one of those seats, check the two narrower routes. Pay-as-you-go bills about USD 10 per active user per app per month and only charges for the people who open the app that month, which is exactly the occasional-user case. The old Per App plan at USD 5 per user per app came off general sale on 2 January 2026, but Enterprise Agreement customers can keep renewing it and Microsoft restored CSP reseller access in April 2026, so if you buy through a partner, as most NZ businesses do, ask your reseller before you rule it out. I've covered the state of that plan in what happened to the Power Apps Per App plan.
Run the maths on a mid-sized team. Forty staff needing occasional access to one internal tool, on pay-as-you-go at USD 10 per active user, is roughly USD 400 in a month where all forty open it, and less in the months they don't. Put the same forty on full premium seats and it's USD 800 a month, close to USD 9,600 a year, whether someone opens the app daily or once a month. A one-time custom build carries a bigger cost upfront and no per-seat bill after that, just ordinary hosting and maintenance. The more people who need bare access to one thing, the sooner that flat cost overtakes the forever-fee, and the licensing route you land on decides how soon.
This is the same arithmetic I use on the trades side of my own work, laid out in what a Power Platform build costs to run. Price both paths before committing to either, which is exactly what a Workflow Review is for.
When an off-the-shelf product already does the job
This is the one I'm most consistent about, because I say it about my own market too. If a purpose-built product already handles the job well, buy it. Don't have me build what Xero already does for accounting, what Tradify, Fergus or ServiceM8 already do for trade job management, what HubSpot or Pipedrive already do for a sales pipeline, what Deputy already does for staff rostering, what PayHero, Smartly or Employment Hero already do for payroll, or what Shopify already does for an online store. These products are cheaper than a custom build, someone else keeps them patched and supported, and they've already fixed problems you haven't hit yet. The same test applies inside Microsoft's own stack: before anyone builds an approval flow, check whether the Approvals app already in Teams covers the process.
I wrote this out for tradies specifically in the NZ job management software comparison, and the test there holds everywhere: if a product fits at least 90% of how you work, buy it. Power Platform, or any custom build, is for the last 10% those products don't reach.
What I'd build instead, in each case
| Where Power Platform stops | What I'd build or buy instead |
|---|---|
| High-volume transaction ingestion | A proper database (Azure SQL or Postgres) behind a purpose-built API, with Power Platform layered on top for the human review and approval steps only |
| A genuinely public, anonymous-facing app | A normal website or web app, hosted and designed for public access, with no per-visitor metering |
| Licence cost outgrowing the time saved | A one-time custom build once headcount crosses the point where the per-seat fee beats a flat build, priced before deciding |
| A job an off-the-shelf product already does | Buy it: Xero, Tradify, Fergus, ServiceM8, HubSpot, Pipedrive, PayHero, Smartly or Shopify, whichever actually fits |
Most of what I build for clients still runs on Power Platform, because most business problems are internal workflow problems on data that moves at a human pace, and that's what the platform is good at. The four cases above are the edges. Knowing where they are is most of the job, and it's worth more than being told yes to everything, which is why how I structure a build starts with a paid Workflow Review rather than a quote off the back of one email.
Common questions
Can Power Platform handle high-volume transaction processing?
Not well. Dataverse, the database behind most Power Platform apps, protects itself with service protection limits: a single identity is capped at roughly 6,000 requests inside a rolling 5-minute window, plus a combined execution time ceiling, and every licence carries its own daily API request cap on top. Cross either one and Dataverse returns a 429 error and tells you how long to wait. For genuine high-volume ingestion, a proper database and API built for that job is the better fit, with Power Platform layered on top for the human workflow around it.
Can I build a public website with Power Apps for anonymous visitors?
Not with a standard canvas or model-driven app. Those need a licensed user behind every session. The Power Platform product built for anonymous visitors is Power Pages, and it's priced per visitor per month rather than per seat, which is a workable model for a bounded external portal and an odd one for anything you want to go fully public and grow.
When does Power Platform cost more than it saves?
Power Apps Premium is licensed per user, per month, at about USD 20. Two cheaper routes exist for people who only touch one app. Pay-as-you-go bills about USD 10 per active user per app per month, so it charges for the people who open the app that month and nobody else. The Per App plan came off general sale on 2 January 2026, but Enterprise Agreement customers can keep renewing it and Microsoft restored CSP reseller access in April 2026, so if you buy through a partner it is worth asking. Once a large enough headcount needs full premium seats for a single internal tool, that recurring fee can overtake the cost of a one-off custom build with no ongoing licence, and the maths is worth running before committing to either path.
Not sure which side of the line your job falls on?
Free 30-minute call. Tell me the problem and I'll say whether Power Platform fits it or whether you need something else.