Offline as the default state
The app assumes no connection, queues everything locally, and syncs with a defined conflict rule. Signal becomes a bonus rather than a requirement.
Mobile App Development
BuildMost businesses do not need an app. Some genuinely do.
Native and cross-platform apps built where a mobile app is the right answer — offline capability, device hardware, or a workflow people run all day in the field.
Typical stack
- React Native
- Expo
- Swift
- Kotlin
- SQLite
- TypeScript
- PostgreSQL
Written for: A business that has been quoted for an app and is not sure whether they need one.
Who it is for
Is this built for a business like mine?Built for workflows that genuinely live on a phone.
An app is justified by three things: working without signal, needing the device hardware, or being used many times a day by the same people. If none of those apply, a fast mobile website will beat an app on cost and adoption.
What we see
Technicians work in basements and roof spaces with no signal, and paperwork is completed in the van afterwards from memory.
What we build
An offline-first job app — checklists, photos, signatures and parts used — that syncs when signal returns and resolves conflicts predictably.
The detail that matters
Offline is the default state, not an error condition handled at the end.
What we see
Proof of delivery is a photo on a personal phone, sent by text, filed by nobody.
What we build
Driver apps with scanning, capture, route awareness and proof of delivery written straight into the TMS.
The detail that matters
Battery and data cost are treated as design constraints — a driver app runs ten hours.
What we see
Visit notes are written on paper in the field and typed up at the end of a shift, hours later.
What we build
Point-of-care capture on a device, with data handled to the boundary the service operates under.
The detail that matters
Device-level data handling is designed to the constraint from day one.
What we see
Stock movements are recorded on a clipboard and entered into the ERP the next morning.
What we build
Scanner-driven apps for picking, counts and movements, writing to the ERP as it happens.
The detail that matters
Built for gloved hands and a scanner, not for a designer’s thumb on a clean phone.
And who it is not for
If the goal is a customer-facing app to increase engagement with a service people use monthly, it will be downloaded once and deleted. We will say that on the first call and propose a fast mobile web experience instead.
The problem
Do they understand what is actually going wrong?The app gets built. Then it gets deleted.
Consumer apps are downloaded and abandoned within a week, and internal field apps are quietly worked around because they are slower than the paper they replaced. Both failures share a cause: the app was specified as a feature list rather than designed around the conditions it would actually be used in.
It needs a connection, and the work happens where there is none.
It duplicates the website with a worse layout and an install step.
Field staff use it because they must, and keep the paper as the real record.
It was built for one platform and now needs the other, which means starting again.
What we build
What exactly would I be buying?We argue about whether you need one first.
The most valuable part of this engagement is often the recommendation not to build. Where an app is right, four things decide whether it gets used, and all four are design decisions rather than features.
Designed for the conditions
Gloves, sunlight, one hand, a cracked screen, ten hours of battery. The constraints are named before layout starts.
One codebase where it is honest
React Native where the app is workflow-driven; native where the hardware or performance genuinely demands it. We tell you which this is and why.
Release you can survive
Store submissions, staged rollout, crash reporting and over-the-air updates for the parts that allow it — set up before launch, not after the first bad review.
How it works
How does this actually function?What happens when there is no signal.
Offline is not an error state to handle at the end. It is the assumption the data layer is built on, and sync is a designed behaviour with a rule for every conflict.
Act
Queue locally
Detect signal
Sync
Resolve
Conflict → ruleConfirm
Actions complete instantly against local storage. The user never waits on a network they may not have.
Conflicts resolve on a rule agreed with you during design — last-write, server-wins or held for review, per record type.
The queue survives a force-quit, a flat battery and an app update. It is storage, not memory.
What changes
What is different afterwards?What is different afterwards.
It gets used in the field
Built around signal loss, gloves and battery life, so it is faster than the paper process rather than a compliance obligation.
Adoption without enforcement — the paper fallback stops being used.
Data arrives once, at the source
Captured where the work happens rather than re-entered later, which removes both the delay and the transcription error.
Records created in the field, not re-keyed at the office.
Shipping stays possible
Store pipelines, staged rollout and crash reporting configured before launch, so the second release is routine.
Releases shipped by your team after handover.
How we deliver
How does this start, and what do I get at each step?Six stages, and every one has an exit.
You can stop after any stage with something useful in hand. That is the point of naming the artefacts rather than the activities.
- 01
The app question
Does this need to be an app? Offline, hardware, or daily repeated use. If none apply we recommend mobile web and scope that instead.
- Written recommendation, including "do not build"
- Platform decision with reasoning
- Cost comparison against mobile web
- 02
Field study
We watch the work happen in the place it happens. Every unused field app was designed from a description of the job rather than the job.
- Observed workflow, documented
- Environmental constraints
- The current workaround, and why it exists
- 03
Data and sync design
What is stored locally, what syncs, and what happens to every kind of conflict. Decided before any screen is built.
- Local data model
- Sync and conflict rules per record type
- Offline behaviour specification
- 04
Build
Screens and workflow against the real data layer, tested on real devices from the first week.
- Test builds on real devices
- Offline scenarios verified
- Crash reporting live
- 05
Field pilot
A small group, real jobs, real conditions — including the basement with no signal.
- Pilot findings from actual users
- Battery and data measurements
- Revised workflow
- 06
Release and handover
Store submission, staged rollout, and the accounts and pipeline transferred to you.
- Apps published under your developer accounts
- Release pipeline documented
- Recorded training session
Questions
But what about the thing that worries me?The questions people actually ask.
Do we actually need an app?
Often not, and the first stage exists to answer that honestly. The test is whether the work happens offline, needs device hardware, or is repeated many times a day by the same people. If none of those hold, a fast mobile site wins on cost, on reach and on adoption.
React Native or native?
React Native for workflow-driven apps where one codebase across both platforms is the dominant economic fact. Native where sustained camera work, background processing or platform-specific hardware makes the bridge a real cost. We make the call during the platform decision and show the reasoning.
What about the app stores?
We handle submission and review under your developer accounts. Review timelines belong to Apple and Google, so we build in the buffer rather than promise a date we do not control.
How do you handle updates after launch?
Over-the-air updates for the JavaScript layer where the platform permits it, so content and logic fixes ship without a store round trip. Native changes go through review. Both paths are set up before launch.
Who owns the app?
You do — code, store listings and developer accounts, all in your name from the start.
The other half
Field data has to be checked by someone.
Capture in the field produces a stream of records with photos, signatures and free text attached, and a share of them need review — the illegible signature, the count that does not reconcile, the note flagged for follow-up. That verification queue is work, and it is work we staff.
Data Entry & ProcessingStart
What is the next step?Tell us the problem, not the specification.
A short call is usually enough to say which half of the business your problem belongs to, roughly what it costs, and whether it is worth doing at all.
Related services
- DevelopmentWebsite DevelopmentFast, accessible, search-legible websites built on a performance budget — and handed over as a codebase you own, not a platform you rent.
- AI EngineeringAI DevelopmentApplied AI systems built with retrieval, evaluation and observability from the first commit — because those decide whether it still works in month six.
- AI EngineeringAI AgentsAutonomous agents that plan, call real tools against real systems, and leave a trace of every action — with human approval gates on anything consequential.