Your drivers, crews or techs do the work out of the office, and the record of it comes back on paper, in a text thread, or in someone's memory at the end of the day. Then a person in the office spends the next morning turning it into rows.
So you start looking at custom mobile application development, and the quotes come back priced like a consumer app: design sprints, an app store launch, a feature list as long as the product you wanted to avoid. A phone app your own people use to report their work is a smaller and different job. This post is what that job contains. I run a firm that builds these, so read the pricing section as an argument for hiring us. The rest holds whoever you hire.
Start with the record, not the screen
The question that sizes a field app is not "what should it look like." It is "what record has to exist when the job is done, and where does it have to end up."
Write that record down field by field. For a delivery it might be the stop, the time, who signed, what was dropped, what came back, and a photo. For a service call it might be the site, the hours, the parts used and the customer's sign-off. Then write down where each field goes: payroll, the invoice, the CRM, the accounting file.
That list is the app. Every screen exists to fill one of those fields, and every field exists because a system downstream needs it. Anything that is not on the list is a feature you are paying for and nobody will use.
What belongs on the phone
A phone is good at four things in the field, and a custom app should use all four before it adds anything else.
Capturing what the person sees: a photo of the signed ticket, the damaged pallet, the meter reading. The photo is the evidence; the app should attach it to the record it proves.
Capturing what only the person knows: the reason a delivery failed, the part that was swapped, the customer who asked for a callback. These are short choices from a fixed list, with a free-text box for the exception, not a blank form.
Knowing where and when: the time and place of a stop are recorded when the person taps the button, so nobody types them later from memory.
Telling the person what is next: the next stop, the next job, the open item from yesterday. One list, in order, that the office can change during the day.
What stays off the phone
The fastest way to make a field app expensive is to put the office on it. Reports, approvals, rate tables, customer history and billing belong on a screen in the office or in the systems you already run. The person in the truck needs the next job and a way to close it.
Keep the decisions off the phone too. If a reading is out of range or a stop was missed, the app records it and sends it to a person in the office. Your rules decide what happens next, not the driver's judgment at 4 PM in a parking lot.
The phone is one end; the systems are the other
A field app that stores its records in its own database has made one more place to reconcile. The part that saves the office time is the connection on the other side: each record lands in the spreadsheet, the CRM, the ERP or the accounting file your team already works in, checked against your rules on the way.
That is the same work our data-entry agent does with paper. It reads PDFs, spreadsheets, web forms, email attachments and text messages, checks every field against rules you set, posts the clean records where your team needs them, and sends anything that fails a rule to a person for review. It does not enter a guess. For a delivery company in Dallas-Fort Worth that lost its dispatch system, it read about 2,000 handwritten delivery slips, about twenty fields each, and turned them into more than 1,900 rows checked against the paper in about 30 minutes. Payroll went out on time.
A field app removes the paper from that job. The checks, the review queue and the posting stay the same, and every record notes where it came from, so anyone can trace a row back to the photo and the tap that created it.
Pick the first app by the hours it saves
Choose the one record your field people create most often and that costs the office the most time to clean up. Count the hours a week someone spends retyping it and the number of times a month it is wrong. Build the app for that record only, put it on the phones, and run it for a month before you scope the second screen.
A narrow first version gets used the day it ships, because it replaces one thing completely. A version that covers part of five jobs gets abandoned, because the crew still has to carry the paper for the rest. The first month is also when both sides find out where your exceptions are, which is the only honest basis for pricing the next part.
What gets built, in order
The record and its rules: every field, which ones are required, which values are allowed, and what makes two records the same job.
The connections: reads and writes against each system that stays, with field mapping, validation and a log of every record moved.
The screens: one per step where a person in the field has to do something. If a step needs no input, it gets no screen.
The office view: the review queue for records that failed a rule, with the reason each one stopped.
The audit trail: who submitted each record, from where, when, with which photo, and which rules it passed.
Who keeps it running after launch
Field software breaks on busy days. A phone updates its operating system. A downstream system renames a field. A crew finds a case nobody tested.
We build it, put it in production, and stay responsible for it while it runs. We watch it, fix what breaks, and make the changes you ask for. You are not handed a code repository and a login.
What it costs
Custom software and one-off jobs are priced per project, from $10,000. If the work behind the app is a running agent, such as the data-entry agent posting each field record or the bookkeeping agent matching receipts to bank lines, that agent has a build fee from $5,000, then from $500 a month. The monthly fee covers AI model usage, monitoring, fixes and the changes you ask for.
More systems to connect, more volume and more complicated rules raise a quote. The pricing section of our FAQ covers the rest. Timeline follows scope: a single-record app against one system is a short build, and a complicated one can take up to 90 days to design, build and test.
The call
Bring two things: the record your field people create most often, and the list of systems it has to end up in. We will walk the steps with you, say what goes on the phone and what stays in the office, and put a number on that first version.
If that is the conversation you want, book a call and we will scope it with you.