$40 an hour. That is a rough loaded cost for a technician standing in a driveway filling out a form he already filled out twice this week. Multiply it by four techs and fifty weeks and you are looking at real money burned on work nobody bills for.
I have watched service companies argue for years about whether to buy an off-the-shelf app or build their own. The answer depends on one thing: how weird is your workflow? If it looks exactly like everyone else’s, buy the box. If your techs do something your software vendor has never heard of, custom wins. Here is how to tell which camp you are in, what a custom build actually costs you in time and attention, and the specific questions that separate a good mobile project from a six-month money pit.
What Paper Actually Costs You
Most owners underestimate this because the cost hides inside payroll. Nobody sends an invoice for “time spent transcribing handwriting from a clipboard into a system at 9 p.m.”
Here is the real bill:
- Double entry. The tech writes it in the field, somebody types it into the office system, and both versions disagree about half the details.
- Lag time. By the time a job report reaches dispatch, the customer has already called twice about the same issue.
- Lost records. Paper gets rained on, left on a truck dashboard, or filed in the wrong folder. Nobody knows where it went.
- No photos, no signatures, no timestamps. You get a description of a problem instead of a picture of it.
The U.S. Census Bureau tracks how widely American businesses have moved operational records onto digital systems, and the trend line has been one direction for twenty years. The holdouts are almost always field operations, and it is almost always because somebody tried a generic app once and hated it.
When a Custom Mobile App Is Worth It
A custom app makes sense when your field work has at least two of these traits:
- Your technicians need to see equipment history, drawings, or prior service notes on a phone screen while standing in front of the machine.
- Connectivity is unreliable. Basements, rural routes, warehouses with steel walls. A native app that caches data locally and syncs later beats a website that dies without a signal.
- You need the phone’s hardware. Camera for damage documentation. GPS for arrival verification. Barcode scanning for parts. Accelerometer for equipment vibration checks.
- Your form changes constantly. New city code, new part catalog, new inspection checklist. With custom software, that is a Tuesday morning change. With packaged software, you are filing a feature request and hoping.
Two of those four and a custom build usually pays back inside a year. Four of four and there is no real debate.
The Mobile Build Process, Stripped Down
Good custom software shops do not start by talking about technology. They start by watching your people work. If a vendor skips the observation step and jumps straight to a wireframe, walk away. You cannot design for a workflow nobody has actually watched.
Here is the sequence that works, in plain terms:
Describe. You walk the developer through what a real job looks like from dispatch to close-out. Include the annoying parts. The angry customer, the missing part, the form that got wet.
Design. The developer sketches screens based on what they saw. You review, you argue, you change things. This is the cheapest stage to be picky. Changing a drawing costs nothing. Changing a finished app costs a lot.
Develop. Actual coding happens. A good shop shows you working pieces every week or two instead of disappearing for three months and reappearing with a finished thing you hate.
Deploy and adjust. You roll it out to two techs first. Not twelve. Two. Watch what breaks. Fix it. Then roll out wider.
Most of the failed mobile projects I have seen failed at the rollout stage, not the coding stage. Somebody tried to launch to the whole crew on a Monday morning and the entire team revolted by Wednesday. Start small. Give the skeptics a reason to like it.
Off-the-Shelf vs Custom: A Straight Comparison
| Factor | Packaged App | Custom Build |
|---|---|---|
| Time to first use | Days to weeks | Two to four months |
| Fit with your workflow | Approximate. You adapt to it. | Exact. It adapts to you. |
| Ongoing cost | Per-seat subscription, forever | Support and updates only |
| When your process changes | Feature request, no timeline | You pay for the change and get it |
| Data ownership | Usually vendor-hosted | Frequently yours to host |
| Best for | Standard workflows | Anything with a wrinkle in it |
I lean custom for any operation with more than a handful of field techs, so long as the workflow genuinely differs from the norm. Below that, the math usually favors a subscription. Be honest with yourself about which camp you are in. Everyone wants to believe their business is unique. Fewer actually are.
Security Questions Worth Asking
Anything that touches customer records, job site data, or payment details needs real security thinking. That is not optional just because the app lives on a phone.
The National Institute of Standards and Technology publishes cybersecurity frameworks that any competent development shop should be working from. Ask directly whether they follow one. Ask how data is encrypted in transit and at rest. Ask who holds the keys. Ask what happens if a tech’s phone is stolen and what the remote wipe process looks like.
If the answers are vague, keep looking. In my experience the shops that have real answers give them in plain sentences, not in jargon. Vague shops are usually guessing.
Smaller operations also have a smaller target on their back, which is genuinely worth noting. The Small Business Administration is a reasonable starting point for understanding the baseline obligations that apply to small operators collecting customer data. You are not a bank. You still have responsibilities.
A Short Scoping Checklist
Before you call anyone, answer these on paper. Every shop you talk to will ask some version of them, and having the answers ready shortens the sales cycle dramatically.
- How many field people need access, and will that number change over two years?
- What does a single job look like from start to finish, written out step by step?
- Where does the data need to end up? QuickBooks, an internal system, a spreadsheet?
- Does anyone work in places with bad signal? How often?
- What hardware features would actually get used? Camera, GPS, scanner, microphone?
- Who owns the code and the data when the relationship ends?
Anyone pitching a full development contract without walking through these questions first is selling a template, not a solution. That distinction matters more than any pricing table.
What to Look For in a Development Partner
Ask whether they have built anything that talks to hardware. Custom software work that touches real devices, whether it is a sensor, a handheld scanner, or a piece of machinery on a factory floor, is genuinely harder than building a website. A shop that does both tends to have better instincts about what breaks in the real world.
If your operation is in southeast Michigan, a local partner who can walk your job sites with you is worth more than a cheaper remote team you never meet. Anyone shopping for Mobile App Development in Ann Arbor, MI should look for a developer willing to physically stand where your techs stand. That single habit predicts project success better than any portfolio page.
The Takeaway
Paper forms survive because changing them feels expensive and risky. The truth is that leaving them in place is the expensive option. It just costs you quietly, in payroll and in missed detail, instead of in one visible invoice.
Pick two field people. Give them a working app for a month. Watch what happens to their paperwork, their drive time, and their mood. That test costs almost nothing and tells you more than any proposal will. So which of your teams would you put on a phone first?
