A useful app idea is not yet an approvable project
A spreadsheet-driven approval process is slowing work down. Managers cannot see where requests are stuck. Teams re-enter the same information into several systems. Someone suggests building a Power App, the room agrees it sounds sensible, and the idea appears to have momentum.
Then it reaches the people who must approve the spend.
They ask who will use it, what the first release includes, which systems it must connect to, who owns the data, how success will be measured and what ongoing support will cost. The answers are incomplete. The idea stalls.
Promising Power Apps projects usually stall because the business problem, first-release boundary and total delivery responsibility have not been agreed early enough. Power Apps may be technically capable, but decision-makers cannot approve an app while user value, ownership, licensing, data, security and success measures remain open to interpretation.
Why “we need an app” is the wrong starting point
A Power App is a proposed solution. It is not a business requirement.
Take a purchase approval process managed through email and Excel. The visible problem may be slow approvals. The underlying causes could include unclear authority limits, missing information, duplicate data entry, poor escalation rules or no shared view of outstanding requests.
Building a cleaner form will not resolve those issues by itself. It may simply reproduce them in a new interface.
Discovery should therefore begin with the users, workflow and operational cost of the problem. UK government discovery guidance makes the same distinction: define the problem before committing to build, understand user needs and constraints, and decide whether further investment is justified.
What makes a Power Apps project decision-ready?
Before a reliable estimate or approval can be produced, the business should be able to answer seven questions:
- Who is affected, and how often does the problem occur?
- What happens today, including manual workarounds?
- Which data enters, leaves or changes during the process?
- Which ERP, CRM, Microsoft 365 or third-party systems are involved?
- Who owns the process, data and post-launch support?
- What must the first release prove?
- How will improvement be measured?
These questions turn enthusiasm into a value case. They expose whether the app could reduce approval time, remove rekeying, improve auditability, give managers better visibility or reduce dependence on individual memory.
They may also reveal that an app is not the best first move. A process change, existing Dynamics 365 capability or simpler automation may solve the problem with less cost and disruption.
That is not lost momentum. It is better decision-making.
GO ERP’s view is straightforward: Power Apps should follow the path from pain to process to system design. The technology comes after the business has defined what needs to improve, who owns the outcome and what a commercially safe first step looks like.
Vague goals create several different apps in the same meeting
A Power Apps project can look aligned long before it is aligned.
Operations may picture a simple request form. Finance may expect approval controls and audit history. IT may assume Dataverse, managed environments and formal security roles. The sponsor may expect a polished application ready for wider rollout.
Everyone leaves the meeting believing they agreed. In reality, they agreed only on the idea.
What should Power Apps discovery produce?
Power Apps discovery should produce a documented agreement on the problem boundary, user groups, process rules, data, permissions, integrations, first-release priorities and success measures. A workshop is useful only when it converts assumptions into decisions that can guide design, estimation and approval.
The output should cover:
- the current process and its failure points;
- each user role and what that role can view or change;
- approval rules, exceptions and escalation paths;
- data sources, ownership and quality concerns;
- integration assumptions across Dynamics 365, ERP, CRM or third-party systems;
- what the prototype or MVP must prove;
- what is explicitly outside the first release.
Microsoft’s own Power Platform guidance places stakeholder engagement, role clarity, security, governance, success criteria and strategic alignment early in the adoption process. The commercial reason is simple: decisions made late cost more to correct.
Use the APPROVE Test before estimating the app
GO ERP’s APPROVE Test gives project sponsors a practical way to check whether an idea is ready for scoping:
| Test | Decision to make |
| A — Affected users | Who uses the app, how often, and in which locations or devices? |
| P — Process boundary | Where does the workflow start and finish? |
| P — Proof of value | Which delay, cost, error or control problem should improve? |
| R — Risks and rights | What licensing, security, compliance or integration issues may apply? |
| O — Ownership | Who owns the process, data, adoption and support? |
| V — Version-one scope | What must the first release include, and what must wait? |
| E — Evidence of success | Which measures will show that the app is working? |
Consider a maintenance-request app described as “a simple mobile form”. Once users ask for photographs, asset data from ERP, approval routing, contractor access, service-level alerts, audit history and management reporting, the project has moved far beyond a form.
Each request may be reasonable. The problem is not the extra functionality. The problem is discovering it after the estimate has already shaped expectations.
This is where business-first Power Apps consulting earns its value. Clear scope reduces rework. Defined roles improve adoption. Agreed ownership protects support. Shared success measures give leaders a credible basis for deciding whether to proceed.
Budget shock is usually a late discovery of early assumptions
A Power Apps estimate often feels high because the buyer and delivery team are pricing different things.
The buyer may have a prototype in mind: a few screens, a simple workflow and a small user group. The delivery estimate may cover a governed operational application with security roles, integrations, testing, deployment controls, monitoring and support.
The gap is not simply technical. It is commercial.
What level of solution are you actually buying?
| Solution class | Typical expectation | Cost and control implications |
| Prototype | Tests whether an idea or user flow is viable | Limited users, temporary data and little production responsibility |
| Team workflow app | Replaces a contained manual process | Defined permissions, basic testing, ownership and support |
| Departmental application | Supports several roles or connected workflows | Formal data model, governed environments, integrations and release controls |
| Business-critical solution | Carries an operational process the business depends on | Security assurance, resilience, monitoring, documentation, support and change control |
GO ERP’s position is clear: low-code does not mean low-skill or low-risk. A prototype for one user is materially different from a production system used across an organisation. The total cost depends on users, architecture, licensing, data, governance and operational ownership, not just the time needed to assemble screens.
What drives Power Apps project costs?
A credible estimate may need to account for:
- Power Apps licence rights across the intended user population;
- premium or custom connectors;
- Dataverse database, file and log capacity;
- development, test and production environments;
- ERP, CRM, Microsoft 365 or third-party integrations;
- security roles, data protection and audit requirements;
- testing, deployment, monitoring, training and support.
Microsoft’s July 2026 Power Platform Licensing Guide distinguishes per-user, per-app and pay-as-you-go models, alongside limited rights included with some Microsoft 365 and Dynamics 365 licences. It also shows that connector choice, Dataverse use and environment design can affect the required licence model. Current terms should always be checked during scoping rather than assumed from an earlier project.
Weak inputs create predictable business risks
| Weak input | Business risk | Decision required |
| User population undefined | Licence exposure and unreliable budgeting | Confirm users, roles and access frequency |
| Integration treated as “simple” | Rework, delay and hidden dependencies | Confirm systems, APIs, data volumes and ownership |
| Permissions left vague | Security or compliance gaps | Approve role and access rules |
| Prototype treated as production | Support failure and operational disruption | Define the required service level |
| No data owner | Poor quality and low trust | Assign ownership and validation rules |
| No adoption plan | Delivered app remains unused | Agree training, communications and support |
The better budget question is not, “How much does a Power App cost?” It is, “How much operational responsibility must this solution carry?”
Once that is clear, scope, architecture and spend can be judged on the same basis.
Credibility returns when the first release has firm boundaries
A stalled Power Apps project becomes credible again when the business narrows the problem, fixes the first-release boundary and agrees how value will be judged.
The aim is not to squeeze every requirement into version one. It is to prove that one defined process can work better, with enough control to protect spend, users and operational continuity.
What should a credible Power Apps MVP include?
A credible Power Apps MVP should solve one valuable process problem for a defined user group, using agreed data, permissions and success measures. It should include enough security, testing, ownership and support to operate safely, but exclude enhancements that are not needed to prove the first business outcome.
That means agreeing:
- the backlog and its priority order;
- explicit exclusions for the first release;
- acceptance criteria for each core process;
- the data model and source ownership;
- security roles and access rules;
- the testing and deployment approach;
- the adoption, training and support plan;
- where future enhancements will be parked.
This is not administrative overhead. It protects the commercial agreement.
Without firm backlog rules, every sensible request can become an urgent addition. A mobile view, extra approval route, new ERP field or management dashboard may each appear small, but together they can change the architecture, licence model, testing effort and launch date.
Measure the process, not the presence of the app
A Power Apps project should not be judged only by whether the app went live.
The first release should be tied to a small set of baseline and target measures, such as:
- average approval time;
- manual rekeying effort;
- error or rejection rates;
- overdue requests;
- user uptake;
- support demand;
- management visibility of work in progress.
These measures help leaders decide whether to expand, revise or stop. Stopping after discovery or an early release is not failure when the evidence shows that further investment is not justified. It can prevent greater cost and disruption later.
Power Apps project FAQs
Why do Power Apps projects stall?
They usually stall because the problem, user group, ownership, scope, licensing or success measures remain unresolved.
What should Power Apps discovery include?
It should cover users, process boundaries, data, permissions, integrations, constraints, first-release priorities and measurable business outcomes.
What affects Power Apps project cost?
Cost is shaped by users, licence rights, connectors, Dataverse, integrations, environments, security, testing, deployment and ongoing support.
When is a prototype ready for production?
Only when its data, permissions, testing, deployment, monitoring, support and ownership are suitable for real operational use.
Before approving a build, apply the APPROVE Test: affected users, process boundary, proof of value, risks and rights, ownership, version-one scope and evidence of success.
GO ERP can use this framework in a Power Apps Project Readiness Review to map the first release, expose cost and architecture assumptions, and define the next decisions before development begins. The purpose is not to sell a bigger project. It is to help the business make a safer one.
