%20-%20Teams%20Logo.png?width=576&height=182&name=Logo%20in%20standard%20arrangement%202%20(RGB)%20-%20Teams%20Logo.png "Epic Fusion")
Power Apps Code Apps: The Power Platform can now do almost anything. That is the problem.
Building an app was never the problem. Running it was. Login. Permissions. Hosting. Monitoring. Security checks. Deployment. What often begins after the actual build for an internal application costs teams time, money, and nerves. It is exactly this part that is changing right now.
With Power Apps Code Apps, you develop a standard modern web app using React, TypeScript, and Vite. And with a single command, you publish it to the Power Platform, where sign-in, sharing, management, and monitoring are already in place. At the same time, Generative Pages in model-driven apps offers a feature that lets you describe an app page and generate actual React code from it. The key point here is not that Microsoft can now do AI. Or that React is suddenly appearing in Power Apps. The line between low-code and traditional software development is breaking down right now. And this from both sides at the same time.
The Separation between Low-Code and Pro-Code was more artificial than we liked to admit anyway.
For years, an invisible dividing line has existed within the Power Platform. On one side, low-code: fast, governed, but eventually you reach the limits of what can be achieved with standard components. On the other, classic web development: complete freedom, but every project starts from scratch (authentication, role modeling, hosting, deployment pipeline, logging). And finally, the uncomfortable question from IT security: Who actually audited this?
What is happening now is remarkable: The separation between low-code and «real» development has always been more artificial than we have been willing to admit. In 2026, it will finally disintegrate.
From the code side come Code Apps, which allow developers to work in their familiar IDE, but end up in the Power Platform. From the low-code side come Generative Pages, which generate production-like TypeScript and React code from a description. The two meet in the middle with React components that run in a managed enterprise environment.
Power Apps Code Apps: A normal Web App, but without all the Infrastructure Baggage.
Microsoft describes Code Apps as follows: Bring Power Apps capabilities to your own code-first web applications. You develop locally. You use familiar frameworks like React or Vue. You have full control over the UI and logic. And yet, the application then runs within the Power Platform.
A description from the community sums it up perfectly: The first Code App is «a regular modern web app that becomes a managed Power Platform app.» No limited toolkit, no «unfortunately, that is not possible because the component cannot do that.» If a design system is specified, it is implemented. If an interaction needs to be custom, it is built. That is web development.
The Path from Idea to Production App
The technical process is surprisingly straightforward for anyone who has ever deployed a web app. But that is precisely the point.
-
Create a project from an official Microsoft Vite template. Install the Power Apps CLI and connect the app to a Power Platform environment with an init command – simply log in with your Power Platform account.
-
Test locally using «Local Play.» The app runs on your computer but already communicates with the environment.
-
Build and push: The CLI returns a Power Apps URL. From this moment on, the app can be launched, shared, and managed in the Power Apps portal just like any other app.
This is the moment when it clicks for most teams. One push notification, and the app is in the company portal. With login, sharing, and management. All without anyone having written a single line of login code. What you get from the platform instead is exactly what makes building your own expensive: Sign-in and account management, application lifecycle management, monitoring via Azure Application Insights, a configurable content security policy, and publishing via a service principal for automated deployments.
The Data is not the Problem. The Data is already there.
A common obstacle to internal projects is not the user interface, but access to the data. Code apps connect to Dataverse, Azure SQL, SharePoint, and Copilot Studio. Existing Power Automate flows can be directly integrated into the app.
So, if you already have processes mapped in Power Automate, you do not need to build new logic. In the simplest case, it just gets a new interface. And if you need your own backend logic, you can extend it: Microsoft documents, among other things, a simple asset management API with Azure Functions as an add-on.
This is where Code apps become interesting. Not because every low-code developer suddenly has to write React. But because teams no longer have to choose between complete frontend freedom and Power Platform governance.
Generative Pages: When model-driven Apps suddenly get their own Frontend.
Model-driven apps have always been the solid, unassuming side of the Power Platform: data-model driven, consistent, governed, and visually very standardized. Anyone needing a truly unique view quickly ended up using custom pages or making compromises.
Generative Pages address this need. And no, it is not simply a case of «AI quickly building me a pretty page.» The more exciting development lies elsewhere. One of the classic limitations of the Power Platform is becoming more permeable. Previously, the rule was often: either you accept the standard interface or you leave the world of the standard interface and build your own. Generative Pages occupy the space in between.
Describe a page instead of building one.
You describe your needs in natural language, name the relevant Dataverse tables, and can even attach an image of what the page should look like, right down to what Microsoft calls a «rough napkin sketch.»
From this, React code is generated that covers both the frontend experience – selecting the right components, the best layout – and the associated business logic. The process then continues interactively: elements can be modified, layouts adjusted, and functionalities extended.
Important for anyone who takes governance seriously: Generative Pages are solution-aware. They appear as «UX Agent Project» lines and can be exported and imported between environments. The standard ALM process is therefore fully integrated. And before users see a page, it must be explicitly published. Nothing accidentally slips into production. And the pages are not isolated: they accept input parameters and are accessed via the regular model-driven navigation. Real building blocks in the flow of the app, not a pretty add-on.
The more exciting approach is via the development environment.
Generative Pages are also available directly in the browser within the App Designer. In practice, however, this approach is regionally limited and currently not an option for us in Europe. The more interesting approach, and one that Microsoft explicitly recommends, is working from within the development environment using AI coding tools like the GitHub Copilot CLI or Claude Code.
The reasons are compelling: access to the latest Frontier models, global availability in public clouds, and the ability to build multiple pages plus their associated Dataverse tables in a single pass. The feature itself is now available globally.
This is based on an orchestrated process: A Planner agent analyzes the request and proposes a plan – which pages, which tables, which app, which solution – and then delegates to specialized agents like a Table Builder and a Page Builder, which generate production-ready TypeScript and React code. Optionally, there is a «verify-in-browser» step with automatically generated Playwright tests.
The language aspect is also resolved in this way: The agent detects all languages activated in the environment and generates the corresponding code. The page then respects the individual regional settings for date, numbers, and currency.
Copilot Chat and Form Fill Assistance: AI is increasingly being integrated into business applications.
Model-driven apps today offer more than just generated pages. With Copilot Chat, end users can ask questions in natural language about their application's data and receive immediate answers. In addition, there is form-fill assistance, which provides suggestions for complex forms based on the available data context. These features are generally available and enabled by default for Dynamics 365 users. For standalone Power Apps, both remain in public preview and must be activated in the Power Platform admin center. Nevertheless, the direction is clear: the user interface is not only becoming more generative. The application itself is becoming increasingly interactive.
Which Power Platform App is best for which Use Case?
The most frequent question in workshops is not «What can the platform do?» but rather «What should I use for what purpose?» At the European Power Platform Conference 2026 in Copenhagen, Microsoft presented a map that clearly outlines this.
From up to down, you relinquish control and gain freedom. Everything except Power Pages BYOC is intended for internal users. Those who need an anonymously accessible interface are located on the far right of this map.
Model-driven Apps
A model-driven app is the right choice if your application is highly data- and process-driven and you need a consistent, managed user interface. Built from the data model, it offers a unified interface, offline functionality, and built-in permissions.
Suitable for internal users.
Generative Pages
A generative page is useful if you're staying within an existing model-driven app but need significantly more UI freedom for a specific process or view. In essence, AI-written code within the model-driven app bridges the gap between the two worlds, making it globally accessible.
Suitable for internal users.
Vibe Apps (Preview)
Internal applications designed for rapid, AI-powered development. Generated by the agent and within the platform's guidelines, you describe it, and the platform builds it.
Suitable for internal users.
Code Apps
Code Apps are ideal for standalone SPAs, modern development teams, and applications where the frontend is more than just a slightly modified data entry form. You gain full control over the UI and logic and work with a React or Vue model.
Suitable for internal users.
Canvas Apps
There is also the middle ground. A mixed team of makers and developers. A fast, low-code core, complemented by custom components. Pixel-perfect development, now also with AI agents (currently in preview) and smartphone support.
Suitable for internal users.
Power Pages BYOC
As soon as an application needs to be publicly accessible or external users require a different routing and access model, the architecture changes. Full-stack, server-side logic, custom code, custom hosting.
Suitable for external users.
The Reality Check: What happens if you choose the wrong One?
At the same conference, Vivian Voss and Yannick Reekmans presented a table that I consider the most useful decision-making tool on the topic. It does not ask «What is possible?» but rather «What goes wrong if I make the wrong choice?»
Two things stand out:
-
Twice the answer is «Standard Form» or «Canvas + PCF». The new possibilities are not automatically the right answer. The most common mistake ist not «too little technology», but too much.
-
The column with the error modes is the real value. Generative Page, if you want to stay within the context of the model-driven app and inherit its security model. Code App, if the application is intended to be standalone, requires more than Dataverse, or if the frontend needs to be treated as a true engineering artifact.
Be honest: Limits and Responsibilities.
A post that only raves about the code will not help you with planning. These points need to be addressed:
- The generated code is not automatically production-ready or compliant with your organization's standards. Microsoft states this unusually clearly: The agent makes a «best-effort attempt» to generate complete, production-ready code, including accessibility and security best practices. However, the team remains responsible for validation. It must be tested and reviewed before publication. This is not a disadvantage, but a normal review step, just like with any code.
- Technical constraints for Generative Pages: Dataverse as the sole data source, a maximum of six tables per page, no simultaneous work by multiple makers on the same page, and a prompt limit of 50,000 characters. These are not reasons not to use the feature. But they should be considered in the architectural decision.
- Code Apps must be enabled in the environment – this is an administrative action, not self-service. The tooling is also evolving. In addition to the existing pac code commands, there's a newer npm-based CLI that will eventually replace them. Microsoft's current Quickstarts already use the new commands. A migration path is documented. Anyone starting today should be aware of this development.
- Licenses: Power Apps Premium is required for these scenarios. Other license types are insufficient. Premium costs $20 per user per month ($12 for 2,000 or more new user licenses) and allows you to build and run an unlimited number of apps. A free Developer Plan is available for a feasibility study.
Conclusion: The exciting Development is not React. And it is not AI either.
We could already do React. AI could already generate code. And low-code could already build applications. The real change is happening in between. Traditional development is migrating to the Power Platform. At the same time, low-code is transcending its previous limitations. This raises a new architectural question. It is no longer: low-code or pro-code? But rather: what do we want to build ourselves, and what should the platform handle for us? From our perspective, that's the truly interesting development. Because an internal application no longer has to automatically start from scratch.
The boundary is disappearing. And that does not make everything easier. But the possibilities are significantly improved.
