The stack before Jet
For nine years, CPM Commercial Builders ran its construction operations on Procore. The platform was deeply embedded in how the team managed active projects.
But Procore was not the whole operating environment.
Preconstruction tracking lived largely in Smartsheet. Project startup, bid and procurement tracking, scheduling, and other preconstruction activities were managed there before a job fully transitioned into construction.
Excel served as the working layer for project financial controls — including the project budget, cost tracking, commitments, change exposure, forecasting, and the reports project teams and leadership used to understand where a job stood financially.
Procore became the primary construction platform once the job was active.
Each tool worked for its part of the process. The problem was what happened between them. The project moved forward, but its information did not always move with it cleanly.
Where the friction showed up
The biggest issue was translation between systems.
Information created during preconstruction had to be carried into the construction environment. Financial information maintained in Excel had to stay aligned with what was happening operationally in Procore. Changes, commitments, forecast assumptions, and current project status still had to tell the same story even when the underlying work lived in different places.
That meant project managers spent time reconciling information instead of simply managing the job. During reporting cycles, the team could find the answer — but assembling it often meant checking multiple systems, updating the financial model, and rebuilding the version of project status leadership actually used.
The problem was not access to information. It was the manual work required to connect it.
Why CPM agreed to test Jet.Build
CPM was not actively looking to throw Procore out.
After nine years, the team knew the platform well and had significant operating discipline built around it. What got their attention was the possibility of reducing the systems and manual work surrounding Procore rather than simply replacing one construction tool with another.
Jet.Build gave CPM a way to test that question without making a companywide decision first: take one live project from preconstruction through closeout and see whether a more connected workflow actually held up in practice.
One project, preconstruction through closeout
The pilot began in 2024 during preconstruction on the DFW Mixed-Use Corridor, a 425,000-square-foot, $165 million design-build project in the Dallas–Fort Worth market.
Rather than isolate one feature, CPM used the project as a lifecycle test. The confirmed major workflows run in Jet.Build included takeoff, pay applications, punch list, and closeout.
The project ultimately involved 46 internal users and 138 external users — 184 participants in total — and ran through closeout in mid-2026.
This was the point of the pilot: not to prove that a single module worked, but to see whether a live commercial project could stay connected as it moved from early planning through final closeout.
The preconstruction-to-construction handoff
One of the most important differences was continuity.
The project did not have to stop being a “preconstruction project” and become an entirely new “construction project.” The project record could carry forward as the job moved into its next phase rather than forcing the team to recreate context across separate systems.
Budget context, project-team information, vendor information, documents, history, and prior decisions remained part of the same project environment.
In practical terms, the handoff stopped feeling like a handoff. The project simply moved into its next phase.
Project financial controls
The financial picture also became more connected to the project activity around it.
Before the pilot, Excel was an important working layer for project financial controls and reporting. During the Jet.Build test, CPM was able to evaluate what it looked like when financial activity and project workflows lived closer together rather than requiring the team to reconstruct the current picture across separate tools.
Excel could still serve specific accounting or analysis needs. The difference was that it no longer had to be the place where the team rebuilt the operational story of the project from scratch.
For the team, financial reporting shifted closer to a review process and further away from an assembly-and-reconciliation exercise.
Construction workflows without relearning construction
Nine years on Procore meant CPM's team was already fluent in the discipline of running projects through construction software.
Moving into Jet.Build did not require them to relearn how to manage a project. The learning curve was about where the workflows lived, how the information connected, and how to operate the specific processes being tested in the pilot.
That distinction mattered. A platform change did not have to mean abandoning nine years of operational knowledge. The construction discipline transferred; the workflow around it changed.
Service and adoption
The rollout also felt different from a conventional software handoff.
CPM received hands-on training and a dedicated point of contact who worked with the team to understand how they actually operated, configure the project, and help users get value from the platform rather than simply provision accounts.
For a pilot involving 184 internal and external participants over the life of the project, that support model mattered. Adoption was treated as part of implementation, not something CPM had to solve after the software was turned on.
What the pilot proved
The pilot ran from preconstruction in 2024 through project closeout in mid-2026.
CPM did not need to make a theoretical decision about whether a different platform could support a commercial GC. They tested the question on a $165 million live project.
The project demonstrated that a Procore-native construction team could carry its operating discipline into Jet.Build, connect workflows that had historically lived across multiple tools, support a large group of internal and external users, and run the project through closeout without treating the platform change as a reinvention of how the team builds.
The pilot was intentionally one project. CPM may continue to use Procore elsewhere. The value of the test was that the comparison happened against real work, over the full life of a real project, rather than inside a software demo.
In their words
I'd tell them to look at everything they're still doing outside Procore. We had used Procore for nine years. The question wasn't whether Procore could run construction workflows — it could. The question was why we still had preconstruction in one place, project financial controls in another, and construction operations somewhere else. If your team is still maintaining spreadsheets, trackers, separate reporting processes, or manual handoffs around the platform, that's probably where the opportunity is.
— Project Executive, CPM Commercial Builders
What this means for commercial GCs evaluating a Procore alternative
A long-time Procore user does not necessarily have a Procore problem.
The more useful question is what still happens around Procore: which spreadsheets remain essential, which preconstruction trackers sit outside the platform, which reports have to be rebuilt manually, and where information has to be translated as the project changes phases.
CPM's experience suggests a practical way to evaluate that question: do not start with a companywide replacement decision. Test one representative project from preconstruction through closeout and judge the operating model against real work.
For CPM, that meant evaluating Jet.Build not as another module sitting beside the existing stack, but as a way to connect more of the project lifecycle in one environment.