Claude Didn't Build Our Power Platform App in a Day. My Requirements Engineering Did.

TL;DR

• We sized a Power Platform rebuild of a legacy desktop system at roughly 500 person-days. Then I fed my presales requirements engineering and the legacy source code to Claude Fable 5 and asked it to build instead of describe.
• The result was a working application in about a day: declarative YAML source under git, a nine-table Dataverse model with soft-delete and audit protocol, business rules reconstructed from 25-year-old PowerBuilder code.
• I hit exactly two walls: cloud flows and Power BI. Both were integration gaps, not reasoning gaps. Two MCP servers later, flows and a four-page report were built and deployed entirely through APIs, without Power BI Desktop.
• A strict verification loop (publish-and-verify, control totals to the cent, automated screenshot QA) caught three bugs that would otherwise have shipped. “It runs” still isn’t “it’s production-grade.”
• The uncomfortable takeaway: if a 500-day estimate is mostly typing, it’s the requirements engineering (not the keyboard time) that clients are really paying for. That part got more important, not less.

Introduction

If you price software projects for a living (or approve the invoices for them), the past year has probably left you with a quiet, nagging question: how much of what we charge for is thinking, and how much is typing?

I didn’t set out to answer that question. I set out to write a routine offer. But somewhere between the effort estimate and the proposal document, I ran an experiment that I think is worth sharing in detail: including the parts that worked embarrassingly well, the parts that didn’t work at all, and the engineering discipline that made the difference between a demo and something I’d actually show a client. This is a field report, not a manifesto. Draw your own conclusions; I’m still drawing mine.

The 500-day starting point

A few weeks ago a client asked us a straightforward question: what would it cost to build a Power Platform application to replace one of their aging internal systems?

This is bread-and-butter work for a consultancy like ours, so I did what we always do. I ran the presales requirements engineering: sat with the requirements, mapped the workflows, worked out who needed what.

The client handed over the source code of the legacy application, which carried a good chunk of the new requirements inside its logic.

The plan from there was textbook: turn all of that into specification documents, size the effort, and come back with an offer.

“Just to see”

Claude Fable 5 had just become available for free. I’ve learned to be skeptical of model demos, so I wanted to try it on something real and messy rather than a tutorial. Instead of opening a blank spec document, I pointed it at what I already had (the requirements I’d gathered and the legacy source) and asked it to build the thing rather than describe it.

I honestly didn’t expect much. I’ve been burned before by output that looks impressive for ten minutes and falls apart the moment you ask it to do the boring 90%.

This time it held. It built the application: not a mock-up, the working thing.

What “built it” actually means

Because “the AI built an app” can mean anything from a to-do list to a screenshot, here’s what was actually on the table.

The legacy system is a two-tier PowerBuilder desktop application from the late nineties: the business logic buried in one sprawling procedural source file, no audit trail, no API, documentation long out of sync with reality. Claude read that source and reconstructed rules nobody had written down in twenty years: region-specific premium logic (pro-rata vs. short-rate calculation, monthly vs. annual billing schedules, mid-term adjustment proration), cancellation-refund thresholds per product line, policy-number schemes, and over a dozen endorsement types with subtly different accounting behavior. That reconstruction went into the specification first: every rule traceable back to a line of legacy code, every ambiguity flagged as an explicit open point instead of a silent guess.

The new application isn’t clicked together in a low-code designer either. It exists as declarative source code (one YAML file per screen) compiled and pushed through a CLI/MCP toolchain, versioned in git like any other codebase. Underneath sits a Dataverse model of nine custom tables with proper lookups, a soft-delete pattern (nothing is ever physically deleted), and an append-only protocol table for auditability: the thing the legacy system never had.

‍

The two walls, from an engineer’s chair

I hit exactly two impediments, and as an engineer I found both reassuring rather than alarming, because neither was about reasoning.

The model couldn’t create Power Platform cloud flows directly, and it couldn’t build the Power BI reporting layer. Historically that’s the point where you shrug and say “fine, a person finishes this part.” Instead I installed MCP servers for both (one that can plan, author and validate cloud flow definitions, and one for the Power BI stack) and handed the work back. Once it could actually reach into those surfaces, the gaps closed. Flows built: notifications, a daily deadline digest, document generation with template merge to PDF. Reports built (and this part is worth dwelling on, because it was done entirely headless, on a Mac, without Power BI Desktop ever being installed): the semantic model authored as TMDL, the four-page report as PBIR JSON, both generated by scripts, validated with an offline validator, and deployed straight through the Fabric REST APIs.

‍

I want to be precise about what that tells us, because it’s easy to over-read. The blockers weren’t intelligence limits. They were integration limits: the model simply couldn’t touch those tools until I wired them up. That’s a plumbing problem, and plumbing gets solved. It’s a very different kind of ceiling than “the model can’t reason about the domain,” and I don’t think we should confuse the two.

