Power Apps and bespoke web applications: two different approaches

Power Apps provides a Microsoft framework to assemble; bespoke development lets you design that framework. This difference affects speed, skills, governance and evolution.

Microsoft distinguishes between canvas apps, built on a free-form surface, and model-driven apps, structured around tables, relationships, forms and views. The approach is natural when identities, files and collaboration already reside in Microsoft 365, Teams, SharePoint or Dataverse.

A bespoke web application combines a frontend, API, database and infrastructure chosen for the project. It can use Entra ID and Microsoft 365 without belonging to Power Platform. In return, testing, updates, backups, monitoring and maintenance must be organised.

The page GVISION web applications and business tools describes the portals, dashboards, workflows and integrations that a dedicated solution can bring together. It focuses on implementation; this guide remains centred on the choice of architecture.

Mobile Application Management applies rules to work applications and business data without placing the whole endpoint under device management. Microsoft describes MAM for unenrolled devices as a way to combine application configuration and protection. On supported apps, policies can require an app PIN, restrict copying to personal apps, limit local storage and selectively remove organisational data.

The right choice becomes clear when you describe a real-world case with its users, data, exceptions and lifespan. Slogans such as “low-code is always faster” or “code is always more powerful” are not enough.

Internal or public users

Purchase, logistics and personal use policy needed.

Stable process or evolving product

A simple inspection can be structured in a few screens. A strategic business product accumulates exceptions, profiles, integrations and a roadmap. This scenario requires genuine product governance, whether in Power Platform or through bespoke development.

Data and integrations

Company device

User experience and devices

Standard components may be sufficient for internal use. A configurator, SaaS platform or public user journey often requires a more flexible frontend. Offline use, camera access, signatures, accessibility and languages must be tested on real devices.

Complete comparison: Power Apps or bespoke web application

4. Company-owned device No option is superior for every project.

When is Power Apps the right choice?

Power Apps is suitable for well-defined internal requirements connected to Microsoft 365, where speed and platform governance matter more than extreme customisation.

• Request forms, approvals, checklists or internal inspections.
• Tracking a simple process with a few statuses and roles.
• Data-entry or consultation interfaces built on SharePoint or Dataverse.
• Automations combined with Power Automate for notifications and approvals.
• IT or business teams trained in Power Platform and its governance.

When is a bespoke web application preferable?

Bespoke development becomes relevant when the product falls outside the standard Microsoft framework, needs to serve an external audience or relies on complex logic.

• Customer portal, marketplace or public service intended for external users.
• A differentiated brand experience, with a specific design and user journey.
• Complex business rules, advanced calculations or proprietary decision engines.
• Deep integrations with third-party systems, APIs or existing architectures.
• The need to control hosting, scalability or independence from a vendor.

The hybrid scenario: combining both approaches

Many organisations benefit from not choosing a single technology for all their needs. Power Apps can handle internal workflows while a bespoke web application serves a public portal or strategic product.

This hybrid architecture requires clear governance: who decides, which data is shared, which APIs connect the systems, and which operational plan covers the whole environment. A scoping workshop helps define this boundary before development begins.

Broadest controls available on the platform.

Schools, non-profit organisations, professional practices, healthcare organisations and public administrations face recurring requirements where this choice arises in practical terms. A non-profit organisation can digitise a membership application internally with Power Apps, then build a separate bespoke member portal. A school can manage absences with a simple internal tool, while a public parents' area may justify a dedicated application. A medical practice or public administration must pay particular attention to GDPR compliance, data hosting and access rights depending on the option selected.

Total cost and licensing model

Company device Construction, operation, evolution and exit scenarios must be compared over several years.

For Power Apps, licences vary depending on the use of Dataverse, premium connectors, custom APIs and on-premises gateways. Check the latest Microsoft documentation and your contract, as pricing evolves. For bespoke development, the initial investment is generally higher, but hosting, maintenance and ongoing development can be better controlled over time depending on the chosen architecture.

Security, governance and compliance

Both options can be secured, but the responsibilities differ. Power Apps inherits data policies, environments and Power Platform administration. Bespoke development requires authentication, secrets, backups, monitoring and the business continuity plan to be explicitly defined. In both cases, personal data protection must comply with the GDPR, with particular attention required when sensitive or health data is involved.

An eight-step decision-making method

A short scoping sprint can replace weeks of technological debate. It should produce comparable elements, a proof of feasibility and a documented decision.

1. Define the outcome: which deadline, risk, error or manual task needs to be reduced?
2. Map a user journey: actors, steps, decisions, exceptions and the actual end of the process.
3. Catalogue the data: Write policy and notice. Explain visibility, responsibilities, support, loss, removal, departure and updates.
4. Define the users: internal users, guests, customers, the public, volumes and devices.
5. Identify the constraints: integrations, offline use, performance, accessibility, languages and availability.
6. Prototype the riskiest point: not just the easiest screen, but the integration or rule that could invalidate the option.
7. Compare total cost: Purchase, logistics and personal use policy needed.
8. Decide based on thresholds: conditions that validate Power Apps, bespoke development or a hybrid architecture.

The decision should name a product owner, a definition of “production-ready” and a review date after launch. Without these three elements, requests accumulate without arbitration and costs increase regardless of the technology.

Common mistakes to avoid

Most failures stem from poor scoping and a lack of governance, not from the name of the platform. Correct these mistakes before comparing proposals.

• Choosing Power Apps simply because Microsoft 365 is already in place, without checking licences and connectors.
• Choosing bespoke development to obtain a different interface when a standard process would solve the requirement.
• Using Excel as a production database because it was sufficient for the demonstration.
• Ignoring delegation warnings or testing them with a volume that is too small.
• 4. Company-owned device
• Forgetting data migration, history, synchronisation errors and permissions.
• Purchase, logistics and personal use policy needed.
• Automating a process that nobody has simplified or validated.