Service
Mobile Apps and PWAs
Installable applications for field teams and customers, built as progressive web apps or native where the hardware demands it, with offline behaviour designed rather than assumed.
The problem
What usually goes wrong
Field work happens where the signal does not. A technician in a basement, a driver in a car park, a crew on a site with one bar: the application either holds the work or loses it.
The other failure is procedural. An app ships to a store, then a fix takes a week to reach users because of review queues, and half the fleet is on an old version.
Deciding between a progressive web app and a native build is a technical question with a cost attached, and it should be answered before the design starts.
Scope
What we deliver
Platform decision, written down
Which hardware the app needs, which distribution model fits, and what each choice costs in build time and maintenance.
Installable progressive web app
Added to the home screen, launched without browser chrome, cached for offline use, and updated the moment you deploy.
Offline capture and sync
Work created without a connection is stored locally, queued, and reconciled on reconnect with a defined conflict rule.
Device capability use
Camera capture, geolocation, file handling and push notification where the platform allows it and the job needs it.
Interfaces built for gloves and sunlight
Large targets, high contrast, short paths to the two or three things a field user actually does.
Release process
For store distribution, the build pipeline, signing and submission steps documented and handed to you.
Method
Technical approach
We start by listing the hardware and platform features the application genuinely needs. Most field applications need camera, location, storage and notification, all of which a progressive web app can reach. Bluetooth peripherals, background location and deep operating system integration push a project towards native.
Offline is designed as a data problem. Every record type gets a rule: create offline and sync, read only when offline, or block. Local writes carry a client generated identifier so a retry cannot duplicate them, and conflicts resolve by a stated policy rather than last write wins by accident.
The service worker caches the application shell and the reference data a user needs, with an explicit version and an update path that does not strand someone mid job.
Interfaces are built for one handed use at arm length. Targets clear 48 pixels, contrast is set for outdoor light, and the primary action on each screen is unambiguous.
Battery and data use are treated as features. Sync batches rather than chatters, images are compressed on device before upload, and background work is scheduled rather than continuous.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Platform recommendation with the reasoning and the cost of each option
- 02Installable application with manifest, icons and offline shell
- 03Local store and sync queue with conflict resolution
- 04Camera, location and file capture where in scope
- 05Push notification setup where the platform supports it
- 06Field tested interface at WCAG 2.2 AA
- 07Build and release documentation, including store submission steps where applicable
- 08Source code, IP assignment and deployment guide
Related
Systems this service builds
- Mobile Apps and PWAsInstallable applications for staff in the field and customers on the move, with a local store, a sync queue and interfaces designed for one hand and poor light.
- Field Service ManagementDispatch, routing, mobile job capture and invoicing for businesses whose work happens at the customer address rather than in an office.
- Customer and Client PortalsA logged in area where your customers see their own status, documents, invoices and history, which removes the phone calls that only exist because they cannot.
FAQ
Questions people actually ask
Do we need an app store listing?
Only if discovery through the store matters to you, or you need a capability the web platform does not expose. A progressive web app installs from a link, which suits internal and field tools.
What happens to work created with no signal?
It is written to local storage with a client generated identifier, queued, and sent on reconnect. The user sees what is pending and what has synced.
How are sync conflicts resolved?
By a rule set per record type during design. Common choices are server wins for reference data, client wins for field captured work, and a review queue for anything financial.
Will it work on older devices?
We set a supported device and browser floor during planning and test against it. Field fleets are usually older than office hardware, so that floor is set from your actual devices.
Can it use the camera and scan codes?
Yes. Camera capture and barcode or QR scanning work in an installed progressive web app on current mobile platforms.
Who holds the developer accounts?
You do. Where store distribution is in scope, the listings and signing credentials belong to your accounts, and the submission process is documented for your team.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.