Walk into any mid-market commercial subcontractor on a Monday morning and watch what the office staff actually do. They log into Procore for the GC running the school job. Then GCPay for the hospital. Then Textura for the office tower. Then somebody's home-grown SharePoint portal for the courthouse renovation. Then a different Procore instance for a different GC. Then their own QuickBooks. Then Excel.
That's the operating system of a $30 million sub in 2026. Not a platform. A stack of other people's portals.
Nobody set out to design it this way. It's just where construction software ended up after two decades of building GC-first platforms and treating subs as a downstream data-entry endpoint. The cost of that decision falls almost entirely on the sub side — in office hours, in slow cash flow, in retention drift, in pay apps that go sideways because the sub can't see what's happening on the GC's side of the record. And it's invisible in any vendor's P&L because it's paid in administrative labor, not license fees.
This is a post about that gap. Why it exists, what it actually costs the sub side, and what changes when somebody finally builds an operating system for the sub's own business instead of another portal to log into.
The GC-first defaults that broke sub tooling
Construction software in its modern form started in the mid-2000s. Procore launched in 2002, building a project-management tool aimed squarely at general contractors. Textura (later acquired by Oracle) launched a pay-app and lien-waiver platform that GCs bought to manage their subs. CMiC, Viewpoint, Sage 300 CRE — the construction-accounting incumbents — were all GC-centric in their design, even when they had sub-side modules.
The buyer in every case was the GC. That's who had the budget, the IT staff, the appetite to standardize across projects. So the products got built around the GC's workflow: bid out the job, manage the subs, certify their pay apps, route their COIs, handle their lien waivers, and produce a clean owner-facing pay app on top.
The sub got a portal. Free of charge, branded with the GC's logo, with just enough functionality to upload a pay app and download a drawing set. From the GC's perspective this was a feature. From the sub's perspective it was a tax: yet another login, yet another set of conventions, yet another place where the GC's information lived but the sub's didn't.
Twenty years later that pattern is the load-bearing assumption of the entire construction-software market. The sub-facing modules in Sage 300 CRE, Foundation, Viewpoint, and CMiC all exist, but they were grafted onto GC-first cores. The sub-side modules in Procore exist, but they're priced for firms that don't typically buy them. The pay-app platforms exist for subs to upload to, but they don't help the sub run their own business.
The result is that the sub's own operating reality — the ITB inbox, the bid-leveling, the SOV across active jobs, the retention by GC client, the lien-waiver lifecycle, the AP against the PO, the foreman in the truck at 6am — runs on whatever the sub can stitch together. Usually that's QuickBooks plus Excel plus a folder full of PDFs, with the GC portals on top.
What the gap costs the sub side
This isn't an aesthetic complaint about UX. The cost is concrete and shows up in four places.
Office labor that doesn't scale with revenue. A typical $20 million sub runs one estimator, one PM, one accountant. Each one is doing 2-3 jobs. The accountant is reconciling pay-app status across four GC portals every week, downloading PDFs, retyping line items, watching for retention that the GC moved out of the project's "released" column without telling anyone. The PM is logging into three RFI systems to chase responses. The estimator is digging through 200-page bid packages to find the addendum the GC posted yesterday on portal #2. None of this work is visible to the company's P&L, because it's just "what the office does" — but it's the labor that caps how many jobs the firm can run before having to hire another head.
Cash that arrives slower than it has to. The sub bills on the 25th. The pay app goes into the GC's portal. Then what? The sub doesn't know if the GC's PM has reviewed it. If the GC's accountant has rolled it into the master pay app. If the owner has approved that. If the owner has cut the check. If the GC has posted it back to the sub's account. The sub's CFO is running 60-day, 75-day, 90-day cash projections on a status they can't see. Sometimes a phone call to the GC's accountant unlocks the puzzle. Sometimes it doesn't. The financing cost of that opacity — the line of credit the sub has to maintain because they can't predict when cash is actually arriving — is a real, recurring expense.
Retention that drifts and gets lost. Retention should be simple. It isn't. The GC withholds 10% (or 5%, or some other negotiated rate) of every progress payment. The retention sits in the GC's books, owed to the sub, until release at substantial completion. The sub's accountant should know to the dollar what's owed by each GC at each phase of each project. In practice, very few subs can produce that report cleanly. The data lives in the GC's system, the sub's QuickBooks, and a spreadsheet that may or may not be current. Retention disputes at closeout are routine in commercial construction, and they almost always favor the side with better records — which is almost always the GC.
The foreman writes on a steno pad anyway. The supposedly mobile-friendly portals work fine in the office. On a jobsite at 6am, with one bar of LTE and gloves on, the foreman is writing the daily log on a steno pad and a junior PM is transcribing it after lunch. That delay matters: productivity issues spotted in real time cost the sub a half-day; spotted three days later they cost a week. Every commercial-construction technology survey for the last decade has named field adoption as the #1 unsolved problem, and the reason is the same: the apps were built for the office and handed to the field, not designed for the field from day one.
Add these four costs together and what they buy the sub is the ability to take fewer jobs, finance more working capital, fight more closeout disputes, and lose more days to delayed field signal. None of it shows up as a software line item. All of it is real.
Why nobody built the operating system the subs actually needed
If the gap is this obvious, why hasn't somebody filled it?
Two structural reasons. First, the addressable market math is harder. A GC platform sells to a firm with one buyer, often a CTO or COO, and the deal is sticky once it lands. A sub platform sells to a firm where the buyer is also the founder, the deal cycle is faster but smaller, and the customer base is more fragmented. Most construction-software venture capital has gone toward the GC-shaped market because it looked more like enterprise SaaS.
Second, building for subs requires solving operationally distinct problems — ITB inbox, sub-side pay app, retention by GC, AP-against-PO, foreman tooling — that don't reuse cleanly from the GC stack. A GC platform that wants to extend down to subs has to either bolt on a different product or rebuild its core abstractions. Most have tried the bolt-on path and most of those modules are sparse on functionality, expensive per seat, and built for a different buyer's workflow.
The market kept waiting for the GC platforms to "extend" properly. They didn't.
What changes when both sides of the project share a record
Here's the part that nobody has built, and that we think is the most important strategic move available in construction software right now.
When a GC and a subcontractor both operate on the same platform, the data handoff between them disappears. The sub's pay application against the schedule of values is the same record the GC reviews and certifies. The change order the sub submits is the same record the GC approves. The retention the sub tracks is the retention the GC owes. There's no document upload, no PDF rename, no version reconciliation, no portal-to-portal export.
For the sub, this changes the cash-flow math immediately: the moment the GC certifies the pay app, the sub sees the status change. The moment the owner approves it, the sub sees that too. The moment the GC posts the payment, the sub's AR shows it. The 60-90 day projection horizon collapses into a working visibility window. The accountant stops chasing status by email and starts working from a live ledger.
For retention, it solves the records problem at the source: the sub's retention balance and the GC's retention liability are literally the same row in the same database, so the dispute that used to happen at closeout doesn't happen because there's nothing to dispute. Either both sides see the same number, or the platform's audit trail shows exactly when and why it diverged.
For RFIs, submittals, change orders, daily logs, drawing markups — same story. One record across the table. No document handoff. No version drift. No "we sent it on the 14th, we don't know why you didn't get it."
This is the strategic difference. Not "better sub software" or "better GC software" but a different topology for the project record itself.
What AOS is building, and who the beta is for
AOS is the unified operating system we've been describing. It's built multi-tenant from the ground up so a sub, a GC, an owner, an architect, and a residential builder can all operate on the same database — each through interfaces tuned to their work, but sharing the same project record when they're working on the same project.
For subcontractors specifically, AOS provides:
- An ITB inbox with GC bid documents pre-parsed — no more digging through 200-page packages to find the addendum
- Pay-application generation against your own schedule of values, AIA G702/G703 from the sub side
- Retention rollforward by GC client, with the dispute-proof audit trail one record gives you
- Lien-waiver lifecycle management across all 51 jurisdictions
- AP automation against the PO and the budget
- Subcontract management with insurance and COI tracking
- Self-perform crew scheduling with drag-to-reschedule and geofenced timesheets
- Equipment tracking from yard to site, with a ship-out gate that drafts a GL entry for every inventory move
- Voice-to-log daily reports that work in the field at 6am with one bar of LTE
- Drawing markup from mobile, not a flat PDF viewer
- 1099 prep across your own lower-tier subcontractor stack
- Job-cost reporting by GC client and by trade so you actually know your margin where you make it
This is an operating system for the sub's own business. Not another GC-hosted portal.
The subcontractor product overview walks through it in more depth, with role pages for the sub owner / executive, the sub PM, the foreman, and sub accounting.
And on the other side of the table
For the both-sides-on-one-record advantage to actually land, the GC across the table has to be on the platform too. That's why our beta is open to subs and GCs together. A sub running AOS gets immediate value on day one — the ITB inbox, the pay app, the retention rollforward, all in one place. But the compounding value — the disappearance of the document handoff seam — arrives when their GC clients are also on AOS.
For GCs, AOS provides the full stack of what you'd expect: pre-construction (takeoff, estimating, ITB, bid leveling), project management (drawings, RFIs, submittals, change orders, daily logs), construction accounting (AIA G702/G703, AP with tiered approvals, AR, retention, lien waivers), field operations, owner reporting, and compliance. The GC product overview has the details.
What you don't get anywhere else — and the reason we're co-targeting both sides in the beta — is the data topology. A GC on AOS that works with a sub on AOS shares the project record without handoffs. That's the actual game.
What we're looking for in design partners
We're being selective about the beta — not because the platform isn't ready, but because the right early customers do more for the roadmap than later customers ever will. We're looking for:
- Commercial subcontractors, trade-agnostic, with emphasis on self-perform specialty trades (concrete, steel, drywall, MEP, glazing, finishes, roofing, sitework). Size range $5M to $100M+ — we're casting wide to learn which segment fits best.
- Mid-market commercial general contractors, $20M to $500M annual volume, running mostly self-perform or hybrid models.
- Firms willing to engage on the roadmap — we want operators who'll tell us what's missing and what's wrong, not feature-checkers.
- Local firms get a slight tilt for our sake (easier to do in-person workshops), but we're open to anywhere in the US.
Design-partner pricing is discounted relative to the post-beta tier, with the trade being roadmap input and a willingness to share what does and doesn't work in the field. Apply at our contact page or email hello@aos.build directly.
The bet
The bet underneath AOS is that the right next move in construction software isn't another GC platform with better widgets, and isn't another sub-side bolt-on. It's a platform whose core abstraction is the project record — shared by both sides of the table, tuned per role, billed as one bundle instead of as a vendor patchwork. Subs are the most under-served seat in the current market, which means the value lands hardest there first. GCs benefit when their subs are on the same record. The compounding starts as the network builds out.
If you're a subcontractor or a GC who's tired of paying the integration tax with office labor — we'd love to talk.