If you're a general contractor, you've probably never asked a sub at qualification what software they use. It's none of your business, in a contractual sense. But operationally, it's some of your business — because the sub's tech stack determines how much office labor your GC team spends on every project. Here's a frank look at the four specific places the sub's tech stack hits the GC's P&L, and what GCs should actually do about it.
The standard mental model in commercial construction is that the sub's internal operations are the sub's problem. The GC pre-qualifies on bonding, insurance, safety record, references, and price. Anything else — how the sub runs payroll, what accounting system they use, whether their PMs work from spreadsheets or platforms — doesn't show up on the qual sheet.
That model made sense when project communication was phone calls and faxes. It makes less sense in 2026, because the sub's tech maturity now directly drives how much administrative work your GC office has to do for every job that sub is on. The cost is real, it's recurring, and it's invisible in the standard reporting.
This isn't a "make subs use software" post. Subs choose what works for them, and most are running lean by necessity. It's a post about understanding where the GC actually bears cost from sub tech limitations, and what a forward-looking GC can do about it. The most strategic move turns out to be helping good subs adopt better tools, not penalizing them for not having them.
The four places sub tech limitations hit the GC's P&L
1. AP and pay-app processing cost per sub per cycle. Every monthly pay app from a sub on a less-mature stack arrives as a PDF in an email or a portal upload. Your GC's accountant downloads it, re-keys the line items into Sage or Foundation or whatever you run, reconciles against the contract SOV, chases the lien waiver, and routes for PM and accounting approval. For a typical $100M GC running 25 active projects with 10-15 subs each, that's 250-400 monthly pay app cycles, with somewhere between 15 and 45 minutes of GC office time per cycle. The math is 60-300 hours/month of GC AP labor consumed by sub-side tech limitations — one to two FTEs depending on volume.
When a sub is on a connected platform (one that delivers the pay app structured into your AP queue rather than as a PDF), that office-time per cycle drops to roughly 2-5 minutes. The difference is paid in your office labor.
2. RFI and submittal cycle time. The sub PM whose RFI tracking lives in their email inbox responds to your project's RFIs whenever they happen to remember. The sub PM whose tracking is in a platform with SLA alerts responds before the breach fires. For your project schedule, this is the difference between an 8-day average RFI turn-time and a 14-day average — which, on a critical-path RFI, is the difference between staying on schedule and slipping by a week.
You can't bill the sub for the schedule impact in a straightforward way. The cost falls on the GC, who has to either accept the slip or eat it through liquidated damages exposure with the owner.
3. Retention disputes at closeout. The sub whose retention is tracked at the project level in QuickBooks plus a spreadsheet shows up at closeout with a different retention number than your accounting system has. The negotiation begins. The GC's accounting team, the GC's PM, and the sub all spend hours reconciling. Usually the GC wins because the GC has better records — but "winning" still costs the GC team time, and the sub leaves the project with a sour taste that affects whether they bid the GC's next job. (Our retention rollforward guide covers the sub-side mechanics; the GC bears the negotiation cost.)
When both sides track retention at the SOV-line level in connected systems, closeout reconciliation goes from a multi-week negotiation to a confirmation step. The GC's accounting team gets that time back.
4. Field signal latency that arrives in the office as a surprise. The sub whose foreman writes dailies on a steno pad and the office transcribes them the next afternoon means the GC's superintendent finds out about a productivity issue or a quality problem 24-48 hours after it happens. By the time the GC's PM is in the loop, the issue has compounded. The cost shows up as rework, schedule recovery overtime, change orders that should have been smaller, and the occasional owner-visible incident that didn't have to be one.
When the sub is running field-first tools (voice-to-log dailies, geofenced timesheets, real-time photo capture), the field signal arrives in the GC's project record the same day it happens. Issues get caught while they're still small. (Our field-tech adoption playbook walks through what good field tech looks like.)
What "the sub's tech stack" actually means in practice
For GCs evaluating this, it's worth being concrete about what differentiates a sub on a mature tech stack from one on a less mature one. The hallmarks of a sub that's going to be operationally easy to work with:
- Their pay app arrives in a structured format (not just a PDF), with the SOV mapping to your contract structure clearly
- Their RFI responses have SLA tracking and breach alerts on the sub side, so you're not the only party watching the clock
- Their retention is tracked at the SOV-line level, with state-statutory awareness, and they can produce a defensible report at any moment
- Their foreman's dailies arrive in the project record the same day, with voice capture and photos with EXIF data
- Their lien waivers arrive on the correct state's statutory form, for the exact released amount, on the first try
- Their submittal log has version control built in, so the version your architect approved is unambiguously the version that gets installed
- Their COIs and contract documents are kept current automatically, not chased every six months
The hallmarks of a sub that's going to be operationally painful (regardless of how good their workmanship is):
- Pay apps in PDF format, with SOV structures that drift from cycle to cycle
- RFI responses by email, with no SLA tracking on their side
- Retention tracked in a spreadsheet by the AR clerk
- Dailies that arrive in the GC's project record one to three days late
- Lien waivers on whatever form the sub's bookkeeper found online, for round-number amounts that don't match the released payment
- Submittals with version drift, where the architect approves version 3 and the installed product is version 4
- COIs that expire mid-project and have to be chased
The workmanship of these two sub profiles can be identical. The operational cost to the GC is not.
What GCs typically do today (and why it's incomplete)
The standard GC response to operationally painful subs has been variations on:
- Don't bid them next time
- Build "platform compliance" into the pre-qual (typically means "be willing to log into our Procore/Textura/GCPay portal")
- Push lien-waiver and pay-app compliance through the GC's portal of choice
- Tolerate the operational cost as a tax on having access to the sub's pricing
Each of these has limits. Not bidding the sub means losing access to their pricing and their workmanship, which often more than offsets the operational tax. Platform compliance only helps the GC if the platform itself solves the workflow — and most GC-hosted portals push the burden onto the sub without giving the sub their own operating system. Pay-app compliance through the GC's portal addresses the lien waiver issue but doesn't help with retention, field signal, or RFI cycle time. And tolerating the cost is the most common option, which is why most GCs have AP departments larger than they would need if the sub side were modernized.
The strategic move: help your good subs upgrade their stack
The forward-looking GC move is to actively help the subs you want to keep work with onto modern tooling — not because you care about the sub's internal operations, but because the sub's operational improvement is your operational improvement.
Specifically, when both you and a sub are on a connected platform (like AOS), the operational gains compound:
- Pay apps arrive in your AP queue without document upload — your accountant's 15-45 minutes per cycle drops to 2-5
- RFIs and submittals share one record with SLA tracking on both sides — turn-time becomes measurable and contractual
- Retention is the same database row on both sides — closeout reconciliation becomes confirmation
- Field signal arrives the same day on the same project record — productivity issues get caught early
- Lien waivers are auto-generated for the correct state and amount — the back-and-forth disappears
We covered the full strategic differentiator in the both-sides-on-one-record post — it's the central thesis of why AOS is co-targeting subs and GCs in our private-beta program. For the GC, the path is to identify the 3-5 subs you most want operational alignment with and invite them to onboard alongside you.
What this looks like in the AOS private beta
The way we structure design-partner cohorts is deliberately co-recruited: when a GC joins the beta, we ask them to bring 2-3 of their largest or most-strategic subs along. When a sub joins, we ask them to bring 1-2 of their largest GC clients. The cross-tenant value of the platform only fully lands when both sides of the project are on the same record, so we want to set up the network conditions for that on day one rather than waiting for it to backfill organically.
For a mid-market GC reading this, the question isn't "should I make my subs use my software" — it's "which 3 subs would I most want to be on the same operating system with me, where both of us benefit from the operational compression." That's a much better question because the answer is collaborative rather than coercive, and the operational gain is mutual.
If you'd like to talk through it
We're recruiting design-partner cohorts of mid-market GCs co-recruited with 2-3 of their key subs. If you're a GC who has a few sub relationships where the operational alignment matters — or if you're a sub whose largest GC client would benefit from being on the same platform — apply to the beta. We'll work with you on the introductions.
The broader GC product story is on the commercial GC overview page, with role-specific walkthroughs for the GC executive, GC CFO, GC COO, GC project manager, GC accounting, and GC superintendent.