Every tool you add multiplies the work between them.
Each tool in a construction stack is usually good at its job. The cost is in the gaps: the exports, the re-keying, the sync that broke last Tuesday, the two reports that don't agree. That's the integration tax. Here is the math behind it.
8 tools · 28 connections · 4 versions of one number
01 · The integration math
Systems add up. Connections multiply.
Drag the slider. Every pair of systems is a place where data has to cross, by an integration or by a person.
212
Connections to build and maintain
15
6 × 5 ÷ 2
Hand-offs for one record to reach every system
5
N − 1
Places a number can disagree
6
one copy per system
Adding system #6 added 5 new possible connections.
Estimating
Scheduling
Project mgmt
Field app
Accounting
Billing sheet
Payroll
Documents
Photos
Procurement
Equipment
Reporting
Every line is a possible point-to-point integration
Why N(N−1)/2 matters
Each of N systems can talk to the other N−1. Count every pair once and you get N(N−1)/2. That number grows with the square of N: 4 systems make 6 pairs, 8 make 28, 12 make 66. The seventh tool doesn't add one connection. It adds six.
Not every pair is wired
Real stacks don't build all of them. The pairs left unwired are still there; they're bridged by people with exports, email and spreadsheets. Either way, someone owns that gap: a developer maintaining a sync, or a coordinator re-typing a number.
Copies drift
When N systems each store the record, there are N places a number can be wrong. A hub reduces the wiring to N connections, but each tool still keeps its own copy. Only one data model gets you to one copy.
02 · Follow one record
One record, many hand-offs.
Pick a record and match the route to your stack. Every hand-off between tools is a re-key, an export or a sync someone has to check. Put in your own minutes and volumes.
Your stack tap a link to merge two steps into one tool
Field appIssue logged with photos
Project managementCO drafted, linked to the RFI
EstimatingPriced with markup
AccountingBudget revised, sub commitment changed
Billing spreadsheetNew SOV line on the pay app
ReportingWIP and forecast re-run
Email inboxInvoice arrives as a PDF
Project managementPM approves against the commitment
AccountingEntered to AP, coded to a cost code
Lien waiver trackerWaiver collected before payment
ReportingJob cost report updated
Field appCrew, weather, work done, photos
Photo storagePhotos filed by job and date
Project managementIssues become RFIs
TimekeepingHours entered by cost code
AccountingLabor cost posts to the job
AccountingContract and approved COs
Billing spreadsheetG703 progress per SOV line
Project managementPM confirms percent complete
DocumentsG702 signed and filed
EmailSent to the owner and architect
ReportingBilled to date and retainage on the WIP
One data core
One recordChange orderEvery step above happens on the same record. Each team sees its own view; nobody types it again.0 hand-offs · 1 copy
Not a benchmark. The minutes and volumes are yours to set; we don't publish industry averages we can't source. It counts only the hand-offs, not the time spent finding out two copies disagree.
03 · Three architectures
Every approach is a trade.
There's no free option. Here is what each architecture is good at and what it costs, plainly.
A · A best tool for each job, wired together
Point tools + integrations
Strengths
Best-of-breed for each task: each team picks the tool it likes
Start small and add one tool at a time
Swap a single tool without moving everything
Trade-offs
Connections grow as N(N−1)/2; each one needs an owner
Integrations break on updates and field-mapping changes
Every tool keeps its own copy, so numbers drift
Cross-tool reporting means exports and spreadsheets
B · A strong ledger with field tools attached
ERP + bolt-on project management
Strengths
One general ledger with mature accounting controls
Job cost, AP and payroll in one place
A known path for audits and month-end close
Trade-offs
Project and field tools often run on a separate data model that syncs
Field data reaches accounting late, so job cost lags
Customization and upgrades can be slow and costly
Field adoption depends on the bolt-on, not the core
C · Projects, accounting, analytics and agents on one model
One operating system, one data core
Strengths
One record: entered once, used by every module
Job cost, billing and WIP current as work is logged
One permission model and one audit trail
AI agents read the real record, not an export
Trade-offs
May not match every edge feature of a specialist tool
A bigger switching decision: more moves at once
More reliance on one vendor, so data export has to be real
os.construction is young: projects and project financials are live, accounting is Planned
Our bet: for most contractors, one record beats a slightly better edge feature in one tool, because job cost, billing and the forecast all depend on the same numbers. If a specialist tool is critical to how you work, keep it and connect it to the core through the REST API. One integration is easier to own than a web of them.
Project management and project financials are live with a 14-day free trial. Founding contractors get a direct line to the team and a say in what ships next.