Engineers don't resist apps. They resist friction
Written by The BlueWave team · Published 2 April 2026 · 6 min read
Roll out a new field app and brace for pushback from the engineers. It usually comes, and the usual reading is that engineers are set in their ways. That reading is wrong, and it's expensive, because it aims you at the people instead of the app. Two-thirds of field service businesses say technician adoption is their single biggest software problem, 67% of them. When resistance is that widespread, it isn't a character flaw. It's a response to something real.
What engineers resist is friction, and the objections are specific. Extra taps to close a job. The same information keyed in twice. A sync that spins and dies in a basement. The recurring complaint is that the software feels built by people who've never done the work, never stood in a plant room with cold hands and a phone that won't save. That's not obstinacy. It's an accurate field report.
The friction is measurable
Count the taps. A good field app closes a routine visit in a handful of deliberate actions. A bad one makes the engineer confirm the same thing across three screens, re-enter the site address the office already holds, and wait on a spinner between every step. Do that forty times a day and the arithmetic turns brutal. Firms end up spending months trying to force adoption of software their techs won't use, because closing a job takes too many steps or the app is too slow to be worth it.
The repetition is its own tax. The office already holds the customer, the site, the asset list and the schedule, so a well-built app arrives knowing all of it, and the visit starts with the readings rather than with re-keying an address the system stored last week. A badly built one asks again every visit, as if the last thousand never happened. That isn't laziness; a busy engineer optimises the same way a busy office does, by cutting the step that adds nothing. Every field an app makes them re-enter is a field they'll eventually decide is quicker on paper, and they'll be counting.
Then there's the failure that ends adoption in one afternoon: the app that loses the work. Not blocks it, accepts it and then drops it. The reviews name it in the engineers' own words, "program crashing and loosing all the entered details on the report" on one platform, "Mobile app won't auto save, causing much data to be lost" on another. An engineer who loses forty readings once does not lose them twice. They go back to the notepad, and they're right to.
Why the demo looks fine and the app doesn't
Here's the tell that catches buyers out. The same platforms carry two very different scores depending on who's holding the phone. One scores 4.3 on Capterra but 2.6 on the Google Play store. Another's Android app has been reported at roughly 1.6 stars across some 368 reviews. That gap isn't noise. Buyers rate the software they saw in a demo. Engineers rate the app they hold in a plant room. Same name, different products.
A demo runs on strong wifi, on the salesperson's laptop, with clean data and nothing queued. The engineer's Tuesday runs on a cracked screen behind two fire doors with no signal and gloves on. Whichever score you trust tells you which of those two experiences you're actually buying.
The demo hides the friction by design. A salesperson drives a happy path they've run a thousand times, on hardware they own, with a handful of tidy records. Nobody force-quits the app mid-visit or drops the signal halfway through a signature while a prospect is watching. The failure modes that actually decide adoption are the ones a demo is built to route around, which is why the engineer who'll live with the tool should be the one testing it, on your worst site rather than the vendor's best.
What abandonment looks like six months in
It rarely fails loudly. The app goes out, everyone's trained, the first weeks look fine. Then a visit vanishes, or the sync drags on a wet Friday, and one engineer slips back to paper. Then a second. By month six the app is nominally live and the notepad is back in the van, which means the office is transcribing paper into the system after the fact, paying for the software and the manual entry both, and getting worse data than either alone would give, because the retyping happens days later from memory and a damp sheet.
Nobody decides this. It builds up one lost visit at a time, and by the time it surfaces in a report the habit has set.
How to buy so it sticks
The fix lives in the selection, not the training. A few things move the odds:
- Put engineers in the room from day one. Not to rubber-stamp a shortlist the office already drew up, but to run the apps before anyone signs. They'll find in ten minutes the friction you'd otherwise meet in six months.
- Count the taps to close a real visit. Have an engineer complete an actual monitoring visit on each shortlisted app, and count every action. That number is your adoption forecast.
- Run the airplane-mode test. Fill in a whole visit with the phone offline, force-close the app, reopen it, and check the work survived. We wrote up the full five-minute version separately, because "works offline" usually means a read-only cache.
- Pilot with your most sceptical engineer, not your keenest. The keen one makes anything work and tells you it's brilliant. The sceptic reaches for the notepad at the first excuse, which is the report you need before committing.
Read the contract while you're there too. The apps that lose data and the deals that trap you tend to travel together, and the small print is a subject of its own.
We built the BlueWave engineer app by starting from the friction and working back. Big targets for gloved hands, the fewest taps we could get a full visit down to, and offline capture that treats the plant room as the normal case: forms, photos and signatures all save with no signal and sync themselves when it returns. None of that shows up in a feature grid. It shows up in whether the notepad stays in the van.
So when the engineers push back, listen to the words. "It's slow" and "it lost my readings" are not stubbornness. They are a defect report from the only people who use the thing every day, and the cheapest time to act on it is before you sign.