Power Platform vs Custom .NET: A Decision Framework with 9 Real Scenarios

Almost every IT leader we work with eventually asks the same question. They have a new application to build, a process to digitise, or a legacy tool to replace, and someone — usually a developer, an architect or a Microsoft account rep — has thrown an opinion into the room. "We should just build this in .NET." "Why not do it in Power Apps in two weeks?" "Citizen developers can handle this." "We need real code."

The frustrating thing is that they're often all partly right. Power Platform and custom .NET are not competitors so much as different tools for different shapes of problem. Choose well and you ship faster, spend less and end up with software your team can actually maintain. Choose badly and you either build a brittle low-code maze that nobody understands, or you write 18 months of bespoke .NET to solve a problem that two consultants and a canvas app would have wrapped up in six weeks.

This post is the framework we use at Skywinds when clients ask us to make that call. We'll lay out what each platform genuinely does best, the seven decision axes we weigh, and then walk through nine real-world scenarios — drawn from the kind of work we see every week — showing which way each one should go and why.

Why the question is poorly framed

Before the framework, a quick reset. "Power Platform vs custom .NET" is rarely a binary choice. The most successful modern Microsoft solutions blend the two. A Power App calls an Azure Function written in .NET. A Power Automate flow orchestrates a process whose heavy lifting happens in an ASP.NET Core API. Microsoft's own direction reinforces this: the recent general availability of Power Apps "code apps" lets developers write React or Vue applications and deploy them to Power Platform, gaining Dataverse, governance and enterprise-grade ALM without giving up the IDE.

So the real question is not "which platform?" It's: "for this specific component of this solution, where on the low-code / pro-code spectrum does the smart investment sit?" That reframe matters because once you stop looking for one winner, you can start matching the right tool to each part of the system.

What Power Platform is genuinely best at

When you strip away the marketing, Power Platform earns its place when four things are true.

The audience is internal or close to your organisation. Power Apps shines for employees, partners and authenticated users. The licensing model, the governance story and the typical UX patterns are all built around that. Public, anonymous, high-traffic consumer audiences are not where Power Apps lives.

The business value comes from speed and integration, not novel UX. If the win is "we replaced a six-tab spreadsheet, automated three emails and gave management a dashboard," Power Platform's connector ecosystem (1,000+ connectors out of the box), Dataverse, Power Automate and Power BI compress weeks of plumbing into hours. You don't need to write authentication, role-based security, audit logging or a deployment pipeline — you get them.

The data model fits Dataverse or a Microsoft 365 source. SharePoint lists, Excel files, Dataverse tables, SQL — these are home turf. Connecting to your own custom-built database with idiosyncratic relationships is possible but starts to erode the benefits.

The team is a mix of consultants, business analysts and a few developers. This is the "fusion team" pattern Microsoft has been pushing for years, and in practice it's where Power Platform delivers its best ROI. Functional consultants model the process, makers build the apps, and a developer drops in C# plugins or Power Automate custom connectors where the low-code surface runs out.

What custom .NET is genuinely best at

.NET — and specifically ASP.NET Core and the broader Azure-native stack — earns the call when the application has any of these characteristics.

The audience is the public or a high-scale external user base. B2C web apps, partner portals serving thousands of organisations, public APIs, mobile apps with millions of installs. The unit economics of Power Apps licensing simply don't work at this scale, and the platform's architectural assumptions aren't designed for it either.

The business logic is genuinely complex or performance-critical. Domain models with deep invariants, multi-stage state machines, sub-100ms response budgets, real-time computation, machine learning inference at scale — these live more comfortably in code, with a real type system, full debugging, and a test pyramid you control.

Long-term ownership and engineering control matter more than time-to-market. You want everything in source control, peer-reviewed, built by a CI/CD pipeline, with infrastructure as code, observability you choose, and zero platform lock-in. .NET on Azure gives you that without compromise.

You need to do something the platform simply can't. Power Platform has surface area limits — certain UI patterns, certain integration shapes, certain performance characteristics. Hitting those limits is fine; pretending they don't exist is how projects fail.

The decision framework: seven axes

When a new project lands on our desk, we walk it through seven questions. The answers usually point clearly in one direction.

1. Audience. Internal employees, named partners, or anonymous public users? Power Platform leans internal; .NET handles all three.

2. Scale and concurrency. Tens of users, hundreds, thousands, hundreds of thousands? Most internal apps live in the first two tiers, where Power Platform thrives.

3. Complexity of business logic. Forms, lists, approvals, basic calculations — low-code territory. Multi-step state machines, complex pricing engines, regulated calculations — pro-code territory.

4. Integration depth. A few Microsoft 365 or Dataverse connections — Power Platform. Many heterogeneous systems with bespoke protocols, message queues and event streams — .NET (or hybrid).

