We’ll Just Build It in Power Apps.” But Is That Really the Right Question?
By Colin Yates, Co-Founder, WorkMobile
I spent many years working as a software developer, so I completely understand the instinct to build something when a new business requirement appears.
Give a developer a problem and, quite naturally, they start thinking about how it could be solved: what data is needed, what the screens might look like, how the process should flow and what should happen at each stage.
Power Apps has made that route much more accessible for organisations. If a business is already using Microsoft 365, Dynamics 365, SharePoint, Teams or Power BI and there are people internally who understand Power Platform, then Power Apps is an obvious place to start when someone asks for a new application. In many cases, it will be technically capable of delivering what is required.
The point I would question is whether technical capability should be the starting point for the decision.
Over the years I have seen plenty of requirements that begin with something along the lines of, “we just need a form they can fill in on their mobile phone”. It sounds straightforward at first. Then the detail starts to emerge. The form needs to work without a reliable connection.
Users need different permissions. Photographs have to be attached to the correct job, perhaps with location and time information embedded into the photograph. Certain answers need to trigger other questions. Completed work needs to go through an approval process, somebody needs notifying when something goes wrong and a customer-facing report needs producing at the end.
Before long, the form itself is one of the smallest parts of the requirement. Power Apps can handle those things. The question is not whether the platform is capable. It is how much of that structure the organisation wants to design, build and then continue to own.
Building software also means owning it
The first release of an application is rarely the end of the story. Processes change, questions get added, reports are amended and other departments sometimes begin using something that was originally intended for one small team. An approval stage might be introduced or the business may decide that information needs to connect to another system.
At the same time, the person who originally created the application may move into another role, become occupied with other projects or leave the organisation altogether. The software carries on being used, but the knowledge around how it works does not always remain quite so neatly in place.
That is a familiar problem in software development generally and isn’t something unique to Power Apps. A relatively small internal application can gradually become important enough that people rely on it every day. Once that happens, it needs proper ownership, documentation, support and a sensible way of managing future changes.
That doesn't mean it was wrong to build the application. It just means that when you decide to build something, you also need to think about what owning it will involve afterwards.
There are plenty of occasions when building is the right choice
If a process is genuinely unusual, if the interface needs to work in a very particular way or if the application is closely tied to Microsoft data and services, then Power Apps can be an excellent choice. The flexibility of a low-code development platform is valuable precisely because the organisation is not being forced into the structure of an existing product.
The same is true for organisations with established Power Platform teams. If you've already got the skills, governance and capacity in place to build and support a portfolio of applications, adding another one may be perfectly sensible.
Where I think the discussion becomes more interesting is when the requirement is important, but not especially unusual.
We’ve worked with hundreds of businesses over the years, and each one thinks their processes are unique to themselves. The fact is, a great deal of operational work follows a recognisable pattern. Work is issued, somebody carries it out, information and evidence are collected, the result comes back to the office, somebody reviews it and a record or report is produced. The terminology, questions and rules may differ from one organisation to another, but the underlying structure is often very similar.
If that is the process, it is worth asking whether the organisation needs another bespoke application or whether what really needs tailoring is the workflow itself.
There is still plenty to configure. Someone still has to decide what information should be collected, who receives the work, which evidence is mandatory, what happens when something fails, who approves the result and what the finished output should look like.
Those are important business decisions, but they do not necessarily require the underlying application to be created from scratch every time.
The questions I would ask before starting
Before starting, I'd want answers to two other questions as well.
The first is how quickly a dependable version of the process can be put into the hands of the people who will actually use it. The second is who will be responsible for the application in two or three years' time.
Those questions bring deployment, support, change and ownership into the conversation early, rather than after the application has become embedded in the business.
A “quick departmental app” often stays around for much longer than originally expected. If the process becomes important enough that the organisation depends on it, the software behind it becomes important too.
So I am not suggesting that organisations stop asking whether something can be built in Power Apps. It is a perfectly reasonable question and in many cases the answer will be yes.
I just think there is a better question to ask alongside it:
Does this requirement actually justify building and owning another application, or are we dealing with a familiar operational problem that could be solved in a different way?
I'd much rather have that conversation at the beginning than two years down the line when the “quick app” has become something half the department relies on.
