Custom internal web app vs. low-code (Power Apps and similar): when each fits

What low-code is good at

Low-code platforms let people build apps by assembling screens, forms and workflows visually, with formulas and connectors in place of most hand-written code. Microsoft Power Apps (with Power Automate for workflows) is the one many mid-sized companies already have access to through Microsoft 365. Others, such as Retool, OutSystems, Mendix and Appian, have their own strengths, hosting options and licensing models.

They're at their best when the app is mostly data entry and review, the users are a known group inside the company, and the data sits in something the platform handles natively, such as a SharePoint list or the platform's own database. A departmental request tracker, an equipment checkout log or a simple approval form can be live quickly, often built by someone close to the process. Our guide to replacing shared-drive document approvals looks at where document approvals sit on that line.

Low-code and custom side by side

Check 1: how licensing scales with users

Low-code pricing is usually tied to people: per user, per app or per use. That works well for a small team and can change the economics when the app spreads to a whole plant, a sales force or occasional users who open it twice a month. Custom apps have the opposite shape: most of the cost is up front, and adding users mostly doesn't change it.

• What's included vs. premium. With Power Apps, the limited rights included in some Microsoft 365 plans are meant for Microsoft 365 data and standard connectors such as SharePoint and Outlook. Premium connectors such as SQL Server, custom connectors, the on-premises data gateway and Dataverse need premium licensing for every user of the app. Microsoft revises these terms periodically, so confirm the current rules for your plan.
• Who needs a license. Every person who uses the app, not only the people who build it, usually needs appropriate licensing. Count occasional and future users, not just today's pilot group.
• Storage and capacity. Some platforms license database storage, API calls or workflow runs separately. Ask what happens when the app's data or activity grows.
• Renewals. Licensing is a recurring cost the business will see every year. Price it over several years alongside a custom build.

Check 2: where the data lives

An app is only as trustworthy as the place its data is kept. Ask where the records will physically sit, who can reach them outside the app, and how they're backed up.

• Lists are not databases. A SharePoint list is convenient but isn't designed for large volumes, relational data or heavy reporting. Power Apps also has delegation limits: queries it can't pass to the data source only work on a limited number of rows (500 by default, adjustable up to 2,000), which can make results quietly incomplete as a list grows.
• The platform's own database. Options such as Dataverse behave more like a real database, but they sit in the vendor's cloud under the vendor's licensing, and reporting on them from other tools goes through the platform.
• On-premises data. Reaching SQL Server or Oracle in your data center typically needs a gateway: software you install on a server, keep patched and keep running. It's part of the app even though it isn't in the app.
• Audit and retention. If the process needs an audit trail of who changed what, or records kept for a set period, confirm how the platform does that before you build, not after an auditor asks.

Check 3: who maintains it

Many low-code apps are built by one capable person in a department. That's a strength while they're there and a risk when they move on, because the logic often lives in formulas and flows that nobody else has read. Settle ownership before the app goes live:

A custom app answers these with source control, automated tests, a deployment pipeline and a handover package. Our software handover checklist lists what that package should contain, whoever builds the app.

Check 4: what it can connect to

Low-code platforms are strongest when every system involved has a ready-made connector. The harder cases are the ones mid-sized companies tend to have: an ERP with a limited API, a line-of-business database, a plant-floor system or an older app with no API at all.

• Connector coverage. List every system the app must read from or write to, and check each against the platform's connectors, including whether the connector is standard or premium.
• Volume and speed. Connectors often have throttling limits and are designed for moderate volumes. Bulk imports, nightly syncs of large tables or near-real-time data can hit those limits.
• Complex writes. Updating several records across systems in one transaction, with rollback if a step fails, is hard to do reliably in visual flows.
• Security review. Connectors often run under a user's or a shared account's permissions. Check that the resulting access matches least privilege, as described in securing internal apps with SSO and least privilege.

If the app's main job is connecting systems, that's usually a sign it wants to be custom. Our guide to integrating two business systems when one vendor's API is poor covers doing that reliably.

Signs a low-code app has outgrown the platform

• Formulas and flows have become long enough that only one person dares to change them.
• Users report missing records, slow screens or timeouts as the data grows.
• Workarounds appear: exports to Excel, duplicate lists, or a second app to cover what the first can't do.
• Licensing costs have grown with adoption to the point where finance is asking about them.
• The process now needs external users, a mobile app with offline use, or integration the connectors can't provide.

None of these mean the original choice was wrong. A low-code app that proved a process is valuable is a good starting point for a custom build: the screens, fields and rules are already known. Treat it the way you would a department spreadsheet or Access database: inventory what it actually does, then move the data with a repeatable, reconciled migration.

Using both

The choice isn't all-or-nothing. A few combinations work well:

• Prototype in low-code, build custom. Use a quick low-code version to confirm the process and the fields, then build the lasting version once the requirements are proven.
• Custom core, low-code edges. Put the data and business rules in a custom app with a proper API, and let departments build simple forms or approval flows against that API.
• Low-code for the simple, custom for the critical. Keep departmental trackers in the platform, and build the handful of apps that carry key processes, many users or sensitive data as custom apps.

Making the call

Our experience includes full-stack web applications in React, Next.js, TypeScript and Node.js, database design and optimization on SQL Server, PostgreSQL and MySQL, and OAuth and OIDC sign-in. Projects are senior-led, quoted at a fixed price against a written scope, and you own the code. See web application development for what we build.

Sources

• Licensing overview for Microsoft Power Platform and Power Apps licensing FAQs (Microsoft)
• Understand delegation in a canvas app (Microsoft)
• Data policies (Microsoft)