Power Pages vs a Custom Customer Portal: Costs for External B2B Users

Power Pages can be the better-value customer portal when your data, permissions and delivery team already fit the Microsoft platform. A custom portal becomes worth investigating when site overlap, integration complexity or distinctive workflows outweigh that advantage. Compare the same customer journey over an operating period, not a low-code subscription against a developer's initial build estimate.

For external B2B users, the first question is unusually concrete: how many people use each website in each calendar month? The size of your customer database is not that number. Neither is the number of customer companies, employees or login sessions.

This comparison uses one explicitly hypothetical dealer-service portal, two 36-month budget scenarios and a seasonal licensing example. Product documentation was reviewed on 29 September 2026. The effort estimates are illustrative planning assumptions, not measured delivery results, Microsoft quotes or Wavect offers. This is a Power Pages customer-portal decision, not a generic Power Apps-versus-custom comparison.

Compare the same dealer portal, not two different products

Our example lets an invited dealer employee see their company's orders and invoice documents, raise a service request with attachments, and submit a repeat-order request for validation. A dealer administrator manages approved colleagues. An employee responsible for several dealer accounts must be explicitly authorized for each. The ERP remains authoritative for prices, order acceptance and financial documents.

Both implementations must support company-level data isolation, accessible desktop and mobile journeys, audit evidence, an exception queue, monitored integrations and a tested release process. A request is not displayed as an accepted ERP order until that outcome has been confirmed. We exclude embedded analytics, AI assistants and payment collection from both base scenarios.

On the Power Pages path, configure the portal around Dataverse and approved integration surfaces. On the custom path, build the frontend and application service, use a managed identity provider and store portal state in a database selected for the workload. Both can use middleware. Neither path gets a free ERP integration or a free security review.

Keep screen count, business rules, supported languages, document volume, service hours, data-retention requirements and recovery objectives identical within each comparison. Removing dealer administration or reconciliation from the cheaper proposal invalidates the comparison. Our broader custom-versus-off-the-shelf decision guide covers procurement principles; the distinct issue here is external-user portal economics.

What does Power Pages cost for authenticated B2B users?

Microsoft's US pricing page lists USD 200 per month for a 100-user authenticated capacity pack, paid yearly, and USD 75 for a 500-user anonymous pack. Authenticated capacity covers a person using one website during a calendar month. Included subscription storage accrues to the tenant; it is not an unlimited, separate database allowance for every site. See Microsoft's Power Pages pricing and capacity footnotes.

For Austrian buyers, the local pricing page displays EUR 173.30 per 100 authenticated users/site/month, billed yearly, excluding VAT, and EUR 65.00 for a 500-user anonymous pack. These are local published prices, not a currency conversion of our USD scenarios. Confirm the applicable offer, purchase channel and commitment at checkout: Microsoft's Austrian pricing.

Count user-site relationships, then allocate capacity

A registered contact who never signs in that month is not an active authenticated user. Repeat logins to the same site do not multiply the count. The same person using another site creates another user-site count.

Do not round every website up to a separate 100-user purchase. Packs are bought as capacity and allocated to environments. Microsoft's FAQ permits splitting an authenticated pack across environments, with a minimum allocation of 25 per environment. It also documents volume tiers starting at 100 packs and 1,000 packs. Unused monthly capacity does not roll forward. See the Power Pages licensing FAQ.

Use the following as planning arithmetic, not an automated licensing determination:

Monthly demand = sum of distinct active authenticated users for each website.

Purchased capacity = enough whole packs to cover approved environment allocations, including allocation minimums and headroom.

These examples assume no spare capacity, no qualifying existing user entitlements and sufficient allocations. The first three can be modeled within one environment; the last illustrates allocation, not tenant-wide single counting. All are below the documented volume-tier thresholds. For larger purchases, obtain the applicable tier or agreement rather than extrapolating USD 200 forever.

Separate websites are not the same as separate pages, languages or dealer roles. Record the actual website and environment design. Consolidation can reduce overlapping usage, but shared navigation is not justification for weakening company isolation or collapsing genuinely separate operations.

Pay-as-you-go is a different calculation

Microsoft's meter documentation lists USD 4 per active authenticated user/website/month and USD 0.30 for anonymous usage, with the Power Pages meter section currently labeled preview. It also states that prepaid portal capacity assigned to a pay-as-you-go environment is ignored rather than consumed first. Verify availability and contract terms before choosing this route: Power Platform pay-as-you-go meters.

A standard sign-in page alone does not mean a private portal needs a general anonymous capacity budget. A public knowledge base or product-document section is different. Inventory actual anonymous journeys and follow the counting rules in the licensing FAQ, instead of assuming either all public traffic is free or every authentication page is billable.

Identity, permissions and data access change the comparison

Authentication is not dealer authorization

Power Pages associates signed-in users with Dataverse contact records and supports external identity providers, including OpenID Connect and SAML options. This does not require giving every external customer a normal internal employee account. Microsoft's authentication overview describes the supported identity model.

