Every software vendor says their product “integrates.” It’s on the pricing page, usually next to a logo wall. And it’s technically true: there is a way to get data from their tool into another tool.
What they mean by integration is a pipe. When something happens in system A, a copy of it gets pushed into system B. Sometimes on a schedule, sometimes through a third service you also pay for, sometimes through a spreadsheet export and a person. The two systems still have their own separate ideas of what a customer is, what a job is, what “done” means. The pipe just keeps the copies roughly in sync — until it doesn’t, and someone spends a morning figuring out why the invoice total and the estimate total drifted apart again.
That is not software speaking to itself. That’s software leaving voicemails.
One record, many views
What we build is different at the foundation, not the surface. There isn’t a CRM and an estimating tool and a project tracker and a materials system with pipes between them. There’s one platform, with one model of your business, and every screen is a different view of the same underlying record.
Concretely, that means a job is one thing. It comes into existence as an opportunity when the phone rings. The estimate is attached to it — not exported to it, attached, the same object. When the estimate is won, the job doesn’t get “sent to” project management; it’s already there, because there’s no there to send it to. The materials pulled for it, the hours logged against it, the messages the crew sent about it, the invoice that goes out — all of it hangs off that one record.
So when the owner asks how did that job actually do, nobody exports anything. The answer was being assembled the whole time, by the ordinary act of people doing their work.
The part your team notices
The architecture is our problem. What your team notices is what disappears.
Nobody retypes the estimate into the invoice, because they are the same numbers in the same place. Nobody updates the whiteboard to match the system, because the system is the whiteboard. Nobody sends the “hey did we order the lumber for the Thursday job?” text, because the pull ticket is visible to everyone who needs it, and its status changes when the yard changes it.
The reconciliation work — the checking, the matching, the wait which version is right — just doesn’t exist. Not because anyone got better at it. Because there’s only one version, so there’s nothing to reconcile.
What it looked like in practice
Heritage Beam & Board is a regional construction business, and before we worked together they ran on the pattern we described in the first post of this series: spreadsheets, disconnected tools, and a lot of knowledge that lived in people rather than systems.
We built them one platform covering operations, estimating, the CRM pipeline, project management, materials and pull tickets, and team communication. Roughly two months from start to live in production. It has been running since April.
The individual pieces aren’t exotic. A dashboard, an estimator, a pipeline board, a ticket workflow, a chat. You could buy a separate product for each of those tomorrow. What you couldn’t buy is the fact that in their platform, those are six views of the same jobs — so a pull ticket knows which estimate it came from, and the dashboard’s margin number is real because it’s built from the same line items the crew is actually working.
That’s the whole difference. Not more features. Fewer copies.
Why we don’t start with the software
It would be faster, in the short term, to skip to the build. We don’t, and the reason is the thing that makes “one record” possible: you have to know what the record is.
What is a job, in your business? Where does it start — the first call, the site visit, the signed proposal? What has to be true before it’s “ready to schedule”? Who needs to know when materials arrive? Every business answers those differently, and the answers are the data model. Get them wrong and you’ve built a very fast version of the wrong thing.
So we start by drawing it, with you, before anything gets built. Then we audit it properly — interviewing the people who actually run each function and documenting the process end to end. The build comes out of that, and it fits, because it was designed from your answers rather than the average of everyone’s.
Software that speaks to itself isn’t a feature you can add. It’s what you get when you build from one honest picture of how the business runs.