Project 03 · Original methodology
SDD × Power Platform Framework
Microsoft defines Spec-Driven Development as the recommended methodology for AI-assisted enterprise development. This framework adapts that validated cycle to the Power Platform ecosystem: Canvas Apps, Power Automate, Dataverse, and ALM with pac cli.
// the problem
The structural problem of Power Platform
Power Platform has a structural vibe coding problem. The low barrier to entry means Makers build before specifying. A Maker opens Power Apps Studio and starts dragging controls without defining the data model. A Flow gets built by iterating directly in production because "it's faster that way." Nobody documented which connectors are used or why — until DLP breaks the flow six months later.
SDD (Spec-Driven Development) is the methodology Microsoft recommends for AI-assisted enterprise development. Their official module covers the Specify → Plan → Tasks → Implement cycle for traditional software with GitHub Copilot and VS Code. It does not cover Power Platform. This framework closes that gap.
// the gap
What this framework adds to the Microsoft module
| Dimension | Microsoft SDD Module | This Framework |
|---|---|---|
| AI Toolchain | GitHub Copilot + VS Code | Power Platform CLI (pac) |
| Spec type | Classes, functions, APIs | Canvas Apps, Flows, Dataverse schemas |
| Constitution | Engineering standards | DLP policy + naming + environment strategy |
| Type decision | Language (TS, Python, C#) | Canvas vs. Model-Driven |
| ALM | git + GitHub Actions | pac solution export/import + Solution Checker |
| Testing | Unit tests | Test Studio aligned to EARS criteria |
| CI/CD | GitHub Actions | Power Platform Pipelines |
// the framework
The SDD cycle adapted to Power Platform
Capture business intent before opening Studio. Acceptance criteria in EARS notation. Stakeholder signs off before development begins.
Translate the spec to technical decisions: Dataverse schema, app type, Flow architecture, connectors, security model. Verify every connector against DLP before committing.
Decompose the plan into atomic tasks. One component = one task. Each task references the spec section that originated it and has a clear verification criterion.
Build within spec and plan boundaries. Test Studio tests written against EARS criteria. Constitution check before any PR.
// EARS notation
Acceptance criteria in language business and engineering both understand
EARS (Easy Approach to Requirements Syntax) makes acceptance criteria unambiguous and testable. Applied to Power Platform, each criterion maps directly to a test in Test Studio.
| Pattern | When to use | Power Platform example |
|---|---|---|
| WHEN...SHALL | User actions, Flow triggers | WHEN user submits form THE app SHALL validate RUT before saving. |
| IF...THEN SHALL | Error handling, boundary conditions | IF Outlook connector fails THEN THE flow SHALL retry 3 times and notify admin. |
| WHILE...SHALL | App or record states | WHILE request is In Review THE form SHALL disable all fields for the requestor. |
| THE [sys] SHALL | Always-true rules → constitution | THE solution SHALL never store credentials in flow variables. |
| WHERE...SHALL | Role-conditional functionality | WHERE user has Approver role THE app SHALL show the decision history panel. |
// honest questions
The questions someone always asks
No. Waterfall locks the spec at the start and penalizes change. SDD versions the spec alongside the code and updates it when requirements change. When the business changes its mind — and it always does — you update spec.md, revise the plan, and adjust from a place of clear intent, not accumulated technical debt.
Copilot for Power Apps generates apps the same way vibe coding generates code: fast for demos, fragile for production. Without a spec that defines the data model, security roles, and edge cases, Copilot produces the exact problem SDD solves. The spec is the prompt that makes Copilot generate something actually useful.
A well-written spec takes 2–4 hours. A security bug from missing column-level security, or a Flow running in infinite loop from a missing idempotency condition, takes days. The right question isn't 'do we have time for SDD' but 'do we have time to not have it'.
The SDD cycle is validated by Microsoft for enterprise development. Their official module covers traditional software — not Power Platform. This framework takes that validated methodology and adapts it to the Power Platform ecosystem, where DLP constraints, connector governance, delegation limits, and pac cli ALM make the methodology non-trivial to apply without adaptation. The methodology is Microsoft's. The Power Platform adaptation is the contribution of this framework.
Full framework — by email
The full framework with annotated templates and examples is available by email. Leave your name and address and I'll send it over.
Thanks — it'll arrive in a few minutes.