Solution
Custom job management software for field teams
Quoting, scheduling, job tracking and costing for field teams, built around how your business actually runs rather than how a platform assumes it does.
Start with the workflow that costs you the most
Tell us what the process is and what it currently runs on. A senior engineer reads it and replies with either questions or a straight answer that we are not the right fit.
What is actually going wrong
Field businesses have real software options and most of them should use one. The established job management platforms handle quoting, scheduling, dispatch and invoicing, and for a business whose work looks like the industry average they are excellent value. Anyone telling a small contractor to commission custom software before they have tried one is not acting in their interest.
The problem is that the good ones are built around a particular shape of business, usually American residential service work with high job volume and short durations. If you run long projects with staged payments, subcontractors with their own rates, materials that get ordered against a job weeks before anyone attends, and retention held for months, you will spend a lot of time forcing your process into fields that mean something else.
The second problem is price at the wrong end. Per-user pricing designed for a firm with thirty engineers is uncomfortable for one with six, particularly when half of them need to do nothing more than mark a job complete and upload a photo.
Where either applies, a focused custom system is worth costing. Not a platform clone: the specific parts of your operation that bleed time, built to fit.
You will recognise some of these
- Jobs assigned by phone call or group chat, and sometimes forgotten
- You cannot tell whether a completed job made money until the accountant closes the month
- Materials ordered against a job with no record linking cost to that job
- Subcontractor rates and invoices tracked in a separate spreadsheet
- Photos and sign-offs sitting on the phones of whoever took them
- Quotes rebuilt from scratch each time because nothing carries over
- Staged payments and retentions tracked manually, and occasionally missed
- A platform you pay for that fits perhaps two thirds of how you work
What is included
- A job record that holds the whole life of a job: quote, schedule, attendance, materials, labour, photos, sign-off and invoice status
- Scheduling and assignment that works on a phone for the person receiving the job
- Time and materials captured against the job as it happens, rather than reconstructed later
- Job costing that compares quoted against actual, so you know which work is profitable
- Photo and document capture attached to the job, not to somebody's camera roll
- Customer sign-off captured on site
- Subcontractor records with their own rates and their own limited access
- Staged payments, retentions and invoice status tracked against the job
What is not included
Stated as plainly as the inclusions. A fixed price only means something if the boundary around it does.
- Full offline working. The app tolerates a weak signal, retries uploads and does not lose what was typed. Genuine offline synchronisation for teams with no signal for hours is a different architecture and a different price, and we will say so at scoping rather than after.
- Becoming your accounts package. Invoices can be pushed to the software you already use and payment status pulled back; the accounting itself stays where it belongs.
- Native app store applications. This runs in the phone browser, so a fix reaches your engineers the day it ships rather than after a review queue.
- Payroll, CIS or tax calculation. We track hours against jobs and hand them to the system that is certified to do the sums.
- Route optimisation and live vehicle tracking. Real products exist for both and they are better than anything worth building inside a thirty-day scope.
Tell us which workflow it is
A short description of the process and what it runs on now is enough to get a straight answer on whether this fits.
Try the platforms first
We would rather you spent a month trialling two established products than commissioned a build you did not need. They are mature, they cost a fraction of custom development, and for a large proportion of field businesses they are simply the right answer.
Go into the trial with your three most awkward recent jobs and try to run them through the product properly, rather than testing it with a simple one. The awkward cases are where the fit fails, and they are the ones that will cost you daily.
If you come out of that with a short list of workarounds you can live with, use the product. If the list contains the core of how you make money, then it is worth costing a build, and you will scope it far better for having done the exercise.
Job costing is usually the real reason
When field businesses commission custom software, the reason they give is scheduling and the reason it pays for itself is costing. Knowing which jobs, which clients and which kinds of work actually make money changes what you quote and what you decline, and most firms are running on an instinct that turns out to be wrong in at least one direction.
That requires capturing labour and materials against the job while the work is happening, which is a discipline problem as much as a software one. If entering time takes more than a few seconds on a phone, it will be done from memory on Friday and the numbers will be fiction.
So the design constraint is speed at the point of capture. Get that right and the reporting is straightforward, because the data is real.
Built for a van, not a desk
The people using this are on site, on a mid-range phone, often with poor signal and rarely with both hands free. A system designed on a desktop and handed to them will be abandoned within a fortnight, and they will go back to the group chat.
That means large touch targets, today's jobs one tap from opening the app, photo capture straight from the camera, and forms short enough to complete standing up. It also means it has to load fast on a weak connection, which is an engineering constraint rather than a preference.
The office view is a different design problem with different users, and it is fine for the two to look quite different. What matters is that they are the same data.
Common questions
Why not just use one of the big job management platforms?
You probably should, and we would suggest trialling two before spending anything with us. They are mature and cost far less than a custom build. The case for building appears when your work does not match the shape they assume, typically long projects with staged payments, subcontractors on their own rates, or materials ordered against a job well before attendance, or when per-user pricing is punishing for a team of occasional users.
Will our engineers on site actually use it?
Only if it is faster than what they do now, which for most field teams is a phone call or a message. That makes speed on a mid-range phone the primary design constraint, not a nice-to-have. Big targets, today's jobs one tap away, photos straight from the camera, and short forms. If updating a job takes longer than sending a WhatsApp message, it will not get used.
Does it work offline?
Partially, and it is worth being precise because full offline synchronisation is genuinely expensive to build and to keep correct. What is affordable is that the app tolerates a poor connection: forms retain what was entered, uploads retry, and nothing is lost when signal drops. If your teams routinely work with no signal at all for hours, say so at scoping, because that changes the architecture and the price.
Can it connect to our accounting software?
Usually yes. The common accounting products have documented APIs, so pushing invoices across and pulling payment status back is well-trodden work. We would not rebuild accounting logic inside the job system; the accounts package owns that, and the job system should hand off to it rather than compete with it.
What does it cost compared with a monthly platform?
A platform is a monthly cost per user forever; this is a one-off build of £8,000 to £25,000 plus modest hosting and the optional care plan. The crossover depends on your headcount and how long you keep it. For a small team on a well-fitting platform, the platform wins on cost and we will say so. For a larger team on a badly-fitting one, owning something focused usually wins within a couple of years.
Related
The capability pages behind this work, and the other offers in this set.
Which spreadsheet would you kill first?
Describe the workflow and what it runs on today. If it is not a fit for a fixed-scope build, we will tell you that rather than sell you one.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.