Every construction technology survey for the last ten years has named field-tech adoption as the single biggest unsolved problem in the industry. Self-perform specialty trades — concrete, steel, drywall, MEP, glazing — have it worst. The foreman writes on a steno pad, the office buys software the foreman doesn't use, and the executive wonders why the ROI never materializes. This is a playbook for self-perform subs on how to actually get field tech adopted, what fails consistently, and how to design rollouts that survive contact with the jobsite.
If you're the owner, COO, or operations leader at a self-perform specialty trade and you've tried to roll out field tech in the last few years, you know the pattern. (Related context on why this matters specifically for the sub side of the market: our post on why subs are the most under-served seat in construction technology.) The office buys a daily-log app, a timesheet tool, a drawing-markup platform, or some combination of all three. The foremen get a training session. For two weeks they use it. By week four most of them are back on paper. The executive who championed the rollout is asked at the next board meeting why the platform isn't delivering value. The answer is "the foremen aren't using it." The question is then "what do we do about that?"
What we do about it usually isn't another mandate. It's a different rollout. This post is the playbook.
Why field tech rollouts fail the same way every time
Across the last decade of construction-tech case studies, post-mortems, and operator conversations, the same five failure modes show up repeatedly.
1. The app was designed in an office and handed to the field. Most "field" apps are actually thin clients on top of an office workflow. They expect the foreman to have time, a desk-equivalent posture, and uninterrupted attention. The actual jobsite at 6am is gloves, weather, one bar of LTE, and a phone call interrupting every two minutes. Apps that don't survive those conditions get put back in the truck cab.
2. The foreman has no incentive to use it. The data the foreman captures goes to the office. The office benefits. The foreman doesn't. If the only reward for using the app is "the COO doesn't yell at you next week," adoption is going to be exactly what compliance demands and not a millimeter more.
3. The training was a one-time event. A two-hour training session at the start of a rollout produces about three days of behavior change. Without ongoing support — someone who can answer "how do I do X" in real time during the workday — the app gets abandoned the first time it gets confusing.
4. The data the app produces isn't visible back to the field. The foreman fills out the daily log, the timesheets, the equipment ticket. The data disappears into the office system. The foreman never sees it again, doesn't know if it was used, doesn't see how it affected anything. Without feedback, the work feels pointless.
5. The mandate came from above without the on-ground buy-in. The executive decided. The COO supported it. The PMs were told. The foremen were told. Nobody asked the foremen what they actually needed. Mandates from above without consultation from below get the malicious-compliance treatment in any operational role — and field operations is no exception.
Notice that "the foremen are stupid" or "field workers resist change" doesn't appear in this list. Both of those are common executive framings of failed rollouts, and both are wrong. Foremen are usually pragmatic operators with a finite attention budget and a strong filter for tools that don't pay them back. Their resistance is usually rational.
The foreman-first design principle
If you take only one thing from this post: field tech has to be designed for the field, not retrofitted from an office product. That means specific things:
- Voice input over typing. A foreman in the truck at 6am with gloves on cannot type. They can talk. Voice-to-log dailies are an order of magnitude better than form-based daily logs for the actual capture moment.
- Offline-first. Jobsites lose cell signal regularly. Apps that require connectivity for every action fail on cell-dead sites. Offline-first means the foreman can capture data, work normally, and sync when signal returns — not "the app is broken until you walk to the truck."
- Gloved-fingertip targets. Tap targets that work for a thumb in a work glove. Not Material Design defaults sized for a smartphone in an office.
- Geofenced workflows. The platform should know the foreman is on the jobsite (and which jobsite) and tailor the UI accordingly. The crew assignment screen should default to the right project; the timesheet should pre-fill the location.
- Drawing markup that works on a phone, not just a tablet. Not every foreman carries a tablet. A drawing-markup workflow that requires one fails on sites where the foreman has a phone in their belt and nothing else.
- Photo capture with EXIF and project context preserved. The foreman takes a photo of a condition; the platform attaches the timestamp, the GPS coordinates, the project, and the relevant SOV line automatically. Not "the foreman has to remember to upload the photo into the right folder later."
If your current field-tech stack doesn't meet most of these — the rollout is going to fight you, and you'll lose.
The four-stage rollout that actually works
Across the rollouts I've watched succeed, the same staged approach shows up. It's slow on the surface and fast in practice, because it builds the conditions for the adoption to stick.
Stage 1: Pick one crew. One. Not the whole company, not even a division. One foreman, one crew, on one project. Pick the crew whose foreman is curious about tech — not the most senior foreman, not the most resistant one, just the one who's actively open to trying things. This is your pilot.
Stage 2: Spend two weeks with that crew, in the field. Someone from the office — ideally the operations leader, definitely not just a software vendor — spends time on the jobsite with the pilot crew. Watch what they do. Watch where the app helps and where it gets in the way. Make adjustments. The foreman should feel heard. Their feedback should produce visible changes in how the platform is being deployed.
Stage 3: Make the data visible back to the field. Before expanding, build a feedback loop. The foreman should see their own data: their crew's productivity rate, their dailies in the project record, their photos referenced in the next coordination meeting. They should be able to point to specific moments where the app affected the office's decision-making.
Stage 4: Let the pilot foreman help the rollout. When you expand from one crew to three, the pilot foreman is the trainer. Not the software vendor. Not the COO. The foreman who's already proven the workflow works. Other foremen will believe their own.
This is a 6-to-12-week rollout per crew at the start, expanding to whole-firm coverage over 6-12 months. It's slower than the "everyone is on the new platform Monday" approach. It also actually works.
What to capture first, what to defer
Even with the best rollout approach, asking the field to capture too many things at once kills adoption. Start with the highest-value, lowest-friction captures and expand.
Capture first (week 1):
- Daily log — voice-to-log, 90 seconds max. What got built today, what crew sizes, what conditions, any blockers.
- Crew-of-the-day — who's on the job, what they're doing. Often pre-populated from the assignment system; just a confirmation.
- Photos — the foreman takes them anyway. The platform just needs to capture them with context attached.
Add second (weeks 3-4 once daily log is sticky):
- Timesheets — geofenced where possible to reduce friction. Pre-fill the project and rate; the foreman just confirms hours.
- Equipment tickets — what equipment is on site, when it arrived, when it departed.
Add third (weeks 6-8 once basics are sticky):
- RFI initiation from the field — the foreman flags a question, voice-captures the context, attaches a photo. The PM picks it up at the office.
- Drawing markup — the foreman annotates a field condition on the current drawing set.
Defer until well after adoption is established:
- Punch-list management from the field
- Detailed scheduling input from foremen
- Material requisitions through the field app
The principle is that each addition should pay back the foreman before adding new asks. Capture the daily log, then show the foreman how it surfaces productivity insights at the next coordination meeting. Then add timesheets. Then show them how the timesheet data drove a schedule adjustment that helped their crew. And so on.
The specific things self-perform specialty trades need that generalist platforms don't have
Self-perform specialty trades have operational characteristics that distinguish them from GC field workflows and from general-trade subs:
- Yard-to-site equipment tracking. A concrete sub has formwork inventory at the yard. It moves to a jobsite, stays there for weeks, returns, gets repaired, goes out again. Tracking this on paper is how concrete forms get lost. The right answer is an equipment record that knows where each unit is, with a ship-out gate at the yard that drafts the inventory transfer automatically and posts the GL entry.
- Prefab tracking. MEP and steel subs often prefab off-site. The prefab piece has its own identity, its own quality record, its own schedule milestone. When it arrives on site, it's installed. The field workflow needs to be able to identify what arrived, where it's going, and update the install schedule.
- Crew-of-the-day with worker-typeahead. Specialty trade crews change daily based on absences, weather, and other-job conflicts. The foreman building the crew at 6am needs a fast typeahead of available workers, not a spreadsheet they have to scroll. Geofencing helps — "show me workers within 30 miles of this jobsite" is a useful filter.
- Productivity tracking that matches the trade's units. Concrete is yards of pour; drywall is square feet hung; electrical is fixtures or device boxes; steel is tons erected. The platform's productivity tracking has to speak the trade's units, not a generic "labor hours per dollar" abstraction.
Generalist platforms (Procore, Sage, the rest) generally don't have these built in. They have to be configured, customized, or worked around — which kills adoption even when the rest of the platform is fine.
How AOS handles field-tech for self-perform specialty trades
AOS is built field-first for the trade-specific workflows above. Specifically:
- Voice-to-log dailies that work in the truck cab at 6am with one bar of LTE. Offline-first; syncs when signal returns.
- Geofenced timesheets that survive cell-dead sites. The foreman starts the crew shift; the app captures location, hours, and crew composition automatically.
- Crew-of-the-day with worker typeahead and geofence-aware filtering. Build tomorrow's crew in 90 seconds.
- Equipment pinned at site with a yard-side ship-out gate that drafts the GL entry for every inventory transfer.
- Drawing markup from mobile, not a flat PDF viewer. Designed for the truck cab with gloves on.
- Photo capture with EXIF and project context preserved automatically.
- Trade-specific productivity tracking in the units the trade actually uses.
- Foreman feedback loop built in — the foreman sees their own data, productivity comparisons, and the impact of their captures on the project record.
The sub foreman role page walks through the field workflow specifically. The field operations product page has the broader feature map. For the broader strategic story on how field tech, AP cycles, retention, and RFI workflows compound when both sides of a project run on the same platform, see our walk-through of what changes when the GC and the sub share a record. And if you're evaluating field-tech as part of a bigger platform decision, our buyer's guide for mid-market subs and GCs covers the demo questions that actually separate adoptable platforms from PowerPoint-only ones.
One last thing: hire the foreman who liked it
The single highest-leverage hire for a self-perform sub running a successful field-tech rollout is the foreman who was the pilot. Not as a foreman — as the firm's field-tech champion. The person who knows the platform from the foreman's perspective, who can train other foremen credibly, who can push back on the platform vendor when something doesn't work in the field. Most successful field-tech rollouts have this person, and most failed rollouts don't.
If you're a self-perform specialty trade evaluating field-tech in 2026 and you'd like to talk through what a rollout could look like on AOS, apply to the design-partner beta. We work with self-perform subs specifically because the field workflows are where AOS is differentiated, and design-partner conversations have shaped a lot of what's described above.