When to Build on Power Apps vs Commission Custom Software
Low-code is genuinely faster — until per-user licensing, delegation limits or a public-facing requirement makes it the wrong tool. Here is where the line actually sits.
The question behind the question
Teams rarely ask 'low-code or custom' in the abstract. They ask it because an internal process is being run on spreadsheets and email, and someone needs it fixed this quarter. Power Apps is often the right answer to that. It stops being the right answer at a fairly predictable set of boundaries.
Where Power Apps wins clearly
If the workload matches this profile, low-code will beat custom development on time and cost, usually by a wide margin.
- Internal users with existing Microsoft 365 identities — no external or anonymous access
- Form-and-workflow shaped problems: requests, approvals, inspections, checklists, asset registers
- Data volumes in the thousands to low hundreds of thousands of rows
- Tight coupling to SharePoint, Outlook, Teams, Excel or Dynamics 365
- Requirements that will keep changing, where a citizen developer can adjust a screen without a release cycle
The licensing maths nobody does upfront
Premium connectors and Dataverse require per-user or per-app licences on top of Microsoft 365. For twenty back-office users that is trivial. For twelve hundred field staff, the three-year licence bill can exceed the cost of building and hosting a custom application outright.
Do the arithmetic early: users multiplied by monthly licence multiplied by thirty-six months, against a realistic build plus hosting plus maintenance estimate. Very often that single calculation decides the question.
Technical ceilings you will hit
These are not theoretical. They are the recurring reasons Power Apps projects get rewritten.
- Delegation limits — non-delegable queries silently operate on a truncated record set, producing wrong totals
- API request entitlements per user per day, which batch-heavy automations exhaust quickly
- Limited control over the UI: pixel-accurate branded interfaces and complex interactions fight the platform
- Long-running or high-volume Power Automate flows become slow and hard to debug compared with real code
- Automated testing and source control are workable with pipelines, but never as clean as a conventional codebase
Signals it should be custom from day one
Some requirements rule low-code out before you start rather than after.
- Customer-facing or public-facing screens, or any anonymous access at scale
- The application is the product you sell, or a differentiator competitors should not be able to copy quickly
- Sub-second response requirements, heavy computation, or real-time streaming data
- Complex domain logic — pricing engines, scheduling optimisation, regulatory calculation
- Data residency, encryption or audit requirements the platform cannot satisfy
- Millions of rows with demanding reporting and integration needs
The hybrid pattern that usually wins
The strongest architectures are not either-or. Keep the system of record — pricing, transactions, core domain logic — in a custom service with a clean API, and use Power Apps for the surrounding internal tooling: approvals, exception handling, data correction, field capture.
That gives business teams the speed of low-code where change is constant, while the parts that must be correct, fast and defensible stay under engineering control.
Governance if you go low-code
Ungoverned Power Platform estates sprawl. Set up environments for dev, test and production, apply data loss prevention policies, use solutions and pipelines for deployment, and keep an owned inventory of apps with a named owner for each. Orphaned apps built by someone who has left are the most common source of low-code technical debt.
Where EzTechify fits
We build on Power Apps, Power Automate and Dataverse where it is the right tool, build custom platforms where it is not, and design the hybrid boundary between them — including migration paths when a low-code app has outgrown the platform.