Power Apps or a standalone web application? How to decide
Both routes lead to an application that replaces spreadsheets and approvals by e-mail. They differ in who will use it, where the data will be stored and who will run it.
Spreadsheets and approvals by e-mail work as long as there are few people and few orders. When they are no longer enough, the question is what to build the new application in. The decision is usually between two routes: Power Apps with Power Automate in the Microsoft 365 environment, or a standalone web application with its own database.
Neither of them suits everything. Each has situations in which it makes sense, and limits that are better known before development than after it.
When Power Apps is a good fit
Power Apps is a suitable choice when the application will be used by your employees and the company already works in Microsoft 365. Typical uses are records and approval workflows: requests, orders, leave or jobs with a status and a responsible person.
- Sign-in is taken care of. Users sign in with the Microsoft work account they already have. The application runs in a browser and in the mobile app.
- A quick start. Screens are assembled from ready-made controls on a design canvas. The basis of an application can also be created directly on top of an existing SharePoint list.
- Approvals are ready to use. Power Automate has a ready-made approval action. The approver responds from the e-mail or from the Power Automate app, and the result can be written back to the records.
- Ready-made connections. There are standard connectors for SharePoint, Outlook or Teams, so notifications and data transfer do not have to be programmed from scratch.
The data can be stored in SharePoint lists or in Dataverse. This choice affects licensing and how the application copes with larger volumes of data.
Where Power Apps reaches its limits
Licences depend on what the application uses. An application that works only with standard connectors can also be run by users with the Power Apps use rights included in a Microsoft 365 plan, if your plan includes them. When the application uses a premium or custom connector, the on-premises data gateway or Dataverse, users need a licence with premium use rights. The SQL Server connector, for example, is a premium one. A custom connector, in turn, is a way of connecting the application to a system for which no ready-made connector exists. The rules change and also depend on the settings of the environment in which the application runs, so they need to be checked for the specific design before development starts. An overview of licensing and operating requirements is also part of a consultation.
External users. An application can also be shared with guest users from outside the company, for example with a supplier. However, a guest signs in through Microsoft Entra ID and needs a licence that matches the application. For websites aimed at external users, Microsoft has a separate product, Power Pages, which works with data in Dataverse and is licensed by the number of website users per month. With a larger number of people outside the company, this changes both the costs and the administration of accounts.
A very specific interface. What the ready-made controls lack can be added with custom components written by a developer. The more of them the application needs, the less the advantage of rapid development applies.
Larger volumes of data. Power Apps works well when filtering and sorting are carried out by the data source itself. If the data source cannot do that for a particular query, the application loads only a limited number of the first records and the result may be incomplete. For large tables, Microsoft recommends considering Dataverse, which supports more such queries. Dataverse, however, is one of the premium features, so we are back to licences. The platform also has request limits per user, which depend on the licence. According to Microsoft, most customers will not reach them, but they need to be taken into account when processing data in bulk.
Running outside the Microsoft cloud. Power Apps and Power Automate are cloud services. They connect to a database on your server through the on-premises data gateway, but the services themselves remain in the Microsoft cloud. If the whole solution is to run in your network or with another provider, that is a reason to consider a standalone application.
When a standalone web application is a good fit
A standalone web application has its own interface, its own data model and a database. It is a good fit mainly when:
- customers, suppliers or partners will use it too and you need your own sign-in and permissions,
- the interface has to match your workflow exactly, for example in production, in the warehouse or in the field,
- the logic is complex: calculations, planning, many relationships between data or large volumes of data,
- it has to run on your own server or in a cloud of your choice,
- there are many users or they change often, and a licence for each of them would be impractical.
Such an application can also exchange data with Microsoft 365, an ERP system or accounting software. So choosing a standalone application does not mean leaving behind the tools you already use.
The drawbacks need to be stated too:
- More work at the start. Sign-in, permissions, the database and the screens all have to be designed and developed. What is ready-made in Power Apps is created here as part of the project.
- Someone has to run it. Someone has to be responsible for the server or cloud, backups, updates and monitoring, whether in your company or at the supplier.
- Changes are made by a developer. A minor change to a form in Power Apps can often be handled by a trained colleague, while in a standalone application it means a change to the code.
With either route, make sure you know what remains yours after handover. The source code, the documentation and access to the environment should belong to you.
The comparison in brief
| Criterion | Power Apps | Standalone web application |
|---|---|---|
| Users | Mainly internal, with a Microsoft 365 account | Internal and external |
| Interface | From ready-made controls | Custom-designed |
| Data | SharePoint, Dataverse, connectors | Own database and data model |
| Costs | Development and user licences | Development, operation and maintenance |
| Operation | In the Microsoft cloud | Your server or a cloud of your choice |
| Start | Quicker for a common process | More work at the start |
Questions to answer before you decide
- Who will use the application? Only employees, or people outside the company as well? How many will there be, and do they have a Microsoft 365 account?
- Where is the data today? In spreadsheets, in SharePoint, in an ERP system or in a database on your own server? How quickly will it grow?
- Which systems need to be connected? Is there a ready-made connector for them, or do they have their own interface?
- Who will run the application and where should it run? Do you have someone in the company for that, or should it be a service provided by the supplier?
- How might the process change? Will new steps, branches or external partners be added?
The answers to these questions form the basis of the brief. In application development we compare both options in the first stage, when we go through the process, the data and the access rights.
Both routes can be the right one
Power Apps tends to be a sensible choice for internal records and approvals in a company that already works in Microsoft 365 and can manage with standard connections. A standalone web application makes sense for external users, a custom interface, complex logic or operation on your own server.
It is worth deciding on the technology only after you have gone through the process, the data and the users. Then it is clear which of the limits described apply to you and which do not.