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.
There’s also Power BI report generation for the analytics side — which turned out to be its own rabbit hole worth mentioning separately.
Power BI: PBIR Format and Microsoft Fabric
Power BI’s modern report format is PBIR — Power BI Enhanced Report format. Unlike the old .pbix binary blob, PBIR is a folder of JSON files following published Fabric schema definitions. Each page, visual, and semantic model lives in its own file, which means it’s version-controllable, diffable, and — crucially — generatable by an AI.
The platform takes a design (screenshot or prompt) and produces a complete PBIR package:
- Report definition — pages, visual containers, layout, interactions — all as JSON matching the official
developer.microsoft.com/json-schemas/fabric/item/report/schemas - Semantic model — a TMDL (Tabular Model Definition Language) file that defines the data tables, columns, measures, and relationships the report expects
- Theme — brand colors from your design injected into the report theme
The output is a .zip you can import directly into Power BI Desktop or upload to a Microsoft Fabric workspace. Because the semantic model is included, you can immediately connect it to a real Fabric lakehouse or data warehouse — replace the sample data table with a live connection and the visuals bind to your actual schema.
This is useful when you have a mockup of a dashboard and want to skip the manual “drag visuals, configure data roles, set up the model” work. The AI infers what columns and measures each visual type needs from the design, scaffolds a matching semantic model, and hands you something that’s 80% of the way to production.
Power BI PBIR export costs 15 credits in the platform’s credit system — slightly more than canvas app generation because the semantic model inference adds an extra reasoning step.
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:
- Skeleton agent — defines the screen structure, containers, and navigation layout. No controls yet, just the bones.
- Layout agent — fills in positioning: FillPortions, AlignInContainer, widths/heights. This is where most of the hard layout rules live.
- Controls agent — adds the actual controls (galleries, forms, buttons, text inputs). Enforces Classic vs. Modern compatibility and version pinning.
- Styling agent — colors, typography, icons, visual polish.
- 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:
- Discover the cluster:
GET {envSlug}.environment.api.powerplatform.com/gateway/cluster - Start an authoring session (with 412 redirect handling)
- Fetch the app’s PA-YAML source
Tokens are cached per-user so authentication only happens once — silent refresh handles subsequent requests automatically.
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.