Power Apps vs Custom React Frontend for ERP: An Honest Comparison
We get asked this constantly. The honest answer is: it depends on what you are building. Here is a practical, no-nonsense breakdown of when each approach works, where each fails, and how to decide for your business.
If you run an ERP like Dynamics 365 Business Central, Sage 200, or OrderWise, the question of how to build interfaces on top of it comes up sooner or later. You need a customer portal. A sales dashboard. A warehouse app. A supplier self-service screen. And the first fork in the road is almost always the same: Power Apps or a custom-built React frontend?
Both camps have vocal advocates. Microsoft’s ecosystem pushes Power Apps hard — it is included in many E5 licences, tightly coupled to Dataverse, and positioned as the default low-code tool for the Microsoft stack. The React / Next.js ecosystem, by contrast, offers unbounded flexibility but requires proper engineering resource.
This article is a practical comparison. We build both kinds of system, so we have no axe to grind. What follows is what we have actually observed across dozens of ERP integration projects for UK manufacturing and distribution SMEs.
What Power Apps is genuinely good at
Let us start with the honest positives. Power Apps is not useless — it is genuinely effective within a specific band of use cases.
Simple internal dashboards (5–20 users)
A department-level dashboard that surfaces key data from Business Central or Dataverse — open purchase orders, pending approvals, overdue deliveries — can be assembled in Power Apps in a matter of days. The canvas app model lets you drag and drop controls, bind them to data sources, and publish without a CI/CD pipeline. If the data model fits neatly into Dataverse virtual tables or the BC connector, and the user count stays below 20–30 concurrent sessions, performance is acceptable and development cost is low.
Basic approval workflows
Purchase order approvals, holiday requests, expense claim sign-offs — these are textbook Power Apps and Power Automate scenarios. A simple form, a few conditional flows, email notifications, and you have a working approval system in a week. The Power Platform was designed for exactly this category of problem, and it shows. Microsoft’s pre-built templates for PO approval and leave management are genuinely useful starting points.
Connecting to BC data via Dataverse virtual tables
The Dynamics 365 Business Central connector for Power Apps has improved significantly. With virtual tables in Dataverse, you can surface BC entities (Customers, Items, Sales Orders) directly in Power Apps without duplicating data. For read-heavy, low-volume scenarios — look up a customer record, check an item price, view an order status — this works reliably.
Rapid prototyping
If you need a clickable mock-up to validate a concept with stakeholders before committing to a full build, Power Apps is hard to beat. A functional prototype that connects to real data can be produced in two to three days. That speed has genuine value when you are trying to get buy-in from budget holders.
Where Power Apps hits a hard ceiling
The problems start when you push beyond the scenarios above. And in our experience, most ERP-connected applications push beyond them very quickly.
Complex business logic
Power Apps formula language (Power Fx) is deliberately limited. It is designed for spreadsheet-level logic — sums, lookups, conditionals — not the kind of multi-step business rules that ERP implementations routinely require. Consider a bill of materials explosion: you need to recursively resolve component hierarchies, apply scrap factors by level, aggregate costs with currency conversion, and validate against availability. This is a page of TypeScript in a React app and a non-starter in Power Apps. The same applies to multi-tier pricing (customer group + product group + volume tier + promotion), batch traceability with forward and backward lot tracing, landed cost calculations, and pretty much any logic that involves a loop with accumulation.
Workarounds exist — you can push logic into Power Automate flows, custom connectors, or Azure Functions — but each workaround introduces a new hop, a new failure mode, and a new delay. What starts as “low-code” becomes “some-code-scattered-across-four-tools.”
High-volume transactional interfaces
Power Apps struggles with data density. The grid control is limited, virtual scrolling has known performance ceilings, and bulk operations (select 50 rows, update a field, commit) frequently time out or hit delegation limits. For interfaces where a warehouse operative needs to process 200+ order lines per hour, or a sales administrator needs to work through a queue of back-orders in a single session, Power Apps introduces friction at every step.
We have benchmarked Power Apps grid rendering at 800–1,200 rows before noticeable input lag sets in. A React ag-Grid or MUI X Data Grid handles 50,000+ rows with server-side sorting, filtering, and inline editing without breaking a sweat.
Customer-facing portals with complex auth
Power Apps portals (now Power Pages) are a different product from canvas or model-driven apps, and they come with their own constraints. Authentication options are limited to Azure AD B2C, which adds cost and configuration overhead. The rendering model is less mature than a standard React SPA. Customisation of the UI beyond the available templates requires Liquid templates or JavaScript injection — at which point you are effectively writing code anyway, but in a constrained environment with worse tooling.
For a B2B customer portal serving 50–500 external users, Power Pages can work. Beyond that — or if you need fine-grained role hierarchies, social login, MFA with custom policies, or embedding in a broader web application — you will hit limits.
Performance at scale
Microsoft publishes a “known limitations” list for Power Apps. It includes a 2 MB response limit per data source call, a 600-object delegation limit for SharePoint (500 for Dataverse when using the non-premium connector), a 100-millisecond-per-control rendering target that degrades beyond 30–50 controls, and a browser tab memory ceiling of roughly 200–300 MB before the app becomes noticeably sluggish.
These are not theoretical edge cases. We have seen Power Apps portals crash browser tabs on machines with 8 GB of RAM when the data set exceeded 5,000 rows across three connected tables. For an ERP context where users routinely need to see months of transactional data, this is a genuine operational risk.
| Constraint | Power Apps Limit | Typical ERP Requirement |
|---|---|---|
| Data row delegation | 500–600 rows | 10,000+ rows |
| Response payload size | 2 MB per call | 5–10 MB (with line items) |
| Concurrent users (canvas app) | 20–30 before degradation | 50–200+ for customer portals |
| Complex logic loops | Not supported in Power Fx | BOM explosion, batch trace |
| Custom branding | Limited theme editor | Full brand compliance |
What a custom React frontend is good at
React (and modern frameworks built on it, particularly Next.js) takes the opposite approach: you have full control, but you must earn it through proper engineering.
Production-grade customer-facing applications
A React application served via Next.js gives you server-side rendering for SEO, static generation for marketing pages, API routes for backend logic, and a fully customisable React component tree for the UI. Authentication can integrate with Azure AD, Auth0, Cognito, or a custom OAuth provider. The same codebase can serve internal staff and external customers, with role-based rendering deciding which features each user sees.
We have built customer portals handling 500+ daily active users, processing 15,000+ order line lookups per day, with sub-second page load times and no performance degradation. That is not a boast about our engineering — it is the baseline expectation for a properly built React application.
Complex data entry and manipulation workflows
React’s component model and state management (React Query, Zustand, Redux) handle multi-step workflows naturally. A sales order entry screen with inline item search, real-time price calculation, availability checking, discount application, and shipping method selection is a complex state machine. React makes it tractable by keeping UI state, server state, and form state in separate, well-defined layers.
The maturity of the React ecosystem means you are never more than an npm install away from a battle-tested solution for: data grids (ag-Grid, MUI X), forms (React Hook Form, Formik), date handling (date-fns), PDF generation (react-pdf), charts (Recharts, Nivo), drag-and-drop (dnd-kit), and accessibility (Radix, Reach UI).
High-performance real-time dashboards
When your managing director wants to see live sales figures, open order value, and margin by division on a single screen, with data refreshed every 30 seconds from Business Central — React handles this trivially. WebSocket or polling-based data fetching, cached with React Query, rendered with a charting library, composed into a custom dashboard layout. The only limit is the API response time of your ERP.
Full control over UX, accessibility, and branding
Power Apps themes give you a colour picker and a font selector. React gives you a design system. Every pixel, every interaction, every animation, every screen reader label, every keyboard navigation path — you own it all. For organisations that take their digital brand seriously (or have WCAG compliance obligations), this is not a nice-to-have. It is the deciding factor.
Architectural separation — the adapter pattern
This is the structural advantage that matters most for ERP projects. A React frontend built on an adapter layer abstracts the underlying ERP entirely. Your React components talk to an API layer that translates between your application’s data model and whatever your ERP exposes. If you migrate from Business Central to Sage 200 in three years, you replace the adapter — not the frontend. In Power Apps, your app is tightly coupled to Dataverse and the BC connector. Switching ERP means rebuilding the app.
Decision framework
Here is how we think about which approach fits which use case:
| Use case | Power Apps | React / Next.js |
|---|---|---|
| Internal approval workflow (<20 users) | Recommended | Overkill |
| Department KPI dashboard (read-only, <1,000 rows) | Works well | Also works |
| High-volume order entry screen | Not suitable | Recommended |
| Customer-facing B2B portal (50+ users) | Struggles | Recommended |
| Complex business logic (BOM, pricing, traceability) | Not suitable | Recommended |
| Mobile-first warehouse or field app | Limited | Recommended |
| Rapid prototype / proof of concept | Best fit | Too slow |
| WCAG / accessibility-critical interface | Limited | Full control |
| Multi-ERP abstraction / future migration | Tied to Dataverse | Adapter pattern |
Cost comparison
Cost is where the conversation gets nuanced, because the two approaches have fundamentally different cost structures.
Power Apps
- Power Apps per-user plan: ~£7/user/month
- Power Pages: ~£200–1,000/month (external users)
- Premium Dataverse capacity: ~£40/month per GB
- Power Automate per-flow plan: ~£15/month per flow
- Development: £5,000–30,000 per app (partner)
- Ongoing: annual licensing escalates with user growth
Custom React / Next.js
- One-off build cost: £40,000–120,000 (complete portal)
- Hosting: ~£50–300/month (Vercel / AWS)
- No per-user licence cost
- Ongoing maintenance: ~15–20% of build cost per year
- Amortised over 3 years: typically lower TCO beyond 50 users
- *Equivalent based on 3-year amortisation at 80 users
The crossover point is usually between 40 and 80 users, depending on the complexity of the application. Below that, Power Apps licensing is cheaper. Above it, the per-user licence costs of Power Apps accumulate faster than the amortised build cost of a custom React application.
But there is a hidden factor: the cost of the workarounds. If your Power Apps application needs a custom connector to handle complex logic, that adds development and maintenance cost. If your React application is well-architected from the start with an adapter layer, maintenance is lower because the codebase is standard JavaScript, not a platform-specific low-code DSL. The debugging tooling (React DevTools, browser network tab, VS Code debugger) is substantially more mature than the Power Apps Studio and Monitor tools.
The middle ground: Power Apps for internal tools + React for customer-facing
This hybrid approach is more common than you might expect, and for good reason. Many of the organisations we work with run Power Apps for their internal staff portals and a custom React application for their customer-facing portal — both connected to the same Business Central instance.
It works because the two categories have fundamentally different requirements:
Internal staff tools typically need simple forms, approval routing, read-only dashboards, and access to Dataverse-connected data. User counts are low (20–50), authentication uses existing Azure AD, and performance requirements are relaxed. Power Apps handles this well, and the per-user licence cost is baked into your existing Microsoft agreement.
Customer-facing portals need complex workflows, high concurrency, fine-grained access control, full brand customisation, responsive mobile design, and integration with third-party services. This is where React earns its keep.
The architecture looks like this:
(ERP backend) → BC REST API
v2.0 / OData → Adapter Layer
(TypeScript API) → React Portal
(Customers)
The adapter layer sits between both frontends and the ERP. The Power Apps staff app talks to Dataverse (which syncs from BC via virtual tables). The React customer portal talks to the adapter layer (which wraps the BC REST API). Both read and write the same ERP data, but each through the most appropriate channel.
This is not a “best of both worlds” marketing answer. It is a pragmatic position: use the right tool for each audience, and build your integration layer so that neither frontend cares which ERP sits behind it.
Architecture comparison: direct coupling vs adapter pattern
The architectural difference between the two approaches is worth making explicit, because it drives most of the long-term cost and flexibility outcomes.
Power Apps architecture (tightly coupled)
Pros: Fast to build for simple cases, no separate backend to maintain, uses existing Microsoft licensing.
Cons: App logic and data access are inseparable, switching ERP means rebuilding all data bindings, performance limited by Dataverse delegation, no offline capability, testing is manual and platform-specific.
React adapter architecture (decoupled)
Pros: ERP-agnostic frontend, full test coverage, mature CI/CD pipelines, TypeScript throughout, performance unlimited by platform constraints, portable to any hosting.
Cons: Higher upfront build cost, requires senior engineering resource, you own the infrastructure (though managed services minimise this).
Frequently Asked Questions
Can Power Apps handle 200+ concurrent users?
Does Power Apps work offline?
What about Power Pages (formerly Power Apps portals)?
How long does a custom React portal take to build?
Can we use Power Automate with a React frontend?
Do we need to be a software company to maintain a React app?
Which is better for Dynamics 365 Business Central specifically?
What is the total cost of ownership over 5 years?
Not sure which approach fits your project?
We run 3–5 day discovery sprints. We audit your ERP API, map your user workflows, and produce a concrete recommendation — with a fixed-price build proposal if you decide to proceed. Whatever the outcome, you walk away with a clear picture of what your interface should look like and how to build it.
Book a Discovery Call