Mobile Apps

I design and build mobile apps for operations rather than for app-store ambitions: field-team tools, customer portals, delivery and collection apps — cross-platform, offline-first where the network demands it, and wired into the systems where your data actually lives.

Why most SME apps fail

Every growing business is one confident quote away from an expensive app nobody opens. The failures rhyme:

Built like a startup product rather than a business tool, with onboarding flows and feature breadth nobody needed. Assumes connectivity the users do not have — designed on office wifi, deployed to a warehouse with one bar. Organised around screens rather than tasks, when the field team repeats three actions forty times a day and everything else is decoration. And disconnected from the real systems, so staff enter data twice and quietly revert to paper within the quarter.

The common thread: the app was specified by people who would never use it, for a workflow nobody watched.

What I do differently

• The three-task audit first. What must this app do brilliantly? Almost always three things, done forty times a day, by someone standing up and in a hurry. Everything else becomes a later tab or does not get built.
• Offline-first where it matters. Capture now, reconcile when the network returns, conflicts resolved by rule rather than by luck. The DR Congo field-operations education applies directly — build for the network you have, not the one in the demo.
• Integration as the premise. Into your ERP, CRM or ledger, so the app is a window onto existing truth rather than another silo producing its own version of it.
• Cross-platform build. One codebase, both stores, a budget that leaves room for the second and third iterations — which are the ones that make an app good.
• Store submission and the compliance paperwork, plus crash monitoring so problems surface from telemetry rather than from a supervisor’s phone call.

The design bar

WhatsApp. That is the honest benchmark, and it is a high one: enormous target areas, almost no decisions per screen, instant feedback, and complete tolerance for a dead network.

Practically that means an interface with three buttons and a camera, labels in the language the crew actually speaks, and a sync indicator that tells the truth. It also means resisting the features that look good in a specification and add a step to a task performed forty times a day — every extra tap is multiplied by the number of repetitions, which is the arithmetic most app design ignores.

When I will tell you not to build one

If the process is not yet stable on paper, an app will encode the confusion in software and make it harder to change. If the real problem is that two systems do not talk to each other, an integration is cheaper than an app. And if fewer than a handful of people will use it daily, a well-built mobile web page usually serves better than anything requiring installation and store approval.

Saying that costs me the project and saves you the expense, which is the trade this whole site is built on.

What the first version should contain

Less than you think. The three tasks, done excellently, shipped in weeks rather than months — then watched in real use, because the field will teach you things no specification anticipated. The second version is where the app becomes genuinely good, and it only exists if the first one left budget for it.

That sequencing is why fixed scope on version one matters. An app that consumes the entire budget arriving perfect on paper is worse than one that arrives narrow and improves twice.

How offline-first actually works

The phrase gets used loosely, so here is what it means in the apps I build.

Every action completes locally first. The user taps, the record is written to the device, and the interface responds immediately — with no spinner waiting on a network that may not answer. Sync happens afterwards, invisibly.

A sync state the user can see and trust. Pending, synced, failed — visible per record rather than as a global indicator, because a crew member needs to know whether this delivery has reached the office, not whether the app in general is happy.

Conflicts resolved by rule, decided in advance. When two devices modify the same record, the resolution is a business decision rather than a technical accident: last-write-wins for status updates, additive merging for collections, and explicit escalation for anything involving money.

Bounded queues. A device offline for three days should not lose data on day four. Storage limits are planned for rather than discovered.

What the second version usually adds

Consistently, across deployments: photographs in more places than anyone specified, because evidence ends disputes. A search that works on partial input, because names get spelled differently in the field. And an offline reference — the price list, the route, the customer’s history — that the crew previously carried on paper.

None of those appear in first specifications. All of them come from watching real use for a month, which is the argument for shipping narrow and keeping budget.

The corollary is worth saying to anyone commissioning an app: the specification you are about to approve is a hypothesis, and the field will amend it. Budget for the amendment rather than for a perfect first guess, because nobody has ever produced one. The teams that accept this ship useful software; the ones that resist it ship a specification and then argue about whose fault the gap was.

What you should bring to the first call

The names of the three people who will use this every day, and what they currently do instead. Not a feature list — the actual sequence, including the paper, the phone calls and the WhatsApp messages that hold it together today.

That conversation usually reshapes the brief within twenty minutes, and it occasionally ends with the honest conclusion that an app is the wrong tool. Both outcomes are worth the call.

Related reading

/products/field-operations — the productised version of this pattern · /industries/logistics — drivers and deliveries · /industries/automotive — workshop job cards · /services/architecture — deciding what should exist at all

Describe the paper process

Tell me the one process your field team currently does on paper. That is the app; the rest is tabs. /contact — fixed scope, honest quote.