Mobile
In their pocket. On the job.
iOS, Android and cross-platform apps — for the customers who live on their phones, and the crews who never sit at a desk.
What we build
Apps with one clear job
Native iOS and Android apps
Cross-platform apps from one codebase
Customer-facing apps — booking, ordering, accounts
Field and technician apps for staff on site
Offline-capable apps that keep working without signal
App Store and Play Store submission, handled
Industries
Where mobile earns its keep
The industries where a phone in the field beats a computer at the office.
Our approach
An app has to earn the home screen
An app is a bigger ask than a website — people have to install it, keep it, and open it again. So before anything gets designed, we find out what the day actually looks like: where the phone comes out, what gets written down, and what gets re-typed later.
If the honest answer is that a website would do the job, we'll say so. When an app is the right call, it's because there's work only a phone in a pocket can do — a customer booking without ringing, or a crew capturing the job where it happens instead of writing it down twice.
How we build
Understand first, build second
Understand the day
Where the work happens, what the phone has to do there, and what happens when there's no signal.
Scope and price
A written scope and a fixed price, agreed before anything is built.
Build in stages
Working builds on real phones early — not mock-ups you can't tap.
Test and hand over
Store listings, developer accounts and code, all in your name.
We use AI to move faster. We review everything it writes, and we test for the vulnerabilities it introduces.
See the full processHow we'd approach it
A worked example
No mobile case study to show yet — so here's the thinking, in the open.
A field service team fills in paper job sheets on site. Every evening someone re-types them at the office — hours behind, with the photos on one phone, the measurements on another, and one sheet still in the van.
We'd spend a day where the paper lives: what a job sheet holds, who fills it in, and what the office does with it after. The first version would replace the sheet and nothing else — job details, photos, a signature, done on the phone before the technician leaves the driveway.
It would work offline, because job sites have bad signal, and sync when it comes back. The office would see jobs as they close, not the morning after. Nothing else gets built — no dispatch, no invoicing, no inventory — until the paper sheet is actually gone.
A worked example, not a case study — we haven't built this app for a client. It's how we'd think about yours.
Why Latchford
Four promises, in writing
Fixed price, agreed before we start
Written scope, so you know what you're getting
You own everything — code, domain, and accounts
We're here after launch, not just until it ships
Tell us what you're trying to get done.We'll tell you what it takes.