Why it actually worked, and where I’m still cautious

The build didn’t collapse 500 days into one because the tool is magic. It collapsed because most of the genuinely hard part was already done before I wrote a single prompt.

I’d done the requirements engineering. I understood the workflows. I had legacy code that encoded the real business logic, and I could feed it in as ground truth instead of guessing. And we’d checked in advance that all the data already lived in the customer’s Dataverse: no hidden migration project, no integration archaeology waiting to eat the timeline. The thinking was done. What remained was construction, and construction is what these tools have quietly gotten very good at. That’s the claim in the title, unpacked: Claude did the typing. The requirements engineering did the building.

The other reason it held: I never let “it compiles” count as done. Every release ran the same loop: compile clean, publish through the API with version evidence, then verify in the published runtime rather than the editor preview, because the two genuinely differ. The reporting layer had its own gate: before any chart shipped, DAX queries against the published model had to reproduce the legacy system’s control totals to the cent (row counts and sums, per region). Visual QA ran as automated browser screenshots of the live report, iterated until it was right.

That loop earned its keep. It caught a type-coercion bug that compiled cleanly but would have silently disabled a feature on the next save. It caught a current visual type that renders fine in the designer but comes up blank in the published service. It caught a deployment API that quietly requires a full data purge on schema changes. The model found and fixed all three, but only because the verification loop existed to surface them. Without it, I’d have shipped all three bugs and called it a great demo.

That’s also where my engineering instincts start twitching, and I’d rather say it out loud than pretend otherwise. “It runs” is not “it’s production-grade.” I have not read every line the way I’d read a junior’s PR. I don’t yet know how it behaves at the edges, how maintainable it is in six months, or how cleanly the next person will be able to reason about it. A rollout still needs hardening, security review, governance, and someone genuinely accountable when it breaks at 2am. None of that disappeared. The application is ready after about a day; deploying it into the customer’s environment will take under ten, mostly because the data is already sitting where it needs to be. Whether it stays healthy is a separate question, and it’s the one I’d want answered before I’d stake our name on it.

A note on token cost

People ask what the compute cost of a build like this is, expecting it to be the new bottleneck. It isn’t. The generation itself (the model’s “typing”) ran to a few million output tokens; the rest is cheap cached context replayed on every turn. Translated into money, the build cost somewhere in the low tens to low hundreds of euros. Set that against a 500-person-day estimate (several hundred thousand euros at consultancy rates), and you’re looking at three to four orders of magnitude. That doesn’t undercut the argument of this piece; it sharpens it. If the machine’s typing is essentially free, then whatever you’re still paying a consultancy for is very obviously not the typing. It’s the requirements engineering: understanding the problem well enough that the cheap part can run at all.

Conclusion: the center of gravity is shifting

I don’t have a tidy commercial answer yet, and I’m suspicious of anyone who claims they do.

What I’m fairly confident of is that the center of gravity is shifting. The value is moving off the keyboard (off the raw act of producing code) and toward the things that made this build possible in the first place: understanding the problem, knowing the data, reading the legacy system, and framing requirements clearly enough that a machine can execute them without inventing a business that doesn’t exist. That’s the part clients actually needed us for all along. It got more important, not less.

The flip side is uncomfortable and worth naming. If a 500-day estimate is mostly 490 days of typing, that estimate is starting to describe a cost we can no longer honestly defend. I’d rather work that out in my own sandbox than have a client work it out for me.

So here’s my recommendation, and it’s the same one I followed: don’t wait for a slide deck to tell you what these tools change. Take one real project from your own pipeline (one where the requirements work is genuinely done) and run the experiment yourself, with a verification loop you trust. Not a toy, not a tutorial. You’ll learn more in a day than in a quarter of vendor webinars. And if the result unsettles your pricing model, better to find out in your sandbox than in a client meeting.

I ran this experiment out of curiosity, not conviction. I came away with more questions than answers, which is usually a sign the thing is worth paying attention to.

It’s time to find out what your estimates are really made of.

We at &amp are working through exactly these questions right now: where AI-assisted delivery genuinely collapses effort, where it quietly creates risk, and what that means for how software projects should be scoped, priced and governed. We’d rather have that conversation openly than pretend the ground isn’t moving.

If this post sparked ideas (or objections), I’d genuinely like to hear them. Share your experience, challenge the numbers, tell me where your experiments landed differently. And if you’re facing a legacy system of your own and wondering what a rebuild would really take today, reach out. Whether it’s a conversation about the approach, a joint proof of concept, or hands-on support with Power Platform and AI-assisted delivery, that’s precisely the work we love doing. Get in touch with us at &amp, or connect with me directly. Let’s find out together.

‍

‍