Contents7
Teams who work away from the office (technicians, drivers, travelling sales staff, site crews, estate agents on viewings) produce a large share of the information the business needs: what was done, what is missing, what the customer reported. Most of the time, that information travels badly. An internal app does not change their job; it changes the journey of what they know to the office.
In short
The problem is not the field, it is the journey of the information: paper, messaging, re-keying.
An internal app has information entered once, in the right place, with a reliable date and photos attached to the file.
It is only adopted if it is simpler than the notebook it replaces: few screens, few fields, designed with the teams.
It does not need a public store: a link is often enough, and Apple and Google both provide private distribution.
What gets lost between the field and the office
In many businesses, a piece of field information follows a four-step journey:
The journey of field information, without an app
- The note
In a notebook, on a paper form or as a phone photo.
- The send
In a messaging app, sometimes in the evening, sometimes never.
- The re-keying
Someone at the office copies it into the software.
- The filing
The photo and the text find the right file, or not.
Each step has its cost. Re-keying takes the time of someone who could be doing something else, and it introduces errors. Photos get lost in a group chat. The office learns a day late what the field knew in the morning. And when a customer disputes something, nobody can find the proof.
What the app changes
One entry, in the right place. The person in the field picks the file, ticks, photographs, sends. The information goes straight into the database, attached to the customer, site or property concerned.
A reliable date. The time of an entry can matter (a job, a delivery, an inspection). It must then be set by the server, not by the phone, whose clock can be changed by hand.
From the field
In Challenge Us, the server dates every entry
Challenge Us, a group-challenge app we built, computes the day of each entry on the server, in the participant’s time zone, and keeps every entry so the history stays verifiable. The same rule applies to a job sheet: a date that cannot be backdated.
The office sees it live. With a real-time database, a job’s status changes before the office’s eyes the moment the technician finishes it. Fewer calls asking “is it done?”.
Photos in the right place. This is often the first visible gain. At Palmora Property, a real-estate agency in Phuket that we work with, the team sorts a listing’s photos and changes its status in a small custom app added to the CRM that serves as its back office; details are in the Palmora case study.
What it takes for the team to use it
A field app competes with the notebook and the messaging app, which are simple, fast and familiar. It must do better on all three.
- Few screens, few fields. What is entered in the field must take a few gestures; the rest is completed at the office.
- Frictionless sign-in. No complicated password to remember on a shared phone. In Challenge Us, a first name is enough to start; email or a recovery code are optional.
- Designed with the teams. The people who will use it know where the notebook beats any screen. Having them test early, on a clickable prototype, avoids delivering an app they will work around.
- A benefit for them too. If the app only serves the office, it will be filled in reluctantly. If it saves the technician a call or a trip back to the depot, it will be adopted.
When the network drops
Cellars, rural areas, underground car parks: the field is often where the network is weak. There are two levels of answer.
- The interface opens without a network. An installable web app keeps its screens in cache and launches offline; this is explained in our PWA or native app comparison.
- Entries wait for the network to return. Saving on the phone, then syncing with no loss and no duplicates, takes real development work, and some back ends provide for it better than others: see Supabase, Firebase or your own server.
Full offline support is one of the decisions that most affects the price of an app. It should be decided on evidence (where do your teams lose the network, and for how long?), not as a precaution.
Distributing it without a public store
An internal app does not have to appear in the App Store or Google Play. There are three routes:
- A link to an installable web app. The simplest: the team opens the link, adds the app to the home screen, and updates arrive without reinstalling anything.
- A private app on iPhone. Apple provides custom apps distributed through Apple Business Manager to designated organisations only; according to Apple, they go through review before appearing in the organisation’s account.
- A private app on Android. Google Play lets you restrict an app to an organisation, which then distributes it to its managed devices; Google Play’s help describes the steps.
Key takeaway
For a first version, a link to an installable app is almost always enough. The stores’ private routes are justified when the app needs phone features the web covers poorly, or when the phones are managed by the company.
Where to start
- Follow one piece of information.
Take a frequent action (a job, a delivery, a viewing) and note each step of its journey to the office.
- Count the re-keying.
How many times is the same information copied, and by whom?
- Design the minimum.
The few screens that remove the most costly re-keying, nothing more.
- Test with the team.
On a prototype, then on a first installable version, before adding anything.
If software you already use does the essentials, the right answer may be a small app that plugs into it rather than a complete tool: the middle path described in custom-built or off-the-shelf. For the rest, our app development puts an installable version in your teams’ hands within the first weeks.
Frequently asked questions
Does an internal app need to be on the App Store?
No. An installable web app is distributed by a simple link and is often enough for an internal tool. If you need a native app, Apple and Google provide private distribution reserved for your organisation, without appearing in store search results. The choice depends on the phone features the app needs and on how your devices are managed.
Can a field app work without a network?
Its interface can open without a network if it is kept in cache. Saving entries offline and syncing them when the network returns is possible, but takes extra work so that nothing is lost or duplicated. Before planning it, check where and for how long your teams really lose the network: that evidence is what decides.
How do you get field teams to adopt an app?
By designing it with them and making it simpler than what it replaces: few screens, few fields, frictionless sign-in. Have it tested early by the people who will use it, and check that it saves them something, a call, a trip back to the depot, an evening report, not just the office.
Can the app connect to our existing software?
Yes, if that software offers a documented API: the app then sends its entries straight to the right file, with no re-keying. It is often the best solution when the software does the essentials well. Without an API, workarounds exist, but they make the integration less certain, and a good quote says so.
Sources
- Apple Developer, custom apps for business (new tab)developer.apple.com
- Managed Google Play help, publishing private apps (new tab)support.google.com
Jim · founder of Brain Plus AI
Also in web and mobile apps
Choose and price6 min
PWA or native app: which to choose for your business?
An installable web app (PWA) goes onto the home screen without going through the App Store or Google Play, and is enough in many cases, not all. Here is how to decide, and why we start with it.
Choose and price6 min
Business app: custom-built or off-the-shelf software?
Off-the-shelf software costs less as long as your way of working fits its boxes. Here are the signs that tip the balance towards custom, and the middle path that is often forgotten.
Choose and price6 min
App back end: Supabase, Firebase or your own server
Behind an app’s screens you need accounts, a database, files and rules. Supabase, Firebase and your own server answer this in three ways, and each commits you to different things.