Two Apps Can Look the Same. But Were They Built the Same Way?
By Colin Yates, Founder, WorkMobile
One of the odd things about software is that the screen often tells you surprisingly little about the system behind it.
Two engineers can be standing on different sites looking at applications that appear to do almost exactly the same thing.
Both have been given a job, both complete a form, both take photographs and both submit a record back to the office. From their point of view, the experience may be almost identical, even though the organisations they work for have taken very different technology routes to create it.
Having spent many years working as a software developer, I tend to be more interested in what sits behind the screen than whether two products can tick the same feature boxes.
Microsoft Power Apps is a broad low-code platform for creating business applications. At WorkMobile, we come from a different starting point. We provide a configurable platform designed specifically around field and operational workflows, where work is issued, information and evidence are collected and completed records are returned to the office.
There is enough overlap between the two approaches for them to be compared quite naturally. Both can support mobile processes, collect information and present users with an application that helps them carry out a piece of work. What interests me is that they arrive at that point from almost opposite directions.
Starting with the application
Power Apps begins with the idea that an organisation wants to create an application. It provides the tools and the organisation decides what that application should become.
That’s a very attractive proposition from a development perspective. The application can be shaped around the organisation's own terminology, data and business rules rather than having to fit within the structure of a particular operational product. Canvas apps give the maker considerable freedom over layout and the user experience, while model-driven apps provide a more structured approach around information held in Dataverse. Applications can also connect with Microsoft services and other data sources.
The range of things that can be created is deliberately broad. One organisation might build a relatively simple departmental application such as a job booking system, while another might create something involving several groups of users, different sources of information and its own set of business rules, such as a helpdesk solution. Power Apps does not begin by assuming what type of business process is being digitised. The organisation defines the requirement and decides what the application needs to do.
For that reason, I have never thought of Power Apps as simply a digital form builder. A form might be part of the application, but the platform is capable of much more than putting questions onto a screen. It is an environment for creating and extending business applications, which is why it can be applied to such a wide range of requirements.
In some ways, the freedom comes from the fact that Power Apps deliberately knows very little about the application you are about to create. It gives you the tools, but it doesn't presume that the finished product will be an inspection app, a case-management system, an internal approval tool or something else entirely.
As I described in the opening article in this series, this means the organisation is effectively building a bespoke application around its particular requirement. It is not necessarily writing every component from first principles, but it is still responsible for deciding how the parts should be assembled, how the application should behave and what should happen when real-world conditions are less than ideal.
Starting with the type of work
The platform we have developed at WorkMobile begins with more assumptions because it was created for a narrower family of problems.
We assume that there will usually be some work to carry out, somebody who needs to carry it out, information or evidence that needs to be collected and something useful that needs to come back to the office. The actual work could be very different from one organisation to another, but that general operational pattern remains fairly recognisable.
Because of that starting point, the platform already includes the components normally associated with those processes. Mobile forms, offline data capture, job allocation, a booking diary, photographs and annotations, signatures, GPS and timestamps, site documents, approvals, automated reports and office visibility are all part of the product.
The process itself is not fixed. A utility company, engineering contractor and inspection business may all use completely different questions, terminology and rules. One workflow might need several approval stages while another has none. User groups, completion rules and report formats can all be configured around the work the organisation actually carries out.
What is more defined is the structure underneath. WorkMobile is centred around jobs, forms, mobile users, operational evidence, office review and completed outputs. It was never intended to be a general development environment for every type of business application.
That underlying structure has also been exercised repeatedly in the real world. Over the years, millions of jobs and records have flowed through WorkMobile across hundreds of customers. That does not mean every customer uses the platform in the same way. It means that core field requirements, such as handling large volumes of photographs, preserving evidence against the correct job and allowing people to work when connectivity is poor or unavailable, have been encountered, tested and refined many times.
Those are the kinds of details that can be easy to overlook when an application is first designed. What happens if an engineer captures a large number of high-resolution photographs? What if a signal disappears halfway through a job? What if a record is only partially completed, a device is restarted or several pieces of work need to be synchronised when the user reconnects? With a platform built specifically for field operations, many of those “what if?” questions were considered and solved a long time ago.
I think that is an important limitation to be open about. If an organisation needs a highly individual interface, unusual application behaviour or functionality that has little connection with that operational structure, then a broader application-development platform may be a much better fit. WorkMobile's focus is useful only when the requirement actually fits the type of work it was designed to support.
Why the difference can be hard to see
If you look only at the person holding the phone, much of this disappears.
Imagine those two engineers again. Each receives work, opens a form, records what happened, attaches evidence and submits the completed record. One organisation may have created that experience using Power Apps. The other may have configured it within WorkMobile. The engineer does not need to know which route was taken and may see little practical difference between the two.
The differences are more likely to emerge beneath the surface, particularly when the process is placed under pressure. The visible screen does not show how the application manages hundreds of photographs, behaves without a reliable connection, recovers from interruptions or keeps evidence attached to the right job as data moves between the field and the office.
A robust Power Apps solution can, of course, be designed to deal with these requirements. The point is not that it cannot. The point is that the organisation building the application needs to identify those scenarios, decide how they should be handled and make sure the resulting application has been properly tested. Within WorkMobile, much of that operational architecture is already part of the product.
From the organisation's point of view, therefore, the starting point was different. In one case it began with a platform designed to create applications and decided what that particular application should become. In the other it began with an operational application whose basic shape, behaviours and safeguards already existed, then configured its own process within it.
This is why I am wary of software comparisons based only on feature lists. If both products can show a form, capture a photograph and return information to the office, the comparison can quickly become a row of ticks in two columns. That tells you what the user may eventually be able to do, but it says very little about the philosophy, maturity or operational resilience of the platform underneath.
A broad development platform makes relatively few assumptions about the application because its value comes from allowing the organisation to decide what to create. A purpose-built operational platform makes more assumptions because it has already been designed around a particular type of process and refined through repeated use.
Neither approach is automatically better. They are simply different starting points, with different implications for flexibility, implementation effort and responsibility for the finished solution.
So, can two apps look almost identical and still have been built in completely different ways? Absolutely.
One may have started with the freedom to create an application around the requirement. The other may have started with a proven operational structure already in place and been configured around the way the organisation works.
The person holding the phone may never see that difference. The organisation choosing the platform probably should, because what sits beneath the screen can determine how well the application copes when real field work does not go perfectly to plan.
This article is part of a series exploring the themes in WorkMobile's white paper, Power Apps Can Build Almost Anything. But Should It?
