Power Platform Development Changed: Why Professional Makers Need to Start with a Prompt

A practical look at building a Power Platform solution with a prompt, and what it means for professional makers.

TL;DR I gave GitHub Copilot a 480-word prompt and, in one run, it built a working Power Platform request solution with Dataverse tables, security, a model-driven app, a canvas app, and three Power Automate flows. The first build took 44 minutes and used 661 credits, which I estimated at less than $7 in credits. If you build Power Platform solutions professionally, this is the part you should pay attention to: the starting point for development is moving from dragging and dropping to describing what you want.

I have built Power Apps and Power Automate solutions for a long time, so I am not easily impressed by a demo that creates a pretty screen and an app that doesn't really work. What got my attention here was not one isolated AI trick. It was how much of a real solution I could build, how quickly I could build it, and how little of the traditional construction work I had to do myself.

The big story is not the request-management app I built. The story is that professional makers need to start learning how to build with words. You still need your Power Platform skills. You still need to understand architecture, Dataverse, security, automation, UX, testing, and what a business actually needs. But the amount of implementation work you can hand to these tools has changed fast, and the results are getting really good.

If you would rather watch the full walkthrough, check out the video here: Power Apps Development Will Never Be the Same

How did this solution start?

My design was not some giant specification. I had a simple workflow in mind: a requester submits something, it gets routed to the right manager, the manager breaks it into tasks and assigns those tasks, the doer completes the work, and the original requester gets notified when everything is finished. I also wanted files, overdue reminders, and enough variety to make it useful for teaching.

That was basically the brainstorming. The interesting part is what happened next. When I wanted to build this solution, I did not start in Power Apps Maker Studio. I started with Copilot, talked through the business process, and used that conversation to produce the prompt I could hand to the GitHub Copilot app.

Inside the GitHub Copilot app, I used the Power Apps, Power Automate, Copilot Studio, and model-driven app plugins to build across the solution. That is a fundamental workflow change. Instead of opening Maker Studio and beginning with controls, screens, and drag-and-drop authoring, I began with a conversation and a description of the outcome. I mainly went into Maker Studio afterward to verify the generated work and make small tweaks.

What did the first prompt build?

The initial solution was intentionally broad because I wanted to demonstrate several parts of the Power Platform working together. From that prompt, the build included:

• Three Dataverse tables for request types, work requests, and work tasks, including the supporting security.

• A model-driven app for requesters to submit work.

• A canvas app for managers to triage requests, create tasks, assign people, upload files, and for doers to update their work.

• A Power Automate flow that routes a new request to the appropriate manager based on request type.

• A flow that notifies the original requester after all related tasks are complete.

• A daily overdue reminder flow, otherwise known around here as a nag flow.

• Deep links in notifications so people can jump back into the work.

For the demo, I submitted a marketing request to “Get Buddy ready for Christmas,” created tasks to give Buddy a bath and buy him a Santa suit, attached a file, assigned the work, and moved the tasks through the process. Silly scenario, real architecture.

How fast did the GitHub Copilot app build the solution?

Here is the part that made me stop and really think about where this is going.

The main prompt was about 480 words. The build ran for 44 minutes and used 661 credits, which I estimated at less than $7. I did not go in afterward and quietly rebuild half of it. The apps, flows, Dataverse tables, security, and solution you see in the video came from that run.

That is one demo run, not a universal benchmark. Your solution, environment, complexity, and iteration will change the numbers. I also spent more later when I had Copilot do hardening and testing. But even with that caveat, think about the amount of functioning Power Platform work that came out of a relatively small amount of natural-language instruction.

This is why I keep telling professional makers that your first step should increasingly be a tool where you describe the outcome before you start dragging controls around.

Do you need to be a prompt expert?

There is another important detail. I did not magically know the perfect 480 words to type.

I started with my rough notes and talked the idea through with Copilot. I gave it the workshop context and the pieces I wanted students to learn, including the model-driven app, canvas app, Dataverse, and flows. We went back and forth for roughly ten minutes. Once it understood what I wanted, I asked it to give me the prompt I should use for the build.

That workflow matters. The skill is not memorizing some giant magical prompt formula. The skill is being able to explain the business problem, recognize the important requirements, have a conversation about the design, and judge whether the result makes sense. Those are exactly the skills experienced makers already have.

What else can you build from the same process?

Once the core solution existed, the fun part was seeing how many different experiences I could put on top of the same business process. This is where the demo becomes more than “AI built an app.” It shows how quickly we can explore different ways to solve the same problem.

What can a generative page add?

I asked Copilot for a generative page to improve the requester experience inside the model-driven app. Instead of treating it as a completely separate solution, it became another front end over the same request process. The existing Dataverse and automation pieces could keep doing their jobs.

Reminder: This generative page wasn't necessary or doing anything new. Just me showing off we could do the same stuff a different way. 😁

How does a Copilot Studio agent fit?

Next I asked for a Copilot Studio agent that could work with the same solution. The agent could retrieve my submitted requests and interact with the underlying data and process. In my run, building that agent used 213 credits. Again, the interesting part is not merely that an agent exists. It is that I could add a completely different interaction model to the same business solution with another prompt. Also, because I am asked often, it is using the same tables. I am not replicating the data, just a different way to interact with the same data. This is laying the framework for a future concept.

Also, the agent isn't just read. It fully supports adding requests, editing them, etc while also just being a way to chat about the work. The agent can basically do everything the apps can do. And since I made the logic for routing requests in a cloud flow, I didn't have to repeat that work here.

