Mobile as part of a system, not as a second system.

The app is usually the part of an existing platform that has to work while somebody is standing in a warehouse aisle, at a barrier, or in a tower lobby.

  1. 01What happens offline
  2. 02What syncs
  3. 03What the device adds
  4. 04Who releases it

We have not published a named mobile deployment. Every other service line on this site names a system that is running; this page describes how we approach the work and what the hard parts are, and it stops there. Ask us for the mobile work we have delivered and we will tell you what it was and who it was for, subject to their permission.

Where mobile projects go wrong

Three of these four are the same problem: the network was assumed.

  • It assumed connectivity

    It works in the office and fails in the aisle, the basement and the yard, which is where the work happens.

  • Two sources of truth

    The app kept its own copy, the server kept another, and there was no rule for which one wins.

  • A second product by accident

    The app drifted from the platform it was meant to extend and now needs its own roadmap, its own team and its own bugs.

  • Nobody owns the release

    Store review, signing keys and staged rollout were discovered a week before launch.

The decisions that have to be made first

All six are cheap now and expensive after the first release.

  1. Mobile strategy

    Whether this should be an app at all. A responsive web application is often the correct answer, and it is the answer we will give when it is.

  2. React Native

    One codebase across iOS and Android where the app is an extension of a system, which is most of the time. Native where a device capability genuinely requires it.

  3. Backend integration

    The same API the web client uses, versioned, because a mobile client cannot be forced to upgrade on your schedule.

  4. Authentication

    Sessions that survive a background kill and a token that can be revoked from the server when a device is lost.

  5. Notifications

    Push as an operational signal with a delivery expectation, not as a marketing channel bolted onto an operations app.

  6. Testing and deployment

    Device matrix, staged rollout, and a crash reporting path that reaches a person rather than a dashboard nobody opens.

What we build

Extensions of a system that already exists, on the device the work is already done on.

  • Field and floor applications

    Capture at the point the event happens, rather than a form filled in afterwards from memory.

  • Operator companions

    A screen for the person moving around the site, showing the same record the desk sees.

  • Customer and resident apps

    Where the customer’s view and the operator’s record are the same record.

  • Offline first data sync

    A defined conflict rule, decided before the build, not discovered in the field.

  • Device integration

    Camera, scanner, location and printer, treated as hardware that fails rather than as APIs that return.

  • Release management

    Signing, staged rollout, store review and a way to turn a bad build off.

OutcomeThe same record on the phone as on the floor, and a defined answer for what happens offline.
CapabilitiesReact Native applications · iOS and Android delivery · Offline first data sync · Push notifications · Device integration · App store release management

What we build it on.

Grouped by what it does rather than shown as a wall of marks, and short enough that your own team can judge whether they could take it over.

Mobile
React NativeiOSAndroid
Backend
PythonDjangoFastAPINode.js
Data
PostgreSQLMySQLRedisData modelling
Cloud
AWSDockerCI/CDInfrastructure as code

Questions we get asked.

The objections specific to this line, answered here rather than in a first call.

Should this be an app or a mobile web page?

A responsive web application is the right answer unless you need one of three things: work that continues with no connection, a device capability the browser cannot reach, or a home screen presence that the business actually depends on. We will say which of the three applies, including when none of them does.

React Native or native?

React Native where the app extends a system you already run, because one codebase and one set of business rules is worth more than the last few percent of platform polish. Native where a device capability or a performance requirement genuinely demands it.

What happens to data captured with no signal?

It is written locally and reconciled on reconnect against a conflict rule agreed before the build. The rule is written down, because the alternative is that it gets decided implicitly by whichever write happens to arrive second.

Where to go next

You do not need to arrive with a perfect technical specification.

Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.

Start your build