The new Power Platform Pro-Code Era: Code Apps vs Power Pages SPA

Microsoft has introduced two new pro-code development options within the Power Platform — Power Apps Code Apps and Power Pages Single-Page Applications — that allow professional developers to build custom React-based user interfaces while the platform handles infrastructure, authentication, and data connectivity. Both options run on Dataverse and support the full catalog of 1,500+ Power Platform connectors, but they serve different purposes and require distinct toolchains. The shift marks a new era where "low code" means writing less code because the platform absorbs backend complexity, not because it generates the UI.

The phrase " low code " has carried a lot of baggage over the years. For a long time it was synonymous with drag-and-drop, formula bars, and the implicit promise that you could build real applications without writing real code . That era is not over — canvas apps and model-driven apps are still excellent tools — but something has shifted , and it is worth naming clearly. AI has changed what "low code" means . The new definition is not about writing less code because the platform generates it for you. It is about writing less code because the platform absorbs the infrastructure . Consider what building a serious business application actually requires: None of this is your business problem . All of it is work that stands between you and the thing you are actually trying to build . This is where the Power Platform has always been something more interesting than its "low code" label suggests. Dataverse gives you an enterprise-grade relational store with row-level security, audit trails, and a rich metadata model — without a DBA. Over 1,500 connectors let your app talk to Salesforce, SharePoint, Azure DevOps, or a payment gateway with a single CLI command and a generated TypeScript service, rather than weeks of OAuth plumbing. Power Automate handles the orchestration layer. The platform enforces your organisation's Data Loss Prevention policies automatically. Custom APIs, server-side logic endpoints, and Dataverse plugins give you escape hatches for anything the platform does not handle natively. In short: the Power Platform takes care of everything that is not your business logic, so that your code can be exclusively about your business logic . That reframing matters because it changes the profile of developer the platform is now genuinely useful for . It is not just makers and citizen developers anymore. It is professional engineers who want the productivity of a managed platform without surrendering control of what their users actually see and experience. And that is exactly where Power Apps Code Apps 🟠 and Power Pages Single-Page Applications 🔵 enter the picture. Both are answers to the one limitation that has always frustrated developers on the Power Platform: the UI. Canvas apps are powerful but visually constrained. Model-driven apps are consistent but rigid. With Code Apps and Power Pages SPAs, you bring your own React application — your own components, your own design system, your own interaction patterns — and the platform simply becomes the infrastructure layer beneath it. You write the UI . The platform handles everything else . Both generate web applications. Both let you write your own frontend. Both sit on Dataverse. And yet they serve fundamentally different purposes, come with different toolchains, and make different trade-offs. If you are evaluating which path to take — or you are a platform architect trying to set a standard for your organisation — this post is for you. 🟠 Power Apps Code Apps are a code-first way to build apps that run inside Power Apps. You write React or any framework , scaffold and publish with the npx power-apps CLI the older pac code command group will be deprecated in a future release — start migrating to the npm-based toolset now , and the Power Apps runtime handles authentication, hosting, and connector proxying. The result feels like a regular web app to your users, but it runs under the Power Apps umbrella — which means it inherits DLP policies, Conditional Access, sharing controls, and the full catalogue of 1,500+ Power Platform connectors. Note on framework choice: The official tooling, scaffolding templates, generated connector service classes, and AI skills all targetReact + Vite + TypeScript— that is the well-supported default. The platform does also accommodate plain JavaScript and other frameworks; @wyattdave's guide to plain-JS Code Apps is a practical example of a lighter-weight setup without the TypeScript or Vite overhead. 🔵 Power Pages SPAs are a code-first flavour of Power Pages sites. Instead of using the low-code Power Pages Studio to build pages with drag-and-drop sections and Liquid templates and -my personal pov- cry desperately when you have to add basic form validations , you upload a compiled static bundle — your React app — which becomes the entire site. The Power Pages runtime hosts it, provides the Dataverse Web API, and handles authentication for external users. The key insight: Code Apps are portals for your employees. Power Pages SPAs are portals for the world. This is the most important distinction, and everything else flows from it. 🟠 Code Apps authenticate users against Microsoft Entra ID . Every user must have a Power Apps Premium licence or a Developer Plan for testing . The Power Apps host manages the entire auth flow — tokens, consent, refresh — and your code never touches a credential. This is ideal for internal line-of-business applications where your users are already in your tenant. 🔵 Power Pages SPAs are designed for external users who may not have a Microsoft account at all. Power Pages supports Microsoft Entra External ID, LinkedIn, local username/password accounts, and anonymous access. Users pay per-site rather than per-user, which makes the economics work for customer-facing portals with large or unpredictable audiences. The practical implication: if you need an employee expense portal, use Code Apps. If you need a customer self-service portal or a supplier onboarding site, use Power Pages SPA. This difference surprises many developers coming from a canvas app background. 🟠 Code Apps expose the full Power Platform connector ecosystem to your TypeScript code. When you run npx power-apps add-data-source , the CLI generates fully typed TypeScript service classes for that connector. You get autocomplete, compile-time type checking, and IntelliSense for every table, column, and action. If the connector works in Power Automate or canvas apps, it works in a Code App. 🔵 Power Pages SPAs are Dataverse-only on the data side. You call Dataverse through the Web API / api/ , and every table your frontend touches must have explicit Table Permissions configured and assigned to Web Roles . There is no CLI command to add a connector. If you need to call an external API — say, a CRM, a payment gateway, or a weather service — you must proxy that call through a Server Logic endpoint or a Cloud Flow, neither of which is as frictionless as simply adding a connector in a Code App. Both platforms have a proper server-side logic story — the difference is one of language, not capability. 🔵 Power Pages SPA has native server-side JavaScript endpoints hosted at / api/serverlogics/<name . These run on the server, never expose secrets to the client, can aggregate data across multiple Dataverse tables, and can call external REST APIs or Azure Functions with credentials stored safely. The /add-server-logic skill in the power-platform-skills AI plugin https://github.com/microsoft/power-platform-skills can generate these endpoints from a natural-language description — see the AI-assisted development section below. 🟠 Code Apps have an equivalent in Dataverse Custom APIs — reusable, versioned server-side operations that run inside the Dataverse execution pipeline, can be called from any client, and benefit from all the platform's security and governance guarantees. Writing a Custom API feels very similar to writing a Dataverse plugin: you author the handler in C , deploy it as a plugin assembly, and register it against the Custom API definition. Power Automate flows are also a valid option for orchestration-heavy logic, and they integrate with Code Apps via the npx power-apps add-flow CLI command. The practical difference is a language choice : if your team lives in JavaScript and wants the fastest path from idea to server-side endpoint, Power Pages Server Logic wins on friction. If your team is comfortable in C and wants the tighter Dataverse integration, transaction control, and testability that come with a proper plugin-based Custom API, Code Apps has a fully equivalent answer. Neither approach is inherently superior — it depends on the skills your team already has. Both platforms support npm run dev to start a local development server with hot-reload — but the experience they provide is very different. 🟠 For Code Apps, npm run dev starts the app and the Power Apps client library @microsoft/power-apps handles the connector auth proxy inline. The local server connects to real Power Platform connectors, acquires tokens, and proxies requests automatically. The result is full hot-reload with real data from production connectors out of the box, no separate process required. Note: the older pac code run command served the same purpose but will be deprecated in a future release in favour of this npm-based approach. 🔵 For Power Pages SPAs, npm run dev starts the local Vite or Angular, or Astro dev server just as fast — but it serves the frontend only. Calls against / api/ are not proxied and will fail locally; you are developing with mock data or stub services until you deploy. The only way to test against real Dataverse data is to upload the bundle with pac pages upload-code-site and test in the browser against the live environment. Both platforms get a fast local feedback loop for UI work. Code Apps go further by giving you real connector data in that same loop, which makes the overall inner development cycle meaningfully faster when data-driven behaviour matters. 🟠 Code Apps use per-user licensing : Power Apps Premium at $20 per user per month. For internal apps with a known, bounded user base, this is predictable and often already covered by existing Microsoft 365 licensing. 🔵 Power Pages uses per-site, capacity-based licensing billed monthly per site, with separate packs for authenticated and anonymous users: | User type | Tier 1 price | Pack size | |---|---|---| | Authenticated | $200 | 100 users | | Anonymous | $75 | 500 users | Volume tiers reduce the per-user cost significantly Tier 2 authenticated: $75/pack at 10,000+ users . One important nuance: users who already hold a Power Apps Premium or Dynamics 365 enterprise licence do not consume authenticated user capacity — they access the site for free, which can significantly reduce the effective cost for internal-facing Power Pages sites. For external portals with large or unpredictable audiences the per-site model is a significant advantage over per-user licensing. Conversely, for a small internal tool, the per-user model of Code Apps is typically cheaper. 📌 Pricing details and tier thresholds can change; always verify with the Power Platform licensing FAQ — Power Pages section . Both integrate with standard Power Platform ALM pac solution . 🟠 Code Apps live in a standard npm project. Solution packaging for 🔵 Power Pages requires manual Web API queries to find component type values and GUIDs, which is more cumbersome than the Code Apps path. The table below maps common development tasks to their equivalent CLI commands in each world. Code Apps CLI toolsets: Microsoft ships two overlapping CLIs for Code Apps. The original pac code sub-command group part of PAC CLI will be deprecated in a future release— new development should target the @microsoft/power-apps npm package exclusively. Commands in the table below use the current toolset where a confirmed equivalent exists; entries that remain as pac code do not yet have a documented npm equivalent. | Task | 🟠 Code Apps | 🔵 Power Pages SPA | |---|---|---| Authenticate to environment | pac auth create --environment <env-id | pac auth create -u <dataverse-url | Create / scaffold project | npx power-apps init --display-name "App Name" | No equivalent — start from a React template and upload | Run locally | npm run dev auth proxy + dev server via @microsoft/power-apps client | npm run dev frontend only — / api/ calls fail locally; deploy to test with real data | Deploy / publish | npm run build && npx power-apps push | pac pages upload-code-site --rootPath <src --compiledPath <build --siteName "Site Name" | List apps / sites | pac code list no npm equivalent yet | pac pages list | Download for editing | n/a source is local | pac pages download-code-site --path <dir --webSiteId <site-guid | Add Dataverse table as data source | npx power-apps add-data-source -a dataverse -t <table-logical-name | Configure Table Permissions + Web Roles in Studio or YAML, then pac pages upload | Add a non-tabular connector | npx power-apps add-data-source -a <apiName -c <connectionId | Not supported — proxy via Server Logic or Cloud Flow | Add a tabular connector | npx power-apps add-data-source -a <apiName -c <connectionId -t <tableName | Not supported | List tables for a connector | pac code list-tables -a <apiId -c <connectionId no npm equivalent yet | Not applicable | Remove a data source | pac code delete-data-source -a <apiName -ds <dataSourceName no npm equivalent yet | Remove Table Permission from YAML + re-upload | Add server-side logic | Register a Dataverse plugin or npx power-apps add-flow <flowId | Copilot CLI plugin: /add-server-logic generates JS at / api/serverlogics/<name | Add / register a cloud flow | npx power-apps list-flows → npx power-apps add-flow <flowId | Studio: Set up → Cloud flows → Add cloud flow; invoke via POST / api/cloudflow/v1.0/trigger/<guid | Remove a flow | npx power-apps remove-flow <flowId | Remove flow registration in Studio | Add a Dataverse action or function | npx power-apps find-dataverse-api → npx power-apps add-dataverse-api <name | Call via Web API directly from client code | List connection references | pac code list-connection-references -s <solutionId no npm equivalent yet | Not applicable | Package as solution | pac solution init ... standard flow | pac solution init ... → pac solution add-solution-component -sn <sol -c <siteId -ct <componentType | So far we have talked about CLIs, commands, and architecture. But there is a third layer that deserves its own section, because it changes the day-to-day experience of building on both platforms significantly: Microsoft's official AI plugin marketplace for Power Platform development , hosted at github.com/microsoft/power-platform-skills https://github.com/microsoft/power-platform-skills . This is a collection of plugins for Claude Code and GitHub Copilot CLI that wrap the entire development lifecycle of both Code Apps and Power Pages SPAs into conversational AI skills. Instead of memorising CLI flags and YAML schemas, you describe what you want in plain language and the agent handles the scaffolding, configuration, and deployment. The repository is a plugin marketplace. A single quick-install script sets up all plugins and keeps them updated: macOS / Linux / Windows cmd curl -fsSL https://raw.githubusercontent.com/microsoft/power-platform-skills/main/scripts/install.js | node Or install individual plugins manually inside a Claude Code or GitHub Copilot CLI session: /plugin marketplace add microsoft/power-platform-skills /plugin install power-pages@power-platform-skills /plugin install code-apps@power-platform-skills The installer also takes care of installing pac CLI if it is not already present — a nice quality-of-life touch for developers new to the platform. The code-apps plugin /plugin install code-apps@power-platform-skills wraps the entire Code Apps workflow into a set of skills built on React + Vite + TypeScript, deployed via npx power-apps push . The key skills are: | Skill | What it does | |---|---| /create-code-app | Scaffolds a complete new Code App, wires up the Vite dev server, and deploys it to your environment | /deploy | Builds and pushes an existing app with npx power-apps push | /list-connections | Lists available Power Platform connections so you can find the connection IDs you need | /add-datasource | Router skill — describes what data you need and picks the right connector skill | /add-dataverse | Adds a Dataverse table with fully typed TypeScript models and service classes | /add-sharepoint | Adds SharePoint Online connector with generated services | /add-azuredevops | Adds Azure DevOps connector | /add-teams | Adds Microsoft Teams connector | /add-excel | Adds Excel Online Business connector | /add-onedrive | Adds OneDrive for Business connector | /add-office365 | Adds Office 365 Outlook connector | /add-mcscopilot | Adds a Copilot Studio agent connector | /add-connector | Fallback skill for any connector not covered by a dedicated skill | One important architectural note the plugin enforces: all data access must go through Power Platform connectors . Direct fetch or axios calls to external APIs do not work at runtime inside the Code Apps sandbox. The plugin actively guards against this pattern and redirects you to the correct connector-based approach. The plugin also uses npx degit for scaffolding rather than git clone , which is the recommended approach for creating new projects from the official templates. The power-pages plugin is considerably more comprehensive, reflecting the greater complexity of the Power Pages SPA surface area. It provides a broad set of skills covering the entire site lifecycle, supported by 4 specialised sub-agents and 2 bundled MCP servers Playwright for browser testing and Microsoft Learn for grounded documentation lookups . | Skill | What it does | |---|---| /create-site | Scaffolds a full site from a React, Vue, Angular, or Astro template; applies design direction; provides live browser preview throughout | /deploy-site | Builds and uploads to Power Pages via pac pages upload-code-site ; handles common blockers like JS attachment restrictions | /activate-site | Provisions the website record and subdomain; polls until the site is live at its public URL | /test-site | Runtime-tests a deployed site using a real browser Playwright ; crawls links, captures network traffic, screenshots failures | /setup-datamodel | Analyses site requirements and creates Dataverse tables, columns, and relationships; produces a Mermaid ER diagram | /add-sample-data | Populates Dataverse tables with realistic test data in dependency order | /integrate-backend | Router skill — analyses your business problem and recommends Web API, Server Logic, Cloud Flow, or a combination | /integrate-webapi | Full Web API lifecycle: scans codebase for mock data, generates typed API client and CRUD services, configures Table Permissions and site settings YAML | /add-server-logic | Creates a Server Logic endpoint server-side JS at / api/serverlogics/<name ; grounded in live Microsoft Learn docs via the bundled MCP | /add-cloud-flow | Discovers available flows in the environment, registers them with the site, generates client-side invocation code | /create-webroles | Generates Web Role YAML files with proper UUIDs; enforces uniqueness constraints | /setup-auth | Adds login/logout components and role-based UI patterns; framework-specific hooks, composables, services | /audit-permissions | Audits table permissions against site code and live Dataverse metadata; produces an HTML report grouped by severity | /add-seo | Generates robots.txt , sitemap.xml , and meta tags Open Graph, Twitter Cards | The /integrate-webapi skill deserves a closer look because it demonstrates what this kind of AI assistance can actually do. It does not just generate a data access layer — it scans your existing codebase , identifies components using mock data or placeholder fetch calls, maps them to your Dataverse tables, and then refactors those components to use real API calls. It also generates the Table Permission YAML files needed for deployment and validates column names directly against live Dataverse metadata before writing them. That is a non-trivial amount of work that previously required deep knowledge of Power Pages conventions. The plugin also includes 4 specialised sub-agents that are spawned automatically during certain skills: | Agent | Role | |---|---| | Data Model Architect | Proposes Dataverse tables and ER diagrams based on your site's code read-only — proposes, never creates | | Web API Integration | Creates typed client, services, and hooks for a specific Dataverse table | | Table Permissions | Proposes CRUD permissions and Web Role scopes with a visual diagram | | Web API Settings | Proposes site settings with validated column names queried from live Dataverse | The "read-only, propose before acting" pattern is consistent across the agents — no schema changes are made until you explicitly approve the proposal. This is the right default for a tool that is touching production infrastructure. The plugin documentation suggests this sequence, which covers the full lifecycle from zero to a live, secured site: 1. /create-site → Scaffold, design, and build pages with live preview 2. /deploy-site → Upload to Power Pages environment 3. /activate-site → Provision a public URL 4. /setup-datamodel → Create Dataverse tables from site analysis 5. /add-sample-data → Populate tables with test records 6. /integrate-backend → Pick the right backend approach 7. /create-webroles → Define access roles 8. /setup-auth → Add login/logout + role-based UI 9. /audit-permissions → Verify permissions for security issues 10. /add-seo → Search engine optimisation 11. /deploy-site → Push final changes live 12. /test-site → Runtime smoke test on the live URL Each skill is independent and checks its own prerequisites, so you do not need to follow this exact order. | Capability | 🟠 Code Apps plugin | 🔵 Power Pages plugin | |---|---|---| | Scaffold new project | /create-code-app | /create-site | | Deploy to environment | /deploy | /deploy-site | | Activate / go live | Automatic on push | /activate-site separate step | | Add Dataverse table | /add-dataverse | /setup-datamodel + /integrate-webapi | | Add connector / data source | /add-datasource routes to 9 connector skills | Not applicable — Dataverse only | | Server-side logic | No dedicated skill — use flows or Dataverse plugins | /add-server-logic | | Cloud flow integration | /add-datasource → add-flow npm CLI | /add-cloud-flow | | Authentication setup | Automatic Entra ID via host | /setup-auth | | Access control | Automatic Entra ID roles + DLP | /create-webroles + /audit-permissions | | Data modelling | Via connector skills | /setup-datamodel with ER diagram | | Sample data | Not included | /add-sample-data | | Runtime testing | Not included | /test-site Playwright-based | | SEO | Not applicable internal app | /add-seo | The difference in skill depth reflects the difference in platform complexity. Code Apps offload a lot of concerns — auth, hosting, connector wiring — to the platform runtime, so there is less for a developer to configure. Power Pages SPAs require explicit configuration of permissions, roles, auth providers, and site settings, which is why the plugin is considerably more capable in those areas. 🟠 Choose Code Apps when: 🔵 Choose Power Pages SPA when: When you might use both: A common enterprise pattern is to use a Power Pages SPA as the external-facing portal — customer onboarding, case submission, partner collaboration — while Code Apps serve the internal team working those cases. They share the same Dataverse environment and the same data, but serve entirely different audiences with the appropriate auth model for each. Code Apps are not a replacement for Model-Driven Apps. They solve different problems, and picking the wrong one is a common mistake. Choose a Model-Driven App when: Choose a Code App instead when: The practical heuristic : start with a Model-Driven App. If you find yourself fighting the platform to make a form look or behave the way you need, that is the signal to reach for a Code App. If you can get the job done with forms and views — possibly with PCF controls for specific fields — stay in the Model-Driven world and ship faster . The Power Platform is increasingly a platform for professional developers, not just low-code makers. Code Apps and Power Pages SPAs are both evidence of that shift: Microsoft is giving developers the tools to write real code while staying inside the managed, governed, connector-rich environment of Power Platform. The choice between them is not about technical capability — both can produce excellent applications. It is about who your users are and what data they need . Get that analysis right, and the rest of the architecture follows naturally.