01
Field and crew apps
Job details, checklists, photo capture and sign-off, built for speed over completeness.
Build
Apps built for the real conditions.
A field app is not a desktop app on a smaller screen. It gets used one-handed, outdoors, in a hurry, sometimes with gloves on and usually with patchy signal. Designing for that is the difference between an app that gets used and one that gets ignored.
Why it matters
The short version.
The context a mobile app runs in is nothing like the one it was designed in. It gets opened outdoors in bright sun, one-handed, by someone wearing gloves, on a device three generations old, with one bar of signal and nine percent battery. Designing on a laptop in an office makes every one of those conditions invisible.
That is why we test on real devices in real conditions rather than in a simulator. A tap target that is comfortable on a desk is not comfortable in a truck. A sync strategy that works on office wifi loses data in a basement. These are findable problems, but only if you go and look.
The first question is always whether an app is the right container at all. App stores add friction at install, review delay at update, and two platforms to maintain forever. A well-built mobile website avoids all three. There are good reasons to need an app — offline, hardware access, notifications people actually want — and if none apply, we will say so.
A tap target that is comfortable on a desk is not comfortable in a truck.
Is this you?
You probably need this if…
- Your field team still submits work on paper or by text message
- You have an app and the crews avoid opening it
- Data arrives a day late because it gets entered back at the office
- Your customers keep asking whether there is an app
What's involved
The actual work.
No two engagements are identical, but this is the shape of it.
02
Offline-first where needed
Work continues without signal and syncs when it returns — with conflict handling that does not lose anyone's work.
03
Customer-facing apps
Booking, account access and notifications that people do not immediately mute.
04
Store submission
App Store and Play Store setup, review process and release handled.
What goes wrong
Mistakes worth
avoiding.
Named plainly, because most of them are easier to avoid than to undo.
-
Porting the desktop screen
A phone is not a small monitor. The task has to be re-thought for one thumb and a short attention window, not compressed.
-
Assuming connectivity
If your users work in basements, rural sites or moving vehicles, offline is a core requirement rather than an enhancement — and retrofitting it is close to a rewrite.
-
Testing only on new flagship phones
The team tests on the newest device they own. The crews are using whatever the company bought four years ago, and it behaves very differently.
How it runs
Start to finish.
Each phase ends in something you can open, click or read.
-
01
Go where the work is
We spend time with the people who will use it, on site where we can.
-
02
Prototype on a real device
Held in a hand, outdoors, not viewed on a laptop.
-
03
Build and test
On a spread of real devices, including older and cheaper ones.
-
04
Release and iterate
Staged rollout, then fixing what real use reveals.
Deliverables
What you walk
away with.
Yours to keep, whatever happens next.
Published iOS and Android apps
Source code and store accounts in your name
An offline and sync strategy you can explain
Crash and usage monitoring configured
Questions
Worth asking.
Anything else — email hello@haddon.software and a human replies the same business day.
Usually cross-platform, because one codebase for two platforms is cheaper to build and much cheaper to maintain. We go native when the app genuinely needs it, and we will explain which case you are in.
Often not. A well-built mobile website avoids app store friction entirely and updates instantly. We will tell you when that is the better answer, even though it is a smaller project for us.
Store review typically takes a day or two. We plan release cadence around that, and keep anything urgent behind a switch we can flip without a new release.
Yes — developer account setup, listing copy, screenshots, privacy declarations and the review process. First submissions get rejected more often than people expect, usually for fixable metadata reasons, so we budget for a round of it.
Forced updates are disruptive when someone is mid-job, so we generally build a soft prompt plus a remote switch for anything genuinely urgent. That way a critical fix does not wait on store review or on users noticing an update badge.
Related
You might also need…
Want to talk it through?
The first call is free, runs about thirty minutes, and you'll get a straight answer about whether we're the right fit — including when we're not.