Every team that runs Dynamics 365 eventually faces the same question: should we build our external portal on Microsoft Power Pages, or build it custom on React / Next.js? The Power Pages marketing page says one thing, the React hiring market says another, and the actual right answer — as usual — depends on a half-dozen factors most blog posts gloss over.
This post is the decision framework we give our customers. By the end, you'll know which category your project falls into, what each path actually costs, and why the hybrid approach (Power Pages infrastructure + a modern builder like PortalForge on top) has become the default for most enterprise teams in 2026.
What Power Pages is great at
Let's be specific about what Power Pages actually does well, because a lot of dismissive commentary misses the point.
- Dataverse-native data access. Zero ORM work, zero API gateway. Your portal reads and writes to the same tables your Dynamics users do, with the same security model, automatically.
- Authentication out of the box. Local accounts, Microsoft, Google, LinkedIn, Facebook, Azure AD B2C, and any SAML/OIDC provider — all configurable from the Power Pages admin UI.
- Web-role-based security. Already how your Dynamics team thinks about access. No duplicate permission model to maintain.
- Hosting included. No Vercel bill, no Kubernetes cluster, no security hardening review. Microsoft runs the edge and the origin.
- Forms engine with field-level validation. Standard forms and basic forms (the Liquid-era names) still work well for simple intake flows.
Where Power Pages hurts
The weaknesses are real and well-documented. They've improved in 2026 versus the Dynamics Portals days, but the underlying architecture still shows.
- Liquid templates are a 2010s authoring model. String concatenation, no component system, no TypeScript, no hot reload. Developer productivity is meaningfully lower than modern React.
- Design Studio is limited. The visual editor covers basic layouts. Real portals end up in the code view editing Liquid files. That's fine for Microsoft's examples; it's not fine for the kind of portal your customers actually want.
- Iteration is slow. Historic reputation: 15-minute cache propagation. Fixed in 2026, but deploy cycle is still slower than a Vite dev server with HMR.
- Styling is harder than it should be. Bootstrap is still the default. Tailwind works but isn't wired in out of the box. Every theme customization requires fighting the theme CSS.
What custom-built portals do better
A bespoke React/Next.js portal solves every Power Pages weakness by construction. You get modern tooling, a real component library, unlimited design flexibility, and the hiring pool is massive. For consumer-facing portals where brand and UX are the product — think D2C commerce, community forums, public product catalogs — custom wins hands-down.
Where custom portals hurt
The costs the React-is-obvious crowd consistently under-estimate:
- You're now running a second app with its own auth, authorization, and data-access layer. Every Dataverse permission rule has to be mirrored in the custom app's middleware, or your portal becomes a security hole.
- Infrastructure and compliance. SOC 2, HIPAA, GDPR — all of this is handled by Microsoft for Power Pages. On a custom portal, you own it.
- Ongoing maintenance. Dependencies, patching, node runtime upgrades, CI/CD, on-call rotation. This is 20–30% of the cost of a full-time engineer indefinitely.
- Dataverse plumbing is the hard part. OData authentication, MSAL token refresh, lookup handling, polymorphic customers, picklist codes vs labels. The stuff Power Pages gives you free — rebuilding it eats weeks.
The hybrid that most teams end up at
The pattern we see winning in 2026: keep the Power Pages infrastructure, swap out the authoring layer. You publish to Power Pages (keeping the auth, Dataverse access, hosting, and compliance story) but you build on a modern visual tooling layer that generates the portal.
This is exactly what PortalForge does. You design on a React + Tailwind canvas, bind components to Dataverse tables, configure scope-aware permissions visually, and publish — the output is a React SPA plus a minimal Liquid host template that deploys to your Power Pages site as a code site.
You get the best of both worlds: Microsoft's security, hosting, and Dataverse story, plus a modern authoring experience and no infrastructure overhead.
A simple decision matrix
- Use Power Pages (native) if: you have a simple portal, you already have Power Pages licensing budget, and you have a team comfortable with Liquid.
- Use custom React/Next.js if: your portal IS the product (consumer-facing brand site, community platform, e-commerce) AND you have engineering capacity to support it indefinitely.
- Use the hybrid (Power Pages + visual builder) if: you're on Dynamics 365 already, you want a modern UX without the custom-app overhead, and you'd rather ship in weeks than quarters.
If the third bullet sounds like you, start with the template library or read the end-to-end build guide.