On this page
Walk into the office of almost any mid-size contractor and count the systems. A field app for daily logs and photos. A project management platform for RFIs, submittals and change orders. An estimating tool. Accounting software for job cost, AP, AR and payroll. A document-signing tool. And a spreadsheet, usually several, that someone maintains so all of the above agree at month end.
Each of those tools was bought for a good reason. Each one is probably fine at its own job. The problem isn’t any single app. The problem is the space between them.
The seams are where the money leaks
A construction company runs on a handful of numbers that move constantly: contract value, budget by cost code, committed cost, actual cost, billed to date and cost to complete. Those numbers are touched by the super in the field, the PM in the trailer, the project accountant in the office and the CFO in front of the bank.
When those people work in different systems, every number has to be carried across a seam. Someone exports, re-keys, uploads or reconciles. At every seam, three things happen:
- Latency. A change approved on Tuesday shows up in the job cost report next week, or next month.
- Drift. Two systems hold two versions of the same number, and nobody is sure which one is right.
- Blind spots. Decisions get made on the version that was easiest to pull, not the version that’s true.
None of this shows up as a line item. It shows up as a WIP schedule that takes a week to build, a pay app that misses an approved change order, or a margin fade nobody saw until the job was mostly built.
Why integrations don’t close the gap
The standard answer is integration: connect the PM tool to accounting, connect accounting to the BI tool, and let the data flow.
Integrations help. But look at the math. With six systems there are fifteen possible point-to-point connections, because n systems have n × (n − 1) ÷ 2 pairs. Nobody builds all fifteen. Companies build the three or four that hurt most and cover the rest with exports and spreadsheets. Each connection has its own field mapping, its own sync schedule, its own failure mode and its own owner, usually whoever set it up and has since moved on.
More important: an integration copies data. It doesn’t share it. The PM system has its idea of a change order and the accounting system has its own. The integration translates one into the other on a schedule. When the two definitions don’t match perfectly (one tracks pending COs and the other only approved ones, one splits cost by type and the other doesn’t), the translation loses something. That loss is what your project accountant spends Thursday afternoons fixing.
What we mean by an operating system
An operating system isn’t a bigger app. It’s the layer many apps run on, sharing the same memory, the same files and the same permissions. That’s the idea we’re building around.
For construction, it means one data core underneath everything:
- One record per thing. A change order is one record. The field note that started it, the RFI that documented it, the pricing, the owner approval, the budget revision, the subcontract change and the line on the pay app all reference that one record. Nothing is copied.
- One cost structure. Cost codes, cost types and the schedule of values are defined once and used by the field, PM, accounting and reporting. A super picking a cost code on a daily log picks the same code the general ledger posts to.
- One permission model, one audit trail. Every change, by a person or an agent, is recorded once, in one place: who, what, when.
- Events, not exports. When a change order is approved, everything that depends on it (budget, commitments, forecast, the next pay app) updates because it’s the same data, not because a sync job ran overnight.
On top of that core sit the apps people actually use: field tools, project management, construction accounting, analytics and AI agents. They can look completely different to a super and a controller. What they can’t do is disagree.
“Haven’t all-in-one suites been tried?”
Yes, and the skepticism is earned. Plenty of contractors have bought a suite that promised everything and delivered a mediocre version of each piece. The usual failure: the suite was built around one discipline, often accounting, and the rest was bolted on. The field app felt like an accounting screen. Or the opposite, a PM tool with a thin ledger that couldn’t survive an audit.
So the bar for a construction OS is high, and it’s specific:
- Accounting-grade at the core. Double-entry, period close, a real audit trail, job cost that ties to the GL, AIA G702/G703 billing and retainage handled properly. If the controller doesn’t trust it, nothing else matters.
- Field-fast at the edge. A super logging a hidden condition shouldn’t need to know what a cost type is. The system should make the right thing the easy thing.
- Open at the boundaries. You’ll still have payroll providers, banks, owner portals and equipment telematics. An OS should offer clean imports and APIs instead of pretending the outside world doesn’t exist.
What changes when the seams go away
It’s tempting to describe all this as “saving time on data entry”, and it does. But the bigger change is what becomes possible when every number is current.
- WIP becomes a view you can open on any day, not a project you start on the 25th. More in WIP shouldn’t be a month-end project.
- A change order can’t fall through the crack between “approved by the owner” and “billed on the pay app”, because it’s the same record. See The real cost of re-keying a change order.
- AI agents become safe to use, because they work on the real record with real permissions, and a person approves every action. More in Agents with approvals.
What we’re not claiming
We’re pre-launch. We’re building os.construction now with a group of founding contractors, and we’d rather tell you where we are than pretend otherwise. Replacing a company’s systems is a serious decision. Migration (jobs, cost codes, vendors, open commitments, open AR and AP) has to be boringly reliable. The first version won’t do everything every contractor needs.
But we’re convinced the direction is right. The industry doesn’t need another app on the pile. It needs the layer underneath: one record, entered once, from the jobsite to the general ledger.
If that’s the problem you live with, get early access and tell us what your stack looks like today. That’s how we decide what to build first.
Share this article