Power Apps lets you build business applications within the Microsoft environment. It can suit an internal request process or data-entry app; custom software is a candidate when your process needs more bespoke work than you can maintain well on the platform. Start with the work, the users and total costs. Our custom software guide covers the wider decision. If you’re considering other building tools too, read Airtable, Notion or custom software and no-code or custom automation.
What exactly is Microsoft Power Apps?
Microsoft describes Power Apps as a collection of apps, services and connectors for building business applications. Apps can use Dataverse or other sources, such as SharePoint. You build screens and process logic on the platform; you aren’t buying a finished solution for the entire business process.
That distinction helps when assessing a proposal. The platform supplies capabilities, but someone must decide which fields are needed, who can change them and what happens during an exception. A leave-request app needs different behaviour from an app used by a service technician to complete a job.
You’re comparing two ways to build. One uses an established application platform; the other gives you more choices over components and configuration. Both need design, testing and someone who remains responsible after delivery.
Which Power Apps approach fits your process?
Microsoft distinguishes canvas and model-driven apps, among other approaches. Canvas begins with user screens; model-driven apps centre on the data model in Dataverse. Ask a supplier to explain why the proposed route fits your work before treating a demonstration as the design.
Consider an internal approval process. The applicant needs to provide the right information, the reviewer needs context, and someone must be able to find out why a request was rejected. Seeing the entry screen doesn’t establish how the rest works. Ask for the complete journey, including returning and resubmitting a request.
Also consider who’ll change the app. Being able to add fields doesn’t necessarily prepare an employee to change permissions or business rules. Agree which changes the team makes independently and when a developer or administrator is needed. That boundary can matter more than the low-code label.
When is Power Apps a good candidate?
Consider Power Apps when you have a bounded business process, suitable data sources and a well-managed Microsoft environment. Having Microsoft 365 is a starting point for investigation. It doesn’t prove that the required functions and users are already covered by your subscription.
A useful first candidate has exceptions employees can explain. For example, a materials request: someone selects items, a responsible person reviews the request, and the issue of materials is recorded. This is a hypothetical example, not a TopDevs client case. A trial can establish fairly clearly whether that journey works.
A vague request to “replace all the spreadsheets” is harder. It may conceal several processes and responsibilities. First identify the file causing the most duplicate entry and follow the information from there. Sometimes a better data source is enough. Sometimes the missing part is an integration.
For an existing Power App, establish what already works. If employees like entering data but reporting is missing, replacing the entire app isn’t inevitable. A targeted addition may be a smaller intervention than starting again.
What do Power Apps licences cost?
The Dutch pricing page lists Power Apps Premium at €17.30 per user per month, paid annually and excluding VAT. Prices checked on 2026-09-24. The developer plan is for building and testing. Check current production options and additional capacity; rates vary by billing country.
If fifty users each need that Premium licence, the calculation is 50 × €17.30 × 12 = €10,380 a year excluding VAT. This is a derived licensing example, not an app’s total cost. It excludes development, support and other required services.
Microsoft’s licensing FAQ distinguishes included use rights from rights for capabilities such as premium connectors. Record the required entitlement for each user group and integration. Don’t assume a Microsoft data source automatically falls within an existing Microsoft 365 licence.
How do you compare Power Apps and custom software fairly?
Compare the same process journey. Have both proposals explain how they handle an ordinary request, an error and a later change. Otherwise, you may compare a small demonstration with a product expected to cover exceptions and maintenance too.
| Topic | Check in Power Apps | Check in custom software |
|---|---|---|
| Users | Required rights for each user group | Account management and agreed roles |
| Data | Source, connector and capacity | Data model, integrations and storage |
| Business logic | Delivery and maintenance on the platform | How rules are documented and tested |
| Changes | Who may safely change the app | Who reviews and deploys code changes |
| Costs | Licences, configuration and maintenance | Development, hosting and maintenance |
| Leaving | Export and solution handover | Code, documentation and handover |
A supplier’s preference for a tool isn’t evidence. Ask which requirement decides the matter. If they say something can’t be done, ask which step fails and what alternatives were investigated. “Too complex” becomes useful only when you know what it’s too complex for.
What does the 500 or 2000 record limit mean?
For a canvas query that cannot be delegated to its data source, Microsoft’s delegation documentation describes a default limit of 500 retrieved records, configurable to 2000. This isn’t a general database maximum. A search can return incomplete results while the user believes they’re seeing everything.
During the trial, ask how completeness is checked. Deliberately include data the chosen search must find. Compare results with the source, including after the dataset grows. A fast empty list isn’t good enough if matching records exist.
The same principle applies to custom software. A screen opening quickly doesn’t prove that its selection is correct. Test searches, totals and reports in both approaches. You need a useful answer, not just a pleasant waiting time.
How do you assess integrations and business rules?
Record which system is authoritative for each piece of information. If a customer address changes in the CRM, establish whether the app reads that change or can also store addresses itself. Without that agreement, two conflicting versions can develop on either platform.
Test the precise action an integration needs to perform. An available connector doesn’t establish that it supports the required fields or actions. Ask how a changed order is handled and what happens when the receiving application is temporarily unavailable. Our guide to connecting software helps structure those questions.
Pay attention to decisions with consequences. Who may approve a request, when must another person review it, and can the same request run again? Document such rules as readable examples outside the screens. An employee should be able to assess the behaviour without understanding a technical formula.
Who maintains the app when its maker is away?
Name a process owner and someone responsible for the technology. They can be different people. The process owner determines a correct outcome; the maintainer needs to investigate why that outcome wasn’t reached.
Practise handover during the trial. Can another employee identify the data source, access arrangements and error reporting? Documentation helps, but someone needs to use it. Have the receiving maintainer perform a small change or recovery task.
Agree how changes are tested before everyone uses them. A new mandatory field can interrupt an existing journey. Plan how you’ll discover that, who approves the change and how to roll back if it fails. Low-code changes the building method; it doesn’t remove responsibility for daily work.
What about external users and mobile work?
Distinguish employees, contractors and customers. They don’t automatically have the same access or usage pattern. An employee may open the app daily, while a customer only checks an occasional request. For each group, demonstrate sign-in, visible data and the cost of access.
Test with an account that actually has the intended role. A demonstration using an administrator account can conceal restrictions. Ask the trial user to open a direct link without first visiting the intended start page. The app still needs to decide what that person may see. Document how access ends when someone leaves or an assignment finishes.
For mobile work, location belongs in the test. A form that works comfortably in the office may be awkward outdoors in bright light, with gloves or on a poor connection. Have an employee use the intended device and check what happens when connectivity drops during a save. Establish whether offline work is required and how later changes are reconciled; don’t assume that behaviour simply because the app opens on a phone.
Avoid a long list of unprioritised wishes. Describe which action must work on location and what the team may do if it temporarily cannot. Sometimes a clear recovery route is enough. Sometimes working without a connection is a firm requirement that affects the whole design.
When does custom development become a sensible next step?
Investigate custom software when a demonstrated requirement falls outside a maintainable platform setup. That might involve a particular user experience, bespoke calculations or a way of serving customers that calls for another design. The requirement must be specific enough to assess both routes against it.
The Mastone case study describes a property platform built around Dutch WWS rental-point calculations. It illustrates how business-specific rules can shape an application. It doesn’t establish that such rules can never be implemented in Power Apps; that project comparison hasn’t been made here.
Ask a custom supplier what can stay from your current environment. An existing database or document store needn’t always disappear. A bespoke component alongside the app may be enough, reducing what must be redesigned and what employees must relearn.
Scrutinise custom development as carefully as Power Apps. “Complete freedom” also means making and maintaining choices. Ask how the solution remains transferable and what would be needed to bring in another supplier. The code remains yours, but you also need documentation and working access. Read code ownership and vendor lock-in for that discussion.
How do you build a budget that remains useful?
Separate one-off work from recurring costs. List discovery, development and data transfer separately from licences, hosting and support. Ask which costs grow with usage and which change only when you add functionality.
Include your employees’ time. Someone must provide examples, assess the result and help colleagues through the transition. Without that availability, even a technically simple app can stall. Assign a responsible person to each customer task, not just a date.
Use traceable assumptions. Record how many people will use the app and the changes you expect. Add a scenario in which more users need access. Our custom software cost guide explains development and maintenance budgeting. Avoid a universal break-even claim that custom software is always cheaper beyond a certain headcount.
How do you test the decision before commissioning a large build?
Choose a representative journey with a recognisable outcome. Collect ordinary inputs and exceptions employees actually encounter. Have the future user run the trial rather than simply watching its maker.
Agree what you need to learn. Examples include finding complete records, refusing an unauthorised user and recovering an interrupted transfer. Record remaining manual work too. A trial doesn’t need every screen finished to answer these questions.
Then request a short finding for each requirement: demonstrated, still to test or unsuitable within the proposal. That stops an attractive demonstration pushing all unanswered questions into the future. Use the remaining questions to revise scope and budget.
How do you actually get started?
Choose the process to improve and describe where it gets stuck. Gather sample inputs, identify the users and have the required rights and licences checked. Compare a Power Apps trial with an alternative using the same requirements, including maintenance after delivery.
To discuss custom software development or establish whether Power Apps is enough, book a call. We can work through the decision around your actual process.