Budget identity separately from portal access. Microsoft Entra External ID has its own monthly-active-user billing model and optional add-ons; it is not the Power Pages user-site meter. A custom portal using that identity service still needs the corresponding cost and tenant design: External ID pricing and billing.

The difficult business rule is usually not “can this person log in?” It is “which dealer accounts, invoices and actions does this person control?” Power Pages table permissions support contact- and account-related access linked to web roles. Global access is broader. Microsoft's table-permission documentation is the implementation reference, not proof that your chosen relationships isolate customers correctly.

Our acceptance requirement is identical on both paths: dealer A cannot read dealer B's invoice by changing a URL, record identifier, attachment reference or request body. Test people with several company relationships, delegated administrators, revoked access and conflicting roles. Do not use hidden buttons or a browser-supplied company ID as the authorization boundary.

Choose how ERP data reaches the portal

Power Pages can use virtual tables to represent external records without copying the underlying business data into physical Dataverse rows. Microsoft documents supported providers, including Finance and Operations, Business Central and custom providers: virtual tables with Power Pages. This is a real option, not evidence that every ERP object or business operation is supported.

Provider constraints matter. Microsoft's documentation for virtual-connector-provider tables lists limitations affecting queries, attachments and auditing, including a 1,000-record query-return limit and unavailable Dataverse audit functionality for virtual tables. Check the actual provider rather than applying those limits to all conceivable middleware: virtual-table limitations.

For this dealer portal, assess three patterns: synchronize a bounded read model into Dataverse; use a supported virtual-table provider; or send commands through a dedicated integration service. For each, price data mapping, account relationships, document retrieval, reconciliation and failure recovery. A displayed ERP table is not automatically an authorized “release order” operation.

The Power Pages portals Web API is not a general ERP integration backend. Microsoft positions it for experiences inside portal pages and explicitly does not support using it to integrate other Power Pages sites. Server-to-server work needs an appropriate supported integration surface: portals Web API scope.

Power Automate can be part of the solution, but its cost is not implicitly zero. The documented Power Pages cloud-flow integration requires a Power Automate license and recommends a Process license for production. Flow access is associated with web roles, and target-environment registration matters during deployment: cloud-flow integration requirements.

Custom development removes the Power Pages capacity line only when the design genuinely does not use Power Pages. It does not remove ERP access charges, identity costs or underlying data-platform entitlements. Ask the relevant licensing owners to confirm external access, integration identities and permitted operations under both architectures. Unresolved quotes remain unresolved costs in our model.

Two illustrative 36-month operating budgets

All following amounts are USD planning inputs, excluding taxes, financing and inflation. We use an assumed blended labor cost of USD 100/hour, unchanged in both approaches. That is not a published Wavect rate. Implementation includes design, configuration or coding, integration, identity setup, initial testing and deployment. Discovery and operational work are separate.

Monthly service allowances include the selected integration runtime, incremental storage, identity and messaging, observability, backup services and applicable administration or flow licenses. On Power Pages they are additional services, not a second charge for its included hosting. On custom they also include application and database hosting. Replace these allowances with an itemized bill of materials before approval.

Maintenance is recurring labor for defect diagnosis, permission reviews, connector changes, dependency or configuration upkeep, regression tests and recovery exercises. Planned changes are separate feature work. Exit readiness covers documentation and a sample data export, not an assumed full migration.

Scenario A: one site and 250 active external users

The same 250 people use the portal each month. Three entry-tier packs cost 3 × USD 200 × 36 = USD 21,600. Our Power Pages estimate assumes an existing Dataverse-capable team and a supported ERP integration path; custom assumes a reusable web foundation, not starting every component from nothing.

Power Pages is USD 9,800 lower before the unresolved quote items in this example. It remains a credible choice. Building custom software just to avoid USD 600/month of portal capacity would not repay the extra implementation and operating effort assumed here.

The margin is sensitive: three additional maintenance hours per month cost USD 10,800 over 36 months at our assumed rate, enough to reverse it. Treat the effort and support model as seriously as the license price.

Scenario B: 600 people, each active on three websites

Keep the dealer-service capabilities, but require three separately operated brand portals. Every person uses all three each month: 600 people become 1,800 monthly user-site counts, not 600 and not 1,800 different people. Eighteen packs cost 18 × USD 200 × 36 = USD 129,600.

Both proposals now include more deployment, identity, permission and support work. The custom path must also serve the three brands, whether through a controlled shared application or separate deployments. We do not give custom a simpler business scope.

Custom is USD 92,400 lower before quote items under these assumptions. This is a reason to investigate, not a universal break-even threshold. Lower overlap, a different agreement, simpler Power Pages delivery or more expensive custom support can change the result.

