Mobile app development
An app earns its place when the work happens away from a desk.
For a service business, that is most of the work. The people who know what happened on the job are the people standing in someone's basement, and everything downstream — the invoice, the follow-up, the next appointment — waits on them getting back to the office.
What it actually does
Six jobs a well-built app does on day one.
Not features. These are the specific places where a business stops losing time the week the app goes live.
Dispatch and the day sheet
Every tech opens the app and sees today: which jobs, in what order, at which address, with the notes from last time. Changes made in the office appear on the van's phone.
Job status, live
On my way, on site, finished. Each tap updates the office and, if you want it to, the customer — which is the single biggest reduction in inbound phone calls we see.
Photos and notes from site
Before and after, the model number on the unit, the thing the customer was warned about. Attached to the job, not sitting in someone's camera roll.
Sign-off and invoicing
Sign on the phone, invoice generated from the work recorded, sent before the van leaves the drive. Cash arrives days earlier for no extra effort.
Customer booking
A customer-facing app or booking flow that offers real slots from your real schedule, so a booking made at 11pm is a job on the board the next morning.
Time and materials
Hours and parts captured against the job as they are used, so job costing is a report you read rather than an evening you spend reconstructing the week.
Built for real conditions
The details that decide whether your crew actually uses it.
It works with no signal
Basements, plant rooms, rural calls. The app holds everything locally and syncs when the phone finds a connection. An app that needs bars is an app that gets abandoned in month two.
It works with gloves and one hand
Big targets, few taps, no dense forms. If a tech has to take a glove off and squint, they will write it on a scrap of paper instead and you are back where you started.
It respects the battery
A phone that dies at 3pm is a safety and scheduling problem. Location and syncing are used deliberately, not left running because it was easier to build that way.
It is learnable in ten minutes
New hires and seasonal staff have to pick it up on their first morning without a training session. That is a design constraint we hold ourselves to, not a nice-to-have.
Platforms
You do not need to have an opinion about this.
One of the more common ways to waste money on an app is to choose the technology before understanding the job. We pick the approach after scoping, based on what the app has to do, who has to use it, and what you already run.
- Both major phone platforms, unless there is a reason not to
- Tablet layouts where the work suits a bigger screen
- A browser version when staff also work at a desk
- Published under your own developer accounts, which you own
- No proprietary platform you can only leave by rebuilding
- The source code is yours at the end of the project
The delivery arc
From first call to a live app.
-
Scoping
We walk through a normal week and find where it leaks. Free, and usually the most useful half hour of the project.
-
Proposal
What the app will do, in order of importance, with a fixed price and a delivery window. You decide whether to go ahead.
-
Design
Screens you can click through before anything is built, so disagreements happen while they are still cheap.
-
Build & pilot
We build in stages and put it on real phones with one or two willing techs. Their complaints are the most valuable feedback in the project.
-
Release & support
Store submission, rollout to the team, and a retainer for the changes that always follow the first month of real use.
Straight answers
The questions we get asked first.
How long does an app take?
A focused first version is usually a matter of a few months rather than weeks or years. We will give you a specific window in the proposal, based on your scope rather than an average.
What does it cost?
It depends entirely on what the app has to do, so any number quoted before scoping would be a guess. We quote a fixed price in writing after the scoping call, and it does not move unless you change what you want.
Do we have to replace the software we already use?
Usually not, and usually you should not. If your accounting or scheduling tool works, the better project is often connecting to it rather than replacing it.
What happens if we stop working with you?
You keep the code, the app store accounts and the data. We will hand over to whoever comes next. There is no version of this where you are stuck with us because leaving is too painful.
We are not sure an app is the answer.
Then say that on the call. Sometimes the answer is a web app, or an automation between two tools you already own, or nothing at all. We would rather tell you that than sell you an app you do not need.
Tell us what's slowing the business down.
A short call, a written scope, a fixed price. No obligation, and no sales sequence afterwards.