Power Apps or expansion on Azure : Where Does the Border Lie?
This is the most critical decision in a business tool project, and it’s almost always made too late—after selecting a vendor, who naturally proposed what they know how to do. Yet the two approaches don’t cost the same, don’t take the same amount of time, and can’t be corrected in the same way once a mistake has been made.
The two approaches, in one sentence each
Power Apps Builds a tool using existing building blocks: a form, a list, permissions, a database, and connections to your other systems. You don't build the plumbing; you describe the business process.
A project on Azure starts from a blank page and builds exactly what’s needed. You build the infrastructure, and you become the owner—with all the freedom and responsibility that entails.
Neither is the high-end version of the other. They are two solutions to two different situations.
The Five Decisive Questions
Who uses the tool? Company employees listed in your directory: Power Apps is right at home here. Customers, job candidates, and a broad, unauthenticated audience: that’s a different story, because the platform’s licensing model is designed for internal users.
How many people at once? A few dozen, a few hundred: the platform handles it without a second thought. Thousands of concurrent sessions, or sharp, short spikes: that’s an architectural issue, and it’s addressed at Azure.
What should a tool do that no other tool can do? A specific business calculation, an optimization algorithm, image processing, integration with industrial equipment. This is just one example among many, but the principle holds true: as soon as there’s a core component that no one has written before you, you have to write it, and it works best on Azure.
What is the expected lifespan? A tool that supports a process set to change every six months is best built in an environment where changes can be made quickly. A foundation that is meant to last ten years and support other tools should be built as a foundation.
Who will update it in three years? An in-house team with expertise in the field can take over an application Power Apps. Custom development requires a developer—either your own or an outside contractor. This option involves more than just the initial budget.
Note: These two approaches are not mutually exclusive. The most common—and most robust—approach is a hybrid one: the interface and validation logic are handled in ` Power Apps`, while the computation-intensive processing is handled in Azure, with the two connected by a service. This way, we maintain speed on one end and control on the other.
Choosing the wrong side—and what it costs
Too much custom development. A company commissions the development of a comprehensive tool when simply integrating existing components would have sufficed. It pays for development, then hosting, then maintenance, then security updates for components it didn’t choose—and it becomes dependent on the developer who wrote it.
Too much custom development. A company forces the platform to do things it isn’t designed to do. The tool is released, it doesn’t work properly, it slows down, and every fix breaks something else. This is the most reliable sign of a boundary error, and it usually becomes apparent when the system is scaled up.
In both cases, making up for the mistake costs more than it would have cost to make the right choice in the first place. That is why this question must be considered before deciding who will do the construction.
What they both have in common—and what matters
Regardless of which side of the border it is on, the tool relies on the same identity, the same rights, the same logging, and the same security rules as the rest of your information system. This is true for both a Power Apps application and an application hosted on Azure. A decision-maker can therefore make decisions based on business needs and usage without worrying that governance will differ depending on the solution chosen.
What to Do
- Answer the five questions before meeting with a service provider.
- Write a one-page description of what the tool is supposed to do—and, most importantly, what it won’t do.
- Explicitly ask the person you are consulting to explain their side of the story.
- If the answer is “both,” ask where the seam runs—that’s where the trouble lies.
- Plan ahead for who will take over the tool in three years, and make sure that option remains available.
Lambert Consulting Set this boundary before writing a single line of code, and build on both sides. The actual cost of the licenses is calculated at that same time, and the question of who owns the application once it’s finished comes up at the very first meeting, not the last one.
Microsoft Sources
What an article Can't Know
An article describes what applies to everyone. What varies from one organization to another is the inventory: which applications, which accounts, and which pieces of equipment are actually involved in your organization. The inventory determines the scope of the effort, and it cannot be summarized on a single page.
You'll be speaking directly with the engineers who will be doing the work, not with a middleman. We'll respond within 24 business hours.
Check what is still true
Announced dates are sometimes postponed, products are renamed, and conditions change. The blog tracks these topics over time: when a rule changes, a new post announces it.
Search for a topic in the blogIn the same issue
Three articles on the same topic. The blog has 149 articles, all of which are freely accessible.