What does a Copilot managed runtime app add?

Then I went further and had it build a Copilot managed runtime app. Why? Because I could. I used that as a consolidated experience that could cover submitting requests, the manager queue, and a task board. In the demo I could drag a task such as “buy a Santa suit” into In Progress and update the underlying work.

I estimated that build at about $2.50 in credits. Sometimes I am honestly at a loss for words when I look at what a short prompt can produce now. Also, notice they all kept the same styling, very handy and required no effort on my part.

Does AI-assisted building replace professional makers?

If this feels a little uncomfortable, I get it. We have spent years learning how to build with formulas, controls, actions, tables, flows, components, solutions, and all the other pieces. Now I am telling you that more of the starting experience can be a conversation.

But this is not an either-or choice. I am not saying prompting replaces Power Platform expertise. I am saying prompting is becoming another part of that expertise.

The GitHub Copilot app did not just take an order and disappear into the back room. It asked me questions and presented design choices that affected the outcome. I still had to understand what those choices meant, supply the business context it could not know on its own, and decide which direction made sense for the people and process I was building for. That judgment was part of the value I brought before the first app was generated, not just something I added during cleanup.

A generated app can still need iteration. You still have to understand whether the data model is sensible. You have to validate security. You have to test the flows. You have to recognize a bad UX decision. You have to know when a business requirement is missing. In my own build I later spent roughly $20 in credits having Copilot do more hardening and testing. Fast first builds do not eliminate responsible engineering.

What changes is where you spend your time. If AI can construct the first 80 or 90 percent of the mechanical pieces from a good conversation, you can spend more of your energy on requirements, architecture, validation, usability, and the weird edge cases that actually require experience.

What should professional makers do now?

Do not wait until these tools are perfect. Start getting repetitions now.

• Take a small app you already understand and try describing the complete outcome instead of manually building the first version.

• Use Copilot as a thinking partner before you build. Give it your rough notes, constraints, and goals, then ask it to help turn the conversation into the build prompt.

• Judge the generated architecture, not just the pretty screen. Look at the tables, relationships, security, formulas, flows, error handling, and lifecycle.

• Iterate in natural language, then drop into the traditional maker experience when direct editing is faster or more precise.

• Test and harden the result. “It built in 44 minutes” is exciting. “It is safe and maintainable in production” is still your responsibility.

What is the fundamental change in Power Platform development?

For years, the first question was usually, “Which app type do I open, and what do I start dragging onto the screen?”

Increasingly, I think the first question is going to be, “Can I describe the solution well enough for the tools to build a useful first version for me?” This might (does) mean that we need to spend more time up front planning and requirements gathering.

And these tools do not make professional makers less important. I think it makes our judgment more important. As more people gain the ability to create software with natural language, knowing what should be built, how the pieces should fit together, whether the result is secure and maintainable, and how to fix it when it is wrong becomes incredibly valuable.

The tools are moving fast. The results are already better than a lot of people realize. If Power Platform is what you do for a living, you need to be using this stuff, not just reading announcements about it.

FAQ

Did Copilot really build the whole Power Platform solution from one prompt?

For the initial build shown in the video, yes. I used a roughly 480-word prompt and the resulting run created the apps, flows, Dataverse tables, security, and solution structure I demonstrated. I later used additional prompts for other experiences and for hardening and testing.

How long did the initial build take?

My observed run took 44 minutes and used 661 credits. I estimated that at less than $7. Treat that as one measured demo run, not a guaranteed benchmark for every solution.

Does this mean I do not need Power Apps or Power Automate skills anymore?

No. You still need to understand requirements, data, security, automation, UX, testing, and maintainability. The difference is that more of the initial construction can now be delegated to an AI-assisted building experience.

Do I have to be great at prompt engineering?

No. I spent about ten minutes talking through my rough idea with Copilot, then asked it to help produce the prompt I would use for the build. Clear requirements and good judgment mattered more than memorizing a magic prompt format.

Was the first generated version automatically production ready?

I considered the core demo a real, functioning solution rather than a fake mockup, but production responsibility does not disappear. I later spent roughly $20 in credits on additional hardening and testing, and any real deployment still needs appropriate review and validation.

But, if you told me I had to roll out the first version it built... I would have. It worked and was well built, I just spent some time fine tuning it to make sure it wasn't good, it was great.

What should a professional maker try first?

Pick a small business process you already know well. Describe the users, data, routing, automation, and expected outcome, let the tool build a first version, and then inspect the implementation like the professional maker you are.

Key Takeaways

• A roughly 480-word prompt produced the first version of a broad Power Platform solution in 44 minutes using 661 credits in my demo.

• That first build included Dataverse tables and security, a model-driven app, a canvas app, and three Power Automate flows.

• You do not need to invent the perfect prompt alone. I used Copilot to talk through the idea and help write the final build prompt.

• The same underlying business process could then be surfaced through a generative page, a Copilot Studio agent, and a Copilot managed runtime app.

• AI-assisted building does not replace Power Platform expertise. It changes where that expertise provides the most value.

• Professional makers should start practicing a “words first, tweak second” workflow now, while still validating architecture, security, UX, and production readiness.

Ready to build this way?

If you want help getting your team comfortable with AI-assisted Power Platform development, or you want somebody to build alongside you while you figure out where these tools fit, the team at PowerApps911 can help. We do training, mentoring, and implementation across Power Platform, Copilot, Dynamics, Azure, SharePoint, and the surrounding Microsoft ecosystem. The tools are changing quickly. Let’s make sure you are learning how to use them, not watching them go by.