cd ../blog

Introducing PowerStudio.dev — AI-Powered Power Apps Generation

A deep dive into PowerStudio.dev: what it does, how the multi-agent AI pipeline works, how we cracked importing from Power Apps Studio, and what's coming next.

</>

Most AI “generate a Power App” demos stop at a screenshot. You click a button, get a pretty image, and then spend three hours manually building the thing anyway.

I got tired of that. So I built the version that actually deploys.

PowerStudio.dev — upload a screenshot or describe your app, get valid PA-YAML back, push it live into Power Apps Studio. No copy-paste, no intermediary steps.

Four Things It Does That Didn’t Exist Before

  • Create from a screenshot or prompt — upload a screenshot, a Figma mockup, or just describe what you want. The AI generates a complete canvas app in PA-YAML format.
  • Import an existing app — paste a Power Apps Studio URL and the platform reads the app’s source directly from the Canvas Authoring API. More on why that was hard below.
  • Redesign with AI — refine any imported or generated app through conversation. Change layout, restructure galleries, swap controls — it reasons over the actual YAML, not a description of it.
  • Push directly to Power Apps Studio — generated YAML streams into a live Studio session via co-authoring. The user ends up inside Studio with the app already there.

Power BI PBIR report generation is also in there, for the analytics side.

The Pipeline: Why One Big Prompt Doesn’t Work

The biggest lesson building this: you can’t ask one LLM to generate a complete Power Apps canvas app in a single call and get consistent, valid output. Power Apps YAML has strict structural rules — containers, FillPortions, AlignInContainer properties, Classic vs. Modern control compatibility — and a single prompt either produces something that looks right but breaks in Power Apps, or something structurally valid that looks nothing like the input.

The solution is a 5-step multi-agent pipeline:

  1. Skeleton agent — defines the screen structure, containers, and navigation layout. No controls yet, just the bones.
  2. Layout agent — fills in positioning: FillPortions, AlignInContainer, widths/heights. This is where most of the hard layout rules live.
  3. Controls agent — adds the actual controls (galleries, forms, buttons, text inputs). Enforces Classic vs. Modern compatibility and version pinning.
  4. Styling agent — colors, typography, icons, visual polish.
  5. Assembly + PowerFX + Packager — combines everything, adds PowerFX formulas, validates YAML structure, packages into a deployable .msapp.

Different models handle different steps. Gemma handles the structural agents (faster, cheaper, good at following strict JSON/YAML schemas). Claude Sonnet handles assembly and PowerFX (better reasoning for formula logic and structural validation).

The pipeline also has a repair loop: after assembly, a validator checks for known Power Apps errors (PA1001, PA2101, PA2108) and structural issues. If it finds problems, it triggers a repair pass with SSE streaming so the user sees real-time progress.

The Import Problem: Cracking the Canvas Authoring API

The hardest technical problem was importing existing apps from Power Apps Studio.

The Canvas Authoring API — the internal API that Power Apps Studio uses — is a Microsoft first-party service. It exposes zero OAuth scopes. Third-party apps can’t request tokens for it. When you try with your own Entra app registration, you get AADSTS650057.

The solution came from studying the open-source power-platform-devkit. It uses a client ID (4e291c71-****-****-****-0a3358e31177) that Microsoft has preauthorized for the Canvas Authoring resource. With device code flow — the user visits microsoft.com/devicelogin and enters a short code once — we can get a valid token.

The import flow then does three API calls:

  1. Discover the cluster: GET {envSlug}.environment.api.powerplatform.com/gateway/cluster
  2. Start an authoring session (with 412 redirect handling)
  3. Fetch the app’s PA-YAML source

The refresh token is cached per-user in Azure Key Vault so users only authenticate once — silent refresh works for ~90 days.

Once we have the YAML, each screen gets converted to an HTML preview by a separate AI pass, displayed as tabs in the Design Passport. Then the user can refine, regenerate, or push back to Power Apps as a copy.

Deploy: Pushing Back to Power Apps Studio

Getting generated YAML back into Power Apps Studio required yet another creative solution.

Power Apps Studio has a Canvas Authoring MCP Server (a .NET binary) that supports co-authoring via the Model Context Protocol. We run this server on Azure Container Apps, wrapped in a custom auth shim that intercepts the authentication flow and injects our tokens headlessly (the MCP binary was designed for interactive use, not server-side automation).

The result: the user clicks “Push to Power Apps”, enters the target environment and app ID, and the generated YAML is streamed directly into a live Power Apps Studio session. They can then continue editing in the native studio.

The Architecture

It’s a monorepo (Turborepo + npm workspaces):

  • Backend: NestJS 10 + Prisma + BullMQ on Railway
  • Frontend: Next.js 14 (App Router) + Tailwind + shadcn/ui on Vercel
  • Storage: Cloudflare R2 for screenshots
  • DB: PostgreSQL on Neon
  • Queue: Redis on Upstash
  • Auth: Clerk
  • Payments: Stripe (credits + subscriptions)
  • Observability: Langfuse for AI tracing, Sentry for errors

The credit system is pay-per-use: generating an app costs 10 credits, importing costs 10, deploying costs 5, refinements are 1-3 credits depending on complexity.

What’s Next

The roadmap has three priorities:

Quality parity — porting the explicit rule library from the original prototype (layout rules, control version registry, anti-pattern detection, gallery contracts) into structured, versioned policies that the validator can enforce. This is the difference between “usually works” and “reliably works.”

Multi-screen app generation — right now the platform generates individual screens. The next step is taking a full PRD, navigation flow, and data model and generating a complete multi-screen app with shared components and proper state management.

App modernization — ingesting an existing .msapp, analyzing the control tree, and producing a modernized version: Classic → Modern controls, better responsiveness, anti-pattern fixes, with a diff report showing what changed.


If you work with Power Apps and want to give it a try: powerstudio.dev. There’s a free tier with starter credits.

I’m curious what the broader Power Platform community thinks — especially anyone who’s tried to automate canvas app generation before and hit the same walls.