App · Training

A training app staff can use on a phone, offline

Training material that lives in a PDF nobody opens is a cost with no return. The problem is rarely the content, it is that the content is somewhere inconvenient.

Who this is for: Built and run by us for our own group.

PWASupabaseOffline-capable

See it live, ORBIS Academy

The problem

New travel agents need to learn destinations, products and process. That knowledge existed, but it existed as documents, and documents on a laptop are not where somebody learns during a quiet ten minutes between calls.

Why a progressive web app rather than a mobile app

Publishing to the App Store and Google Play means two builds, two review processes, developer accounts, and an update cycle measured in days. For an internal training tool used by a known group of people, that is a great deal of cost for very little benefit.

A progressive web app installs to the home screen from a link, updates instantly when we publish, works on both platforms from one codebase, and needs no store approval. For internal tools this is almost always the right answer, and it is worth asking any agency proposing native apps why they are not proposing this instead.

What it does

  • Structured modules staff work through at their own pace
  • Progress that follows the person rather than the device
  • Content editable by the team, not requiring a developer
  • Installs to a phone home screen; usable in the gaps in a working day

What we would do differently

We built the content structure before watching anyone use it, and the first version had modules that were too long for the ten-minute gap they were designed to fill. That is an ordinary mistake and a cheap one to fix, but it would have been cheaper still to test with three people before writing all of the material.

The general lesson holds for any internal tool: the constraint you designed around should be verified with real users early, because everything else in the build depends on it being right. A feature you got wrong costs a day. A constraint you got wrong costs the project.

Why it is not in an app store

Worth spelling out, since "we need an app" is one of the most expensive assumptions a business can arrive with.

A native app on both platforms means two codebases or a cross-platform framework, two developer accounts with annual fees, a store review before every release, and a support tail of users running old versions because they never updated. For a consumer product with millions of users and a need for deep device features, that is all justified. For a training tool used by a known group of staff, it is a large recurring cost buying almost nothing.

The questions worth asking before commissioning any app: does it genuinely need the camera, offline storage, push notifications or background location? Is being in a store a real distribution channel for you, or just a badge? If the honest answers are no, a progressive web app does the job for a fraction of the money and updates the moment you publish.

The lesson worth stealing

The build was not the hard part, deciding it had to fit into ten spare minutes was. That single constraint determined the module length, the navigation and the decision to make it installable. Most projects benefit more from one honest constraint like that than from another feature.

Related case studies

Tell us what you need

Describe the project in a couple of sentences and we will come back with a fixed price and a realistic timescale. No obligation, and no sales sequence.

Start a build