Service 04 — Mobile

Built for the network
your users actually have.

An app demoed on office wifi tells you nothing. Ours are tested where they will be used — a mid-range Android in a tier-3 town, a collections agent in a basement, a customer with two bars of signal and 4% battery. That is where adoption is won or lost.

Offline-first Biometric & device binding Store review first time Low battery draw
Discuss your app What we build
What we build

Two audiences, very different apps.

A customer app is judged on polish. A field app is judged on whether it works when nothing else does. We do not confuse the two.

M/01

Customer apps

Account view, statements, payments, requests and support in an interface a first-time user gets through without help. Reading live from your core system, so the balance shown is the balance owed rather than last night's copy.

Live balancesIn-app payments
M/02

Field-force apps

Visit plans, customer details, receipt capture, photo proof and GPS stamps — all working with no signal and syncing when it returns. Bluetooth thermal printing so the customer walks away with a receipt in hand, not a promise.

Offline captureThermal printing
M/03

Agent & partner apps

Lead submission, document upload, commission statements and wallet balance for DSAs, business correspondents and retail agents. Scoped so an agent sees their own book and nothing beyond it.

Commission viewScoped data
M/04

Onboarding & KYC flows

Document capture with edge detection and quality checks that reject a blurred photo at the point of capture instead of three days later. Video KYC, liveness detection and penny-drop verification inside the same journey.

LivenessQuality checks
M/05

Rebuilds & rescues

An app that crashes, drains battery or gets abandoned by its users. We start with a two-week audit covering crash telemetry, store reviews and actual field observation before recommending a fix or a rebuild.

Crash auditField observation
M/06

Release & store management

Signing, provisioning, phased rollouts, crash monitoring and store listing work. Enterprise distribution through MDM where the app is internal and should never appear in a public store at all.

Phased rolloutMDM distribution
Where apps fail

Four reasons rollouts get abandoned.

When a client tells us the last two apps were rolled out and quietly dropped, the cause is almost always on this list. None of them are about features.

If an agent loses one entry to a dropped connection, they go back to paper and never return.

It assumed a connection

Offline is designed in, not patched on. The visit, the receipt, the photo and the GPS fix are written locally and queued. Sync rules and conflict resolution get agreed with your operations head before we build them, because the right answer depends on your process rather than on convention.

Nothing is lost to a dead zone

It drained the battery by 2pm

Continuous GPS polling and chatty background sync will flatten a phone before the shift ends, and a field agent with a dead phone stops using the app permanently. We batch location, back off sync intelligently, and measure battery draw over a simulated full working day before release.

Measured over a full shift

It was tested on the wrong phone

Your field team is not carrying flagships. We test on the actual device profile in use — often 3GB RAM and two Android versions behind — and we ask for that list in discovery. An app that is smooth on the developer's phone and stutters on the agent's is a failed app.

Tested on real device profiles

It needed training nobody got

A hundred field staff will not read a manual. Screens are designed around the single task at hand, large touch targets for use while standing, and the common path completable in as few taps as we can manage. We watch real users attempt it before launch, not after.

Observed with real users
Platform choice

Cross-platform or native — it depends on the job.

Anyone who recommends the same answer for every app is selling their comfort zone. Here is how we actually decide.

ApproachBest whenTrade-off
Flutter Field and agent apps needing identical behaviour on both platforms, heavy custom UI, and one team maintaining it. Larger install size. Newer platform features arrive a little later.
React Native Your web team already writes React and will maintain the app after handover. Fast iteration on content-driven screens. Native modules needed for heavy device work like advanced camera handling.
Swift (iOS) iOS-first consumer products where interface polish and platform conventions are the product. Separate codebase and separate team from Android.
Kotlin (Android) Deep device integration — background services, printing hardware, aggressive battery optimisation, MDM. Separate codebase. Usually paired with Swift, which doubles maintenance.
For most enterprise work we recommend Flutter or React Native, then drop to native modules only where the device demands it. Two full native codebases are worth the cost less often than people assume.
Proof

Two failed rollouts, then one that stuck.

Collections · 400-person field force 🇮🇳 India · 7 months · Under NDA

A field app that worked where the network did not

The problem

Two previous apps had been rolled out and abandoned. Agents in tier-3 towns lost connectivity mid-visit, the app dropped the entry, and they went back to paper receipts within a fortnight. Head office was reconciling cash deposits against handwritten books four days later.

What we did

Rebuilt offline-first in Flutter. Visit, receipt, photo and GPS fix are written locally and sync when signal returns, with conflict rules agreed with the recovery head. Receipts print to a Bluetooth thermal printer at the doorstep. Battery draw was measured across a simulated eight-hour shift on the exact handset model the agents carry.

94%
Daily active agents
4d → 1d
Cash reconciliation lag
+18%
Visits per agent per day
Before you call

Common questions.

Ask something else

Ten to fourteen weeks for a focused field app on one platform. Sixteen to twenty-four for a customer app with payments, KYC and both stores. Store review adds one to two weeks at the end, and we build that into the plan rather than discovering it. If your backend APIs do not exist yet, that work runs in parallel and extends the timeline.

Yes, under your developer accounts — never ours, because an app published under a vendor account is a hostage. We handle signing, provisioning, store listings, privacy declarations and the review process. Rejections happen; we have seen most of the common reasons and design around them, which is why first-pass approval is the norm rather than the exception.

Usually. We start by reviewing your APIs for what the app will need — particularly around pagination, incremental sync and conflict handling, which most existing APIs were not designed for. Sometimes a thin sync layer between app and backend is cheaper than changing the core system, and we will tell you which is which.

Device binding so credentials only work on the registered handset, biometric or PIN unlock on every launch, encrypted local storage, and remote wipe of cached data on the next connection. For collections work we also cap how much customer data is held locally — an agent's phone should carry today's route, not the whole book.

Next step

Tell us which phone
your team carries.

Forty-five minutes with a mobile architect. Bring the device models, the connectivity reality and what went wrong last time. You will leave with a rough scope and a budget band.

Book a discovery call See the collections product