The operations team built a Power Apps app in three weeks to log field visits. It worked so well that management asked to open it to the contractors' 400 technicians, connect it to the ERP and add a portal where customers could check the status of their service. That's when the questions started: who pays licenses for people outside the company, why search can't find older records, and who maintains an app that was put together over a weekend.
Enterprise application development almost always starts with the same question these days: do we build it on a low-code platform like Power Apps, or write it in code, with Angular, Node.js or whatever stack fits? There's no single answer, but there are fairly concrete criteria that tip the scale: who will use the app, how much data it handles, what it has to integrate with and what it costs per user. If what you have is a manual process you want to automate, start with when Power Platform automation is worth it.
What each approach does well
First, drop a common prejudice: low-code isn't development for people who can't program, and custom code isn't automatically the serious option. Each one fits a certain kind of problem better.
A low-code platform like Power Apps performs well when the app is internal, its users already have Microsoft 365 accounts, the data lives in SharePoint, Dataverse or SQL, and the process changes often. You build it fast, change it fast, and the business team can take a real part in the design.
Writing code makes sense when customers, suppliers or the public use the app, when the interface and user experience are part of the product, when data volumes are large or the logic is complex, or when the company needs full control over where it runs, how it scales and who owns the code.
The hard part is the middle: the internal app that slowly starts picking up external users, or the simple form that ends up becoming a system.
Five criteria to decide
1. Who will use the application
This one weighs the most, because it sets the licensing model. If the users are employees with Microsoft 365, a Power Apps app built on standard connectors (SharePoint, Outlook, Teams) may not need extra licenses, unless it runs in a managed environment, where all active usage requires a premium license. If the users are external, things change: Power Apps for internal users is licensed per person, and for customers or suppliers Microsoft offers Power Pages, licensed by capacity (packs of authenticated or anonymous users per website per month). A web application written in code doesn't pay per user, though it does pay for hosting, maintenance and development.
2. How much data, and what kind of queries
Power Apps handles large data sources well as long as queries can be "delegated" to the database. When a formula isn't delegable, the app brings in only the first 500 records by default (you can raise that to a maximum of 10,000) and works on those. Microsoft documents it: if the record you're looking for is number 501, the search won't find it and won't tell the user. You can design around this with Dataverse, views and delegable filters, but it takes discipline. An app with complex reports over hundreds of thousands of records is usually more comfortable with its own backend.
3. What it has to integrate with
Microsoft 365 standard connectors are included. Dataverse, premium connectors (SQL Server, for example) and custom connectors turn the app into a premium app, and every user who runs it needs a license that grants that right. If the app has to talk to an on-premises ERP, an AS/400 or a bank API, the question is whether a connector is enough or whether you're better off with your own integration layer that can later serve several applications.
4. How much it will change, and who maintains it
Low-code works best when the process changes every month and someone on the business side can tweak a form without opening a project. The risk sits at the other end: critical apps built by someone who's no longer around, with no version control and no test environments. Custom code brings its own upkeep too: frameworks that go out of support, dependencies, deployments. We covered that in detail in what happens to custom software after delivery.
5. What it costs over three years, not in the first month
Low-code is cheap to start. The recurring cost grows with every user. Code works the other way around: a bigger upfront investment and a recurring cost less tied to headcount. That's why it pays to compare over three years, using the number of users you actually expect, not the pilot.
Comparison table
| Criterion | Power Apps (low-code) | Code-based development |
|---|---|---|
| Typical users | Employees with Microsoft 365 | Customers, suppliers, the public or large teams |
| Time to first version | Weeks | Weeks to months, depending on scope |
| Licensing | Per user (or by capacity in Power Pages) | No per-user license; hosting and maintenance |
| Data volume | Fine with delegable queries; watch the limits | No platform-imposed limits |
| Interface | Platform templates and controls | Fully custom |
| Who can change it | Business and IT, with governance | Development team |
| Main risk | Ownerless apps and runaway licensing | Maintenance and technical debt |
What's changing in Power Apps licensing
Many companies don't have this on their radar. Microsoft announced that starting February 2027 it will strictly enforce licensing requirements that until now were applied leniently: apps in managed environments, model-driven apps and custom apps used outside the context of a Dynamics 365 license. Users without an appropriate premium license won't be able to open those apps until one is assigned. Microsoft points out the requirement isn't new; what changes is that it will now be enforced.
If you already have apps in Power Apps, download the licensing reports from the Power Platform admin center and check which ones fall into that situation before adding new ones. For reference, the official pricing page lists Power Apps Premium at USD 20 per user per month, paid yearly (US list price). There are also per-app and pay-as-you-go options through an Azure subscription.
The middle path: combining both
You don't always have to pick one. Some patterns that work:
- Your own backend with an API (on Azure, for example) and a Power Apps app for internal use, connected through a custom connector. The customer portal is built in code on top of the same API.
- A Power Apps prototype to validate the process with real users and, if the app grows toward external users or high volumes, a rebuild in code using what you learned.
- Power Automate for approval flows and notifications around a custom-built application.
Whatever the mix, put the decision in writing: what gets built on each platform, who owns it and when it gets reviewed.
Frequently asked questions
Can Power Apps be used for apps that external customers use?
For that, Microsoft offers Power Pages, licensed by user capacity per website per month. Run the numbers with your real user volume and compare them with the cost of your own web application.
Can a Power Apps app be migrated to code later?
There's no automatic conversion, but the process, data and business rules validated in the low-code app save a good part of the analysis for the later build.
If I have Microsoft 365, is Power Apps already included?
Microsoft 365 includes rights to use Power Apps with standard connectors. If the app uses Dataverse, premium or custom connectors, each user needs a premium license.
Before picking a tool, do the math
At Disrupsoft we build custom web and mobile applications with Angular, Node.js and Azure, and we also work with Power Platform, so the conversation starts with the process and with what the app will cost over three years, not with the tool. If you're weighing how to build your next application, let's talk about your custom software development project.
