the MEOWER-PLATFORM

Six days to a Power Pages portal with GitHub Copilot

What shifted in my Power Platform build day when I added GitHub Copilot to the mix.

6working days
9custom tables
60+columns
28pull requests
0merge headaches

The honest opening

I keep noticing something. My time in the Power Platform maker experience is shifting. I still love it and still use it. The mix of where I spend my build day has just moved. The tool that moved it is GitHub Copilot. I used both the desktop app and the terminal CLI across this build, and I will just call it Copilot from here on. So let me tell you what that looks like in practice, using a recent six day proof of concept as the example.

The one sentence version

Six working days. A portal, a Dataverse schema, a Copilot Studio agent, a custom chat embed, a PCF control, and an Azure AI Foundry call, all wired together and demo ready. The point of the story is not necessarily the product (although it is very cool and if you are not experimenting with GitHub Copilot, what are you waiting for?). The point is the loop.

The point of the story is not the product. It is the loop.

The collaboration model

Before I get to the tools, I want to name the shape of the partnership, because it is the piece that actually changed everything. Treat the agent like a senior engineer who never context switches. I bring the judgment. Copilot brings the typing. We meet in the middle, often, in small commits.

  1. I bring strategy and customer empathy

    What needs to exist, why it matters, what a real user will do with it. Copilot does not have that judgment and does not pretend to. That part stays with me.

  2. Copilot brings the execution

    Plain English requirements turn into working code, scripts, schema, and config. Usually in one response. This is the part that used to eat my week.

  3. I review, push back, and steer

    When it over engineers, I tell it to back off. When it hits a dead end, I name the dead end and pick the next path. Steering is half the value of the whole loop.

  4. We commit often, in small batches

    28 pull requests across this build. Each one is a coherent unit of value. Never a whole day of work sitting on one branch. That is where zero merge headaches comes from.

Where the maker experience used to sit in my day

In the browser. Clicking through the modeler, dragging fields, tweaking forms, wiring the flow visually. It is a useful surface and I still love it for exploration and for the parts of a build that benefit from a real human eye on the canvas. What has shifted is the mix. When I already know the shape of what I am building, I find myself reaching for GitHub Copilot first and coming back to the maker experience for the pieces that deserve it.

What replaced it, in practice

A Copilot window, a plain English requirement, a small pull request, a review, a merge. Repeat. The maker experience is still very much part of my toolbox. The balance has just shifted for the kind of assembly work where I already know what I want.

What demo ready actually meant

This is the part I want to slow down on. Demo ready used to mean a couple of screens, some sample data, and a lot of hand waving over the parts that were not built yet. With GitHub Copilot in the loop, demo ready meant all of this actually worked.

Every one of those bullets used to be a bullet on a roadmap slide. This time they were all working, all wired together, and all reviewable in a live demo. That is the shift I keep coming back to. GitHub Copilot did not just help me build a bigger version of what I already knew how to build. It changed what the word ready means for me.

GitHub Copilot did not just help me build a bigger version of what I already knew how to build. It changed what the word ready means for me.

Four moments from the build

The four column analysis panel. I described the layout I wanted for surfacing AI analysis on both the wizard and the case detail page. Copilot extended the schema, built the renderer, mirrored it across pages, and caught an overlap bug on its own. Live in about 25 minutes.

The bulk rebrand. I asked it to swap the accent color everywhere. It regex scanned 19 files, made the swap case insensitively, verified no residue, and re uploaded. About four minutes.

Semantic similar cases without embeddings. I told it to use the model we already had instead of standing up a vector setup. It extended the prompt with a similar cases array, pre fetched closed cases, updated the renderers, and backfilled 48 already persisted verdicts with a re runnable script.

The chat embed pivot. I started with a self hosted approach and ran into CDN and content security policy friction that was mine to own, not the platform's. I named it out loud and Copilot moved us to Bot Framework WebChat with brand style options and anonymous DirectLine, which is the supported Microsoft path. Working in about 30 minutes and behaving exactly the way the docs describe.

The parts that were outside my usual lane

This is the part I want to be honest about. A lot of what shipped in those six days was not Power Platform work. It was the connective tissue around it. I am a Power Platform person by trade. I do not write JavaScript from scratch, I do not hand craft CSS, and I do not spend my weekends in a terminal. Copilot let me build the pieces I would normally have to hand off or skip.

None of that is Power Platform work. All of it made the Power Platform work land in a real demo. That is the part that surprised me most. Copilot did not just speed up the pieces I already knew. It let me finish the pieces I would have otherwise left unfinished.

Architecture flow: user in the portal reaches Power Pages, which embeds the Bot Framework WebChat pointing to a Copilot Studio agent. Power Pages also connects to Dataverse (9 tables, 60+ columns) and to an Azure Function App TypeScript proxy that calls Azure AI Foundry gpt-5-mini. Both Copilot Studio and the Function App also touch Dataverse.
How the pieces fit. Power Pages in the middle, everything else wired in.

The exact stack I ran, so you can copy it

I want to name the tools instead of hand waving. If you are trying to figure out where to start, this is the shape of the toolbox on my desk right now.

Deterministic backbones:

Skills loaded on demand:

That is the whole list. Not a broad category name, the actual thing I typed. If you are a Power Platform person eyeing this and wondering whether the ramp is worth it, this is what the ramp looked like for me.

Five things I actually learned

  1. Treat the agent like a senior engineer, not a tab

    Plain English intent works better than file path level instructions. Tell it what and why, not where to click.

  2. Push back when it over engineers

    Saying no or back off is half the value. A shorter answer is usually the right answer.

  3. Read the output critically

    When it is wrong, my requirement was usually vague. Tightening the ask fixes both sides of the loop.

  4. Commit early and often

    The app handled worktrees and per pull request branches for me. 28 pull requests. Zero merge headaches.

  5. The decisions stayed with me

    What to skip, when to pivot, when to say that is not the demo. That authority never left my chair.

The part I keep circling back to

The maker experience is not going anywhere for me. What has changed is where I open it in a day. I still go there when a screen needs a real human eye, when I am exploring a new feature, or when the visual canvas is genuinely the fastest way to think. I go to Copilot first when I already know the shape of what I am building. Those two modes complement each other, and it turns out having both in the mix is what made six day proofs of concept start feeling normal.

Closing

I stayed in charge of the judgment. Copilot stayed in charge of the typing. The maker experience stayed exactly where it belongs, right next to both of us. Six days, one working portal, and a clearer sense of how the pieces fit together in the new shape of my day.

Back to the blog