The strategic differentiator of AOS isn't that it's a better PM tool, or a better construction-accounting system, or a better field-ops app — though we work hard on all three. The strategic differentiator is that when both the GC and the subcontractor on a project are on AOS, they share the same project record. The document handoff seam between them disappears. This is a walk-through of what that actually changes, workflow by workflow, on a real commercial project.
The cross-tenant value of AOS only fully lands when both sides of a project use the platform. We've written about why this matters strategically in the sub-side thesis and the GC-side thesis. This post is more concrete: what changes on the ground, in the day-to-day workflow, when the GC's PM and the sub's PM are looking at the same database row instead of two different versions of the same document.
It's not theoretical. It changes seven specific workflows in measurable ways.
1. The pay-app cycle: from 60 days to 30, and from opaque to live
The monthly pay-app cycle is the single most expensive piece of administrative work on a commercial project. Here's the cycle as most subs experience it today:
- Day 25-30: sub walks the job with the GC's PM to agree on percent-complete numbers
- Day 30: sub generates a G702 + G703 in their accounting system or in Excel, exports as PDF, uploads to the GC's portal (Textura, GCPay, Procore, etc.)
- Day 1-7: GC's PM downloads the PDF, reviews it, sometimes pushes back via email
- Day 7-10: GC's accountant re-enters the line items into the GC's accounting system, rolls the sub's numbers up into the master pay app to the owner
- Day 10-15: owner reviews master pay app, certifies, owner's accountant cuts the check
- Day 30-60: GC receives owner payment, GC accountant releases sub payments, sub receives the cash
That's a 30 to 60-day cycle, depending on how many manual handoffs hit a snag. The sub doesn't know where in the cycle they are at any given moment — they call the GC's accountant every Tuesday to ask.
Here's the same cycle when both sides are on AOS:
- Day 25-30: sub's PM marks percent-complete on the live SOV; the GC's PM sees the same numbers in real time, can comment or adjust before submission
- Day 30: sub clicks "submit" — the pay app appears in the GC's AP queue cross-tenant, with the SOV and supporting docs already attached. No PDF upload, no re-entry, no portal handoff
- Day 1-3: GC's accountant reviews in their own AP queue, with one-click roll-up into the master pay app to the owner. Sub can watch the certification happen in their dashboard
- Day 3-7: owner reviews master pay app (if owner is also on AOS, this happens in their own dashboard with two-click certification; if off-platform, AOS generates the PDF)
- Day 7-15: owner pays GC, GC pays sub — sub sees status updates at each step, in real time, in their dashboard
That's a 15 to 25-day cycle, plus full visibility throughout. The sub stops chasing status by email. The GC's accountant stops re-entering line items. The integration tax goes to zero.
For a sub doing $30 million in volume with 30 to 60-day pay-app cycles, compressing to 15 to 25 days releases somewhere between $500K and $1.5M in working capital. That's not a software feature improvement. That's a real change in the firm's financial position.
2. Retention: from dispute-prone to dispute-proof
Retention is the chronic dispute on every commercial project's closeout. The GC withholds 10% (or whatever the contract specifies) of every progress payment, holding it until substantial completion. At closeout, the GC and the sub compare records. They usually don't match. The difference becomes the basis for a negotiation that almost always favors the side with better records — usually the GC.
The reason the records don't match is that retention lives in three places at once: the GC's accounting system, the sub's accounting system, and the spreadsheet a junior accountant maintains because neither system tracks retention against milestones cleanly enough. State statutes complicate this further — many states require retention reduction or release at 50% project completion, or at substantial completion, with specific timelines. Subs frequently lose retention they were statutorily owed because they couldn't prove the GC's records were wrong.
When both sides are on AOS, retention isn't replicated across systems. It's literally one row in the database, with the GC's liability and the sub's receivable being two views of the same number. Either side seeing a value that doesn't match means the platform's audit trail will show exactly when and why it diverged — there's no "your records vs. ours" debate, because there's only one set of records.
Practically, this changes closeout from a three-week reconciliation exercise to a confirmation step. The sub knows precisely what's owed at each milestone, when retention reduction triggers fire (state-statute-aware), and exactly when release should occur. The GC knows the same numbers and the same triggers. Disputes don't disappear entirely — sometimes the work itself is in dispute — but record disputes do.
3. Change orders: from email threads to one approval flow
Change orders are the second-most-disputed item on a commercial project, after retention. The typical flow:
- Sub identifies a change — either a scope addition, a field condition, an owner-directed change, or a design change — and sends a Time & Materials estimate or a fixed-price quote to the GC by email
- GC's PM reviews, sometimes pushes back, sometimes approves and forwards to the GC's accountant
- GC's accountant prepares a formal change-order document, sends it back to the sub for signature
- Sub signs, returns by email; meanwhile, the work has often started already because the schedule can't wait
- Owner reviews the same change order; sometimes approves, sometimes pushes back
- If approved, the change order gets added to the contract sum; the sub's SOV updates; the next pay app reflects it
- If disputed, the change order sits in email purgatory while the work continues; reconciliation happens at closeout
When both sides are on AOS, the change order is one record with state transitions: proposed → reviewed → approved → committed → invoiced. The sub creates it; the GC's PM reviews it in their own queue with one-click approve/reject/comment; the GC's accountant adds it to the contract sum automatically when approved; the owner sees it in their own dashboard if also on AOS. The change-order log on both sides is the same log. Email purgatory disappears because the workflow lives in the platform, with a clear state at every moment.
The biggest practical change is that change-order aging — the dollar value of changes the sub has performed but not been paid for — becomes a live number on both sides instead of a closeout-time surprise. The sub knows their exposure. The GC knows their commitment. Owners don't get hit with a $400K change-order roll-up two weeks before closeout.
4. RFIs and submittals: from inbox chaos to SLA tracking
The standard RFI workflow today is an email thread that gets logged into one of the parties' systems eventually. The sub's foreman or PM identifies a question. They email the GC's PM. The GC's PM either answers from their own knowledge, or forwards to the architect, or both. The architect's contract admin responds (eventually). The GC's PM forwards the response back to the sub. The sub's PM logs the answer somewhere — maybe.
The submittal workflow is similar: sub uploads a submittal package to the GC's portal, GC's PM downloads, forwards to the architect, architect reviews and returns, GC's PM downloads, uploads back to the sub's portal. Multiple round-trips, multiple version numbers, multiple inboxes.
When both sides are on AOS, the RFI and the submittal are single records with state and assignment. The sub creates an RFI; the GC's PM is the assigned reviewer; the architect (if on AOS) is automatically routed for design questions; the response posts back as part of the same record; everyone involved sees the SLA clock and the breach indicators. Submittals work the same way, with version control built in so there's no "wait, which version did the architect approve?"
The practical change is two-fold. First, RFI and submittal turn-time becomes measurable and trackable — you can hold a GC, a sub, or an architect accountable to specific SLA numbers per client, which is what the contract usually requires anyway. Second, the documentation burden disappears: the audit trail of who asked what, who answered, when, and what version of the answer became authoritative is built in.
5. Daily logs and field signal: from "the next day" to live
The standard sub-side daily log workflow today is a steno pad or an iPad in the foreman's truck, transcribed by a junior PM the next morning, eventually shared with the GC's superintendent later that week. The information that the office actually needs — what got built today, what crew sizes, what equipment, what conditions — arrives a day late, in a format that doesn't tie to anything else in the system.
When the sub is on AOS, the foreman uses voice-to-log dailies in the truck, with photo capture and geofenced labor — the data lands in the system in real time, not the next day. When the GC is also on AOS, the GC's superintendent and PM see the sub's dailies in the same project timeline they see their own. Schedule-slip signals fire when productivity drifts. Weather context (NOAA-sourced) attaches to dailies automatically so the schedule-impact case for change orders writes itself.
The practical change is that the office sees field reality the day it happens, not the day after. Productivity issues spotted in real time cost the sub a half-day; spotted three days later they cost a week. Compress the signal latency and you compress the cost of every issue.
6. Drawings and document control: one set, not three
The standard project today has the drawing set in two or three places. The architect's Bluebeam files. The GC's BIM 360 or Procore drawings module. The sub's local copy that they marked up two months ago and may or may not have refreshed since. Version drift between these sets is the source of an enormous amount of construction error.
When both the GC and the sub are on AOS, the drawing set is one record. The architect uploads (or syncs from Autodesk Construction Cloud); the GC manages the version on AOS; the sub's foreman marks up the same set from mobile. Updates propagate. The "wait, which version are you looking at?" conversation disappears because there's only one version, with a clear version history of what changed and when.
For sub-foreman field markup specifically, AOS is designed for the truck cab with gloves on — not a desk-bound markup tool that happens to have a mobile view. The markup posts to the same drawing the GC is looking at. The architect sees field conditions surfaced from the sub's markup.
7. Closeout: from a three-month scramble to a known endpoint
Closeout is where every record-keeping shortcut taken during the project comes due. The closeout binder — warranty docs, O&M manuals, as-built drawings, lien waivers, final pay apps, attic stock receipts — has to be assembled from the various places those documents live. For a $20 million project with 30 subs, that's typically a three-month scramble for the GC's project engineer, with constant chasing of subs for the documents that should have been collected at the time the work was done.
When both sides are on AOS, closeout documents are collected continuously through the project, attached to the right records (pay apps, change orders, submittals) at the time they're produced. The closeout binder is essentially compiled at substantial completion — not assembled from scratch. The sub's lien waivers, warranties, and O&M documents are pre-attached to the relevant records. The as-built drawings reflect the actual final state because field markups posted into the same drawing set all along.
Practical change: closeout shifts from three months of scramble to two weeks of confirmation. For an owner, that means the warranty period starts when it's supposed to, not three months late.
What you need for this to work
Both sides on AOS. That's the core requirement. The cross-tenant value compounds across the network — the more of your counterparties on the platform, the more of these workflow changes you actually see.
That's why our private-beta design-partner program is co-targeting subs and GCs. We want firms whose counterparties will follow them onto AOS, where the both-sides-on-one-record value lands fully. A sub on AOS whose GCs are all off-platform still gets significant standalone value (the ITB inbox, the sub-side pay app, the retention rollforward, the foreman tools) — but the document-handoff seam doesn't disappear until at least one GC client is also on the platform. Same the other direction.
If you're a sub, the highest-leverage thing you can do is introduce us to one of your GC clients. If you're a GC, the highest-leverage thing is to bring two or three of your largest subs onto the beta with you. Network value compounds; we want to be deliberate about which networks build out first.
How to evaluate this for your firm
If you're a sub or GC running a typical 4-6 vendor stack today, the way to evaluate the both-sides-on-one-record value is to estimate the cost of the seven workflow gaps above on a single project. Specifically:
- Pay-app cycle: what's your average days-to-payment from submission? Compress it by 50% and compute the working-capital release.
- Retention disputes: what do you lose annually to retention you couldn't prove was owed?
- Change-order aging: what's the dollar value of changes you've performed but not been paid for at any given moment?
- RFI/submittal SLA: how many days does a typical RFI take? How many of them breach the contract SLA?
- Field signal latency: how many days between the foreman knowing something and the PM knowing the same thing?
- Drawing version drift: how many rework events per project trace back to someone working from an outdated drawing?
- Closeout duration: how long does your typical closeout take, and how much PM time does it consume?
Add those numbers up and they're usually somewhere between 1% and 5% of project value. For a typical mid-market commercial project, that's six figures of cost recovery per project, paid for largely by office labor reduction and faster cash cycles.
If you'd like to see it
The both-sides-on-one-record value lands when both sides are actually on the platform. We're recruiting design-partner cohorts where a GC and 2-3 of their subs (or a sub and 2-3 of their GCs) come on together, so the network value lands on day one rather than waiting for the second side to catch up.
If you'd like to be one of those cohorts — or if you'd like to be the sub or GC who introduces us to your counterparties — apply to the beta. We'll work with you on the co-recruit.