Built for Six, Used by Six Hundred: When Does a Small App Stop Being a Small App?
By Colin Yates, Director, WorkMobile
Most business-critical software does not begin with somebody saying, “We’re going to build a business-critical system.”
It usually starts with something much smaller. A spreadsheet is becoming difficult to manage, a departmental form needs digitising or a handful of engineers need a better way to record their work.
Someone builds an application, it solves the immediate problem and everybody gets on with their day.
Then, because the application works, people start asking it to do more.
Another team wants to use it. A few more questions are added. Somebody asks for an approval stage. A report is introduced, followed by a connection to another system. Three years later, the form that six engineers once filled in is used by several hundred people, holds customer records, feeds compliance reporting and perhaps even triggers invoicing. And the person who built it has moved on.
None of those changes felt dramatic at the time. But the application has grown in three directions at once: more people use it, more of the business depends on it and fewer people understand it. What very often has not grown is the foundation underneath it.
That gap is the real risk. Not the growth itself, but an application that has outgrown the way it was built and the way it is looked after.
Success changes what an application is
I spent many years developing software and I have always found this one of the more interesting parts of application development. Software has a habit of becoming more important precisely because it has been successful.
The application may still look quite modest. It might only have a few screens and people may describe it as “the app we use for inspections” or “the form the engineers fill in”. But the number of screens is not what determines its importance. What counts is what happens to the business if it is unavailable, or if a change goes wrong.
If work cannot be completed, records stop reaching the office or information needed elsewhere disappears, then the application has become part of the operation.
The difficulty is that this transition rarely happens on a particular day. Nobody receives a notification saying the application has now become important enough to need different management. It happens gradually, as more people, processes and information come to depend on it.
Built for six is not built for six hundred
The first way an application outgrows its foundations is scale.
Decisions that are perfectly sensible for six users can become real constraints for six hundred. Where the data is stored, how much of it each device loads, how records are synchronised and how the screens retrieve information are often chosen to get something working quickly. At the start, that is exactly the right priority.
As the application grows, those early decisions begin to matter. A year of records from six people is trivial. Three years of records from several hundred people, each with photographs and signatures, is a very different volume of data. More people are working on the same jobs at the same time and more devices are synchronising offline information, so the chances of conflicts increase. Screens that were once instant start to slow down.
In an office, a slow screen is an irritation. In the field, as I wrote last week, it is often the point at which people start finding workarounds, and the real process quietly begins to happen somewhere else.
Cost grows too. Licensing, storage, support and the time spent maintaining the application all tend to rise with the number of users, which can change the business case that justified building it in the first place.
At some point the answer to a request is no longer “we’ll add a field”. It becomes “we’ll need to rebuild it”. That is often the moment an organisation realises how much it now depends on something that was never designed to carry that load.
The person who built it may not always be there
The second way an application outgrows its foundations is knowledge.
A problem we have seen many times starts when a relatively small application needs changing, but the person who originally created it has moved to another role, is busy with other work or has left the organisation.
The application may still be working perfectly well. The difficulty only appears when someone asks for a change. A new field, an altered report or a different approval stage can become uncomfortable if nobody else fully understands the formulas, data structure, connections and decisions that sit behind it.
This is not a Power Apps problem. The same thing happens with almost any internally developed software, and I have seen it throughout my career. The person who builds something naturally accumulates knowledge about how it works, including plenty of small decisions that were never written down because, at the time, there was no reason to document them.
That is when you hear phrases such as “I think Steve built that” or “Sarah normally changes the form for us”. Those arrangements can work for years, right up until the moment they do not.
Ownership becomes more than knowing who created it
Once an application supports an important process, ownership needs to become more formal.
Someone needs to know who can approve changes, who understands the application and who is responsible if something goes wrong. Documentation, testing and sensible control over changes matter more, because an amendment to an application people rely on can affect much more than the screen being changed.
Organisations with established Power Platform teams may already have this in place. Applications move through defined development and testing environments, changes are controlled and support does not depend on one person. In that environment, another Power Apps application simply becomes part of an existing, well-managed estate.
The difficulty tends to appear when the application has grown faster than the arrangements around it. It has become important to the department, but responsibility for it still rests on informal arrangements that were perfectly adequate when it was much smaller.
There is a quieter version of this problem too. A departmental form that begins holding customer details, personal data or compliance evidence takes on obligations around security, retention and audit that nobody planned for when it was built. The application did not change its purpose overnight, but the responsibilities attached to it did.
Owning the process is not the same as owning the software
This is where the difference between owning a business process and owning the application underneath it becomes worth considering.
Every organisation needs to own its process. It needs to decide what information is collected, who does the work, what rules apply and what the completed record should contain. Those decisions cannot sensibly be handed to a software supplier.
The question is how much of the software underneath that process the organisation also wants to own.
With an internally developed application, it owns both: the way the process is configured and the application that makes it possible, including its architecture, its ability to scale and its ongoing support. That can be valuable where the application is important or individual enough to justify complete control.
A product such as WorkMobile divides those responsibilities differently. The organisation still owns its forms, workflows, users, approvals and outputs, but the mobile application, offline framework, synchronisation and the architecture needed to support growing numbers of users remain part of the product we maintain.
Neither model removes responsibility. They simply place it in different places.
For an organisation with a mature internal development team, owning the whole application may be perfectly normal. For a department that simply wanted to replace a spreadsheet three years ago, discovering that it now owns a small but important software system, one that is expected to support hundreds of people, can come as more of a surprise.
Signs your small app has become a business system
I do not think the lesson is that organisations should avoid building small applications. Some of the most useful internal software began that way, and low-code platforms have made it possible to solve problems that might otherwise have gone unresolved for years.
What is useful is recognising when an application has crossed the line. A few signs worth looking out for:
· People would notice within a day if it stopped working.
· It is used by far more people than it was originally designed for.
· Other systems or processes depend on its data, such as invoicing, reporting or job management.
· It holds customer, personal or compliance information.
· Only one or two people can change it, and nothing much is written down.
· Changes now feel risky, or requests are met with “it wasn’t really built for that”.
If several of these apply, the application is no longer a small app, whatever it looks like.
Ask the question before the app becomes important
The question I would ask is not whether a small application might eventually become important. Quite a few of them will.
I would ask whether the organisation knows what will happen if it does.
Was it built for the number of people who now use it? Who will understand it in three years? Who can change it safely? Who supports it if the original developer has moved on? And at what point does something that began as a useful departmental app need to be treated as a proper business system?
Those questions are much easier to answer before the organisation discovers how many people now depend on it.
This article is part of a series exploring the themes in WorkMobile's white paper, Power Apps Can Build Almost Anything. But Should It?