As a sensitivity check, if each of the 600 people uses only one of the three sites, aggregate demand is 600. Six packs instead of 18 reduce the capacity line by USD 86,400 across 36 months. Holding every other input fixed purely for comparison, the Power Pages subtotal becomes USD 146,800, only USD 6,000 above custom. User journeys can matter more than the headline audience count.

Full 36-month cost = modeled subtotal + confirmed additional quote items.

Until Q_PP and Q_Custom are known, neither subtotal is an approved all-in budget. The accompanying editable model keeps the full total unknown rather than silently substituting zero. A confirmed zero is a valid input; a missing quote is not.

Download the editable portal cost-model inputs. The repository calculator reproduces both budgets, allocation examples, sensitivities and the seasonal comparison; edit assumptions and confirmed quote items before treating them as your budget.

Seasonal usage can favor a different Power Pages plan

Consider one site with 1,200 authenticated users in one month and 50 in each of the other eleven. That is 1,750 user-months per year. Holding peak subscription capacity all year means 12 packs at USD 200 for 12 months: USD 28,800/year. Applying the published USD 4 pay-as-you-go input gives USD 7,000/year in authenticated usage charges.

These are licensing-only calculations, not portal total costs. They assume that the peak-capacity commitment is retained for the year and that pay-as-you-go is available on the verified terms. Different commitment arrangements can change the comparison. Storage treatment, other service charges, support and anonymous traffic need separate assessment.

Do not model pay-as-you-go as free prepaid overflow in the same environment. Do not average the peak down to a permanently under-sized prepaid allocation. The right comparison is between feasible purchased configurations, not between idealized minimum numbers that cannot be bought together.

Maintenance includes permissions, freshness and releases

A managed portal still has application-specific operating work. For the example portal, someone must investigate a missing invoice, rotate an integration credential, remove a departed dealer administrator and reconcile an ERP request whose response was lost. A custom application needs those owners too, plus ownership of its application stack.

Define data freshness before promising real-time order or credit status. Microsoft's cache documentation describes server-side caching and explains why changes originating in Dataverse are not guaranteed to appear immediately. Test the chosen path, including indirect workflow updates; do not generalize this into “every portal action takes 15 minutes”: Power Pages caching behavior.

Likewise, paid user capacity is not a throughput guarantee. Power Platform request entitlements, connector limits and service-protection limits are separate concerns. Test the month-end document rush rather than assuming that a monthly active-user calculation proves capacity at peak concurrency: request limits and allocations.

Power Pages has supported release-management mechanisms. Microsoft documents moving site and Dataverse components through solutions with the enhanced data model. That is useful, but it still requires correct component inclusion, target configuration and verification: Power Pages solutions and lifecycle management. Budget a rehearsal that tests the portal, flows, identity mapping and ERP integration together.

Storage needs an inventory, not an arbitrary surcharge. Measure document size, retention, audit/log growth, development environments and any existing shared headroom. Microsoft provides separate Dataverse database, file and log capacity add-ons; purchase only what the selected design needs after included capacity: adding Dataverse capacity.

A future move off Power Pages is not the same as exporting a solution to another Power Platform environment. Price rebuilding the web experience, authorization, workflows, document paths and deployment, along with identity relinking and data reconciliation. Custom systems also have exit work when hosting, identity or delivery ownership changes. Avoid counting a full replacement as inevitable in one option and impossible in the other.

Which approach should the buyer take forward?

This is an assessment framework, not a platform benchmark. A hybrid might retain Power Pages for ordinary service cases and use a custom integration service for validated ERP commands. It inherits both operating boundaries and must be priced as such. Neither custom nor low-code is inherently a security assurance.

Before awarding implementation, require a demonstration of company isolation across lists, exports, files and APIs; invitation and revocation; multiple-account access; ERP outage and duplicate-submission recovery; stale-data behavior; bulk-document pagination; deployment into a clean environment; and reconciliation of site usage against the proposed capacity purchase. Test the difficult journey, not only the homepage.

If identity-to-dealer mapping, the permitted ERP interface or the commercial entitlement is still unknown, pause the production commitment. Reduce scope or resolve those questions first. A visually convincing prototype is not evidence that either proposal is safe, supportable or fully priced.

Start with portal discovery, not a platform commitment

A paid portal discovery engagement should produce a user-by-site usage model, environment and identity design, company-permission matrix, ERP operation contract, targeted technical evidence and a 36-month cost model with named unresolved quotes. It should also identify an operating owner, acceptance tests and a recommendation to configure Power Pages, build custom, use a hybrid or defer implementation.

Bring the current ERP interface documentation, customer roles, site map, monthly and seasonal usage estimates, document volumes and Microsoft agreement details. Agree the discovery fee and deliverables separately; discovery is not a promise that a particular platform will win.

Wavect's custom software development service supports scoped portal and integration work. The Bond Analytics case study provides adjacent financial-software delivery context, not evidence for these Power Pages estimates. Request a customer-portal discovery engagement to turn the assumptions into a testable architecture and scoped proposal.