IT leaders hear this pitch at least once a quarter. A manager from operations or finance turns up asking for a small internal app, and it’s always framed as a quick job that’ll only take a couple of days and little investment. These requests have multiplied over the past few years, and Gartner’s forecast backs that up, having predicted that by 2026, 80% of low-code platform users would come from outside formal IT departments, compared to 60% in 2021.
Building more apps isn’t the problem. The problem is that most organizations don’t have a decent filter for deciding which apps deserve the budget and which ones will just quietly drain money for months after launch. A Power App that actually pays for itself and one that turns into a maintenance headache look almost identical at the request stage, so telling them apart before committing resources is what matters.
Key Takeaways
- Many low-code app requests lack proper filtering, leading to wasted resources and maintenance headaches.
- Focus on how many people interact with the proposed process to assess app viability; fewer than five usually signals a no-build.
- Check if relevant data already exists in systems like Dataverse or SQL to avoid costly integrations.
- Consider ongoing costs after go-live, including licensing and user fees, before approving a build.
- Not every issue requires an app; sometimes, buying existing software or fixing the process is a better solution.
Table of contents
Start with How Many People Touch the Process
This is the simplest filter, and it catches more bad ideas than anything else you could apply. Count how many people actually interact with the process the proposed app will replace or improve. If the answer is fewer than five, the app probably won’t justify the effort it’ll take to build. A spreadsheet shared between three people isn’t broken enough to warrant a custom build, even if it looks terrible and the whole team complains about it every Monday.
Where the case gets much stronger is when a process cuts across teams. If data moves between departments, gets re-keyed into different systems, or depends on a particular person remembering to send a follow-up email at the right time, a well-scoped Power App can cut out real inefficiency. More handoffs between teams will generally mean more value from automating those transitions.
Check Whether the Data Already Lives Somewhere Useful
A Power App that plugs into data your organisation already controls in Dataverse, SharePoint, or an existing SQL database will be far cheaper and faster to build than one that needs new integrations from scratch. If the data currently sits in disconnected spreadsheets, or worse, only exists inside people’s heads, then you’re not building an app. You’re building a data model first and then putting an app on top of it, and that second project has a completely different price tag and timeline.
Ask the person requesting the app where the data comes from today and where it needs to end up. If they can’t give a clear answer for the investment, the app isn’t ready to be built yet, but that doesn’t make it a bad idea. It just means the groundwork hasn’t been done. Skip that step and the organization ends up with an app that breaks the moment a colleague renames a column in a spreadsheet that turned out to be load-bearing, one that nobody even realized was connected to anything else.
Don’t Ignore What the Investment Costs After Go-Live
Build cost is the number most people fixate on, and it’s often the least important one over the long run. Since Microsoft retired the Power Apps per app plan at the start of 2026, the entry-level licensing route has disappeared for new customers. What’s left is either Power Apps Premium at around £15 per user per month on an annual commitment, or a pay-as-you-go meter through Azure at £7.60 per active user per app per month. Apps that use AI Builder features will also rack up consumption charges through Copilot Credits, which are metered and billed separately on top of the base licence.
That assumption many organisations carried for years, that an internal app would just be covered by licenses they already owned, doesn’t hold true in most cases anymore. Before approving a build, pin down the per-user cost, the expected number of users in year one and year two, and whether the app will trigger premium connector charges. If the team can’t answer those questions with actual numbers, the business case hasn’t been properly written yet.
When the Build Investment Outgrows Low-Code
Some apps pass every test above and still turn out to be bigger than they looked on paper. They need to pull data from a legacy system, respect role-based permissions that already exist on another platform, or survive the person who requested them moving to a different team entirely. Once you hit that point, Power Apps development stops being a low-code exercise and becomes a proper project with a data model, integration work, and clear accountability for what happens after go-live. Catching that early can save the organization far more than any licensing comparison would.
Some apps genuinely need professional development support from day one, and pretending otherwise doesn’t reduce the cost. It just delays it while risk quietly builds underneath.
When the Right Answer Is to Build Nothing
Not every process problem needs an app built around it. Sometimes the fix is buying software that already exists and does the job better than anything a team could build internally within a reasonable timeframe. If a commercial product covers 80% of the requirement and costs less per year than the licensing and support burden of a custom build, the numbers make the decision pretty obvious.
Other times, the process itself is what’s broken. Wrapping an app around a messy workflow just makes that workflow harder to change later, because now it’s encoded in software. If the team requesting the app can’t clearly describe the process they want to digitise, or if that process changes every few months, then building an app is premature. Fix the process first, and only then revisit whether it makes sense to build anything at all.
Read Next
A few related pieces worth your time:
- What It Takes to Ship a HIPAA-Compliant Mobile Health App in 2026
- Best CI/CD Platforms for Modern Engineering Teams
- HIPAA and PCI-DSS Costs in Healthcare and Fintech App Development
What This Investment Decision Comes Down To
Executives who handle Power App requests well tend to ask the same handful of questions every time, and they don’t budge until the answers are solid. How many people does this affect? Where does the data live right now? What will the investment cost per user once the app is live? Is the process stable enough to justify encoding it in software? And can the team actually support this thing twelve months from now without leaning on the person who originally asked for it?
If the answers hold up, the app will probably earn its keep. If they’re vague or half-formed, that build is a gamble dressed up as a quick win, and it’ll almost certainly end with a quiet write-off six months later.