5. Time-to-market pressure. "We need this in six weeks" usually tilts to Power Platform. "We're funding a strategic capability for the next five years" usually tilts to .NET.

6. Total cost of ownership. Power Apps Premium runs $20 per user per month ($12 at 2,000+ licences), which is excellent for ten or a hundred internal users and prohibitive for a million customers. .NET has near-zero per-user cost but real engineering cost. Do the math on three-year TCO, including maintenance.

7. Governance, ALM and team skills. Do you have makers who can own a low-code estate responsibly? Do you have .NET engineers and a real DevOps pipeline? The platform you can operate well usually beats the platform that's theoretically better.

Now the scenarios.

Scenario 1: Internal purchase-approval workflow, 200 staff, two approval levels

Recommendation: Power Platform.

A canvas Power App for submitting requests, Dataverse for the data, Power Automate for the two-tier approval routing, and Power BI for the finance team's monthly view. This is the canonical "spreadsheet replacement" use case Power Platform was built for. With a senior consultant, you're looking at four to six weeks end to end, including UAT.

The trap to avoid is trying to "make it generic" so it handles every approval flow in the company. Build it for purchase approvals. Then, if it lands well, build the next one — leave is its own model. Resist the urge to engineer.

Scenario 2: Customer-facing B2C storefront, 100,000 visitors per month

Recommendation: Custom .NET.

ASP.NET Core on Azure App Service or Azure Container Apps, served behind Azure Front Door. The audience is anonymous, the SEO and performance requirements are non-negotiable, and the UX is a competitive surface — not a back-office form. Power Pages (the former Power Apps Portals) can host external users, but for a marketing-led commerce experience at this scale you want full control of the framework, the rendering strategy and the build pipeline.

The temptation here is the reverse of Scenario 1: a leader who's seen a slick internal Power App may underestimate how different a public storefront is. Different game, different tools.

Scenario 3: Field-service inspection app for 50 engineers, offline-capable

Recommendation: Power Platform (canvas Power Apps).

Engineers in the field need to open a job, capture inspection answers, attach photos, get a signature and sync when they're back on coverage. Power Apps canvas apps handle this beautifully — offline data, camera and GPS, signed-in Azure AD identity, and a direct line into Dataverse where the dispatch system already lives. The 2026 mobile and offline improvements have made this story stronger, not weaker.

We've delivered apps in this shape in eight to ten weeks, and they keep working when the engineer rolls into a basement with no signal. Building the same thing in custom Xamarin or .NET MAUI is technically possible and roughly three times the effort.

Scenario 4: Replacing a legacy WinForms accounting tool used by 300 finance users

Recommendation: Hybrid — Power Apps front-end, .NET API for the calc engine.

This is the most common nuance scenario we see. The 300 users want a modern, browser-based experience with familiar entry forms — exactly what a model-driven Power App gives you. But the underlying calculations (period close, multi-currency revaluation, deferred revenue) carry decades of business rules that nobody wants to re-implement in low-code expressions.

Build the front-end and workflow in Power Apps and Power Automate. Encapsulate the calc engine as an ASP.NET Core Web API hosted on Azure App Service, called from Power Apps via a custom connector. You get modern UX in months, you don't rewrite the algorithm, and you preserve the auditability your finance team needs. Pure low-code would buckle under the rule complexity. Pure custom would burn a year on UI work the platform gives you for free.

Scenario 5: Multi-tenant SaaS product sold to 5,000 customers worldwide

Recommendation: Custom .NET.

This is unambiguously pro-code. You need multi-tenant isolation, your own pricing model, per-customer branding, hard performance SLAs and a unit economics model based on Azure consumption, not Power Apps licences. ASP.NET Core, Entity Framework, Azure SQL, Azure Service Bus, Application Insights, Bicep or Terraform for infrastructure. Authentication via Microsoft Entra External ID or Auth0. You're building a product, not a process — and products belong on a platform you fully control.

The version of this we see going wrong is when someone proposes building it on Dataverse "because it'll be faster." It might be for the first sprint. By the time you've worked around the multi-tenancy model, the licensing per external user, the Dataverse storage costs at scale and the absence of true engineering control, you've burned more than you saved. Don't.

Scenario 6: Extending Dynamics 365 Sales with custom lead scoring and routing

Recommendation: Power Platform — with a small .NET assist.

Lead scoring lives close to the data, and the data lives in Dataverse. Build the routing as Power Automate cloud flows triggered by lead create/update events. Build the scoring model itself in a way that's easy to evolve: either as a Power Automate flow with branching logic for simple rules, or as an Azure Function (C# or Python) called from the flow if you're doing real machine learning. Surface the result back on the lead form as a calculated column or a custom PCF control.

This pattern — Power Platform orchestrating, .NET handling the smart bit — is the heart of the fusion-team model. The functional consultants who know the sales process own the flows; the developer owns the function. Neither gets in the other's way, and the solution sits inside the Dataverse solution model so ALM is a single deployment.

Scenario 7: High-throughput public API for partner integrations, 1,000+ requests per second

Recommendation: Custom .NET.

ASP.NET Core minimal APIs, hosted on Azure Container Apps or AKS, fronted by Azure API Management for throttling, contracts, monetisation and observability. This is exactly the territory the modern Microsoft stack was rebuilt for. Power Platform offers custom connectors and Dataverse Web API endpoints, but neither is designed to be the public API for thousands of integrators — you'd be fighting the platform at every turn.

If parts of the data this API exposes do live in Dataverse, query Dataverse from the .NET service and project a clean, versioned contract outward. Don't expose Dataverse directly. Public APIs deserve careful design and total control.

Scenario 8: Internal HR FAQ chatbot

Recommendation: Power Platform (Copilot Studio).

Copilot Studio (the former Power Virtual Agents) is exactly the right tool here. It handles intent classification, conversation flow, escalation to a human and integration with Teams and SharePoint, all in a low-code surface that an HR business partner can co-own. The 2026 AI updates have made it materially better at grounding answers in your own document set.

Building the same thing in custom .NET means you're now operating an LLM gateway, a vector store, a Teams bot service, an authentication flow and a feedback pipeline. That's a fine investment if you're building a strategic AI product. For "answer HR policy questions in Teams," it's wildly disproportionate.

Scenario 9: Heavily regulated banking calculator with audit, complex math and certification needs

Recommendation: Custom .NET.

A treasury calculation engine that has to be audited line by line, deployed under SOX-style controls, with a deterministic, peer-reviewable code path. Even though the users could be served by a Power App front-end (and sometimes that's still the right call for the data-entry layer), the calculation core must live in a place where every change is reviewed, signed, traced and reproducible.

That's what version-controlled C# with a real test suite is for. Use Power Apps for the form. Use ASP.NET Core for the engine. Use Application Insights and Azure Monitor for the audit trail. This is precisely the kind of system where Power Platform's "platform owns the runtime" model fights against the compliance requirement, while custom .NET shines.

The fusion-team pattern is the real answer

If you've spotted a theme across the scenarios, it's that the most resilient designs aren't pure plays. They use Power Platform where business agility and integration speed compound, and custom .NET where complexity, scale or control compound. The architecture diagrams we draw most often look like this: a Power App or model-driven UI for the user experience, Power Automate for orchestration and process, Dataverse for governed data, and one or more Azure Functions or ASP.NET Core APIs for the parts that genuinely need engineering depth.

This is also the direction Microsoft itself keeps pointing. Power Apps code apps now let developers ship React applications onto Power Platform with full governance. Dataverse exposes itself cleanly to .NET. Azure Functions is a first-class extension point for Power Automate. The platforms are converging, and the smart play is to learn both.

Three anti-patterns we keep seeing

A few traps that come up often enough to be worth flagging:

The strategic Power App. Built by an enthusiastic department, it grows to 200 users, six interconnected sub-apps, a maze of cloud flows and a creator who's now left the company. Nobody can confidently change anything. Fix: treat any Power App with more than ~50 users or two integrations as a real product. Solution-aware ALM, environment strategy, a named owner, a backlog.

The "we'll just code it" reflex. A 12-week .NET project for a process that two Power Apps and a SharePoint list would have solved in three. Fix: before you write a line of code, ask whether the user-facing surface is genuinely novel. If it's forms, lists, approvals and reports — even with complex logic underneath — start with the platform and add code where it earns its place.

The hidden licensing surprise. Power Apps Premium at $20/user/month is fantastic value for an internal app with 80 active users. For 800 external customers it isn't. The Power Apps per-app SKU, useful for tightly scoped scenarios, was withdrawn from new Enterprise customers in January 2026 — so the per-user model is now the dominant path. Fix: model three-year licensing alongside engineering effort. Sometimes the cheaper-to-build option is the more expensive option to run.

How we approach the decision at Skywinds

When a client brings us a new build, we run a short discovery — usually one to two weeks — that does three things. We map the audience, scale and integration profile of the proposed system. We sketch a candidate architecture on each side of the line: what would a Power Platform-led design look like, and what would a .NET-led design look like? Then we compare them on time-to-value, three-year TCO, governance posture and risk.

Nine times out of ten the right answer is obvious once both options are on the table. The remaining one in ten is the interesting case — and it's almost always a hybrid, with a clear line of responsibility between the platform-led parts and the engineered parts.

If you're staring at a project and not sure which way to go, that's the call we're happy to help you make. Get in touch and we'll walk through it with you — no commitment, just a clear answer.