Unit Price Analysis and the Limits of Generic Estimating

A unit price is not a price. It is the result of a calculation, and the calculation is the asset. A square meter of formwork is some quantity of material, some fraction of a crew day, some share of equipment time, and some allocation of indirect cost — and when the price of plywood moves, every unit price that consumes plywood should move with it. Generic estimating tools store the result. Unit price analysis stores the structure that produced it.

Quick Summary

• A unit price decomposes into materials, labor, equipment and indirects, each with a yield: how much of it one unit of work consumes.
• The yields are the company-specific part. They are what makes one contractor’s estimate different from a published price book, and they are rarely written down anywhere.
• A spreadsheet can compute a unit price correctly but cannot maintain the dependencies, which is why re-pricing a project is a manual exercise.
• The same decomposition that produces a quote can drive purchasing and budget control, if it is stored as a model rather than recalculated in each system.
• 62% of firms still estimate in spreadsheets, which is less a technology failure than a sign that the available tools do not model yields.

This is one of the clearest cases of the pattern described in what construction companies build when their platform runs out: the process is specific to how the business makes money, and the platform models a simpler version of it.

What Does a Unit Price Actually Contain?

Four components, and the fourth is the one that gets lost.

Direct materials, with a consumption factor rather than a quantity. One square meter of a wall does not consume one square meter of material; it consumes some amount plus waste, and the waste factor is itself a company judgment based on crew skill and site conditions.

Labor allocations, expressed as crew composition and yield. Not “two hours of labor” but “a crew of one specialist and one helper, at a yield of X units per shift.” The distinction matters because when wage rates change by trade, the unit price has to recalculate by trade.

Equipment and tools, allocated by time rather than owned outright. A concrete pump is not consumed by one unit of work — some fraction of a shift is, and that fraction depends on the pour sequence.

Transport and logistics, which is the one most often omitted and the one that bites on sites with difficult access. Material that has to be hoisted to the eighth floor costs more to place than the same material at grade, and if the model has no place to put that difference, the estimator buries it in a fudge factor that nobody can audit later.

It is worth noting what the industry’s standard frameworks do and do not cover here. The CSI MasterFormat system organizes specifications and cost codes into divisions, which gives everyone a shared vocabulary for what work is. It says nothing about what a unit of that work consumes. The decomposition is the part each contractor has to own.

CodeBranch built a unit price analysis engine for an electrical contractor as part of a budget control platform, and structuring these four components — rather than storing a price per item — is what let the same model feed quoting, purchasing and budget tracking.

Why Is a Yield Harder to Model Than a Price?

Because a price is a number and a yield is a judgment with conditions attached.

The price of a bag of cement is the price of a bag of cement. The number of square meters of wall a crew finishes in a shift depends on the wall, the height, the access, the weather, the crew, and whether they are doing it for the first time on this project. Every experienced estimator knows this and adjusts. Almost no system stores the adjustment.

There is a sharper way to put the asymmetry: price data can be bought, and yield data cannot. The U.S. Bureau of Labor Statistics publishes producer price indexes covering construction inputs, and commercial cost databases sell unit prices by region. Nobody publishes how many square meters of wall your crews finish in a shift, because that number is yours.

This is the crux of why generic tools fall short. They are built to hold prices, which are stable and external, and they treat yields as a single number you enter once. A contractor’s actual yields vary by condition, and the variance is not noise — it is the accumulated knowledge that makes their estimates better than a competitor’s.

The design question is how much of that variance to model explicitly. Too little and the system is a price book with extra steps. Too much and nobody can maintain it. The useful middle is usually a base yield with a small number of named modifiers that an estimator applies consciously, so the adjustment is recorded rather than absorbed.

What Does This Buy You Beyond the Estimate?

The decomposition is reusable, and that is the part that justifies building it.

Purchasing comes from the same model. If a budget line knows it consumes 1.05 units of a material per unit of work, the requisition can be generated from the quantity of work scheduled, rather than reconstructed by someone reading the plans a second time.

Actuals compare against assumptions. When the work is done, what was actually consumed can be set against the yield that was assumed. That comparison is the feedback loop that makes the next estimate better, and it exists only if the assumption was stored in a form that survives.

Change orders re-price instead of re-estimate. A design change that adds twenty square meters of a known assembly is a quantity change against an existing unit price, not a new estimating exercise.

None of those three is available if the unit price is stored as a number. All of them follow automatically if it is stored as a structure.

Why Do 62% of Firms Still Estimate in Spreadsheets?

Because the spreadsheet does the one thing that matters — it models the calculation — and the alternatives often do not.

In the last systematic survey of construction technology, 62% of firms relied on spreadsheets for estimating. That is usually read as a failure to adopt technology. It is at least as much a verdict on the technology: an estimator who can express a yield relationship in a spreadsheet and cannot express it in the estimating platform is making a rational choice.

What the spreadsheet cannot do is hold the relationships over time. The formulas are there, but the reasoning behind them is not, and when the person who built the file leaves, what remains is a working calculator nobody dares modify. The same survey found 49% of firms moving data between applications by hand, which is the downstream symptom: the estimate lives in one place and everything that should flow from it lives somewhere else.

Replacing spreadsheets with something worse is a common and expensive mistake. Replacing them with something that models the same relationships and also persists them is the actual goal.

How Does the Model Survive Being Used in the Field?

By exposing less of itself than it contains.

The same unit price logic that an estimator uses in an office has to produce a number when a salesperson is standing in front of a client with no laptop. CodeBranch built both ends for the same contractor: a web quoting platform with floor plan design and component-level detail, and a mobile app that produces a budget from a form of five to ten questions.

The mobile version does not use a simplified pricing model. It uses the same model with most of the inputs derived rather than asked. The questions cover what a non-expert can observe — how many lighting zones, how many motorized curtains — and the yields, crews and material consumption are applied underneath.

That is the general principle and it is worth stating plainly: the complexity belongs in the model, not in the form. A system that requires an expert operator to produce a correct number has moved the knowledge into the operator, which is where it was before the software existed.

What Has to Be True Before Building This?

The organization has to agree on its own yields.

This sounds administrative and it is the part that derails these projects. In most contractors, the yields are distributed across several senior estimators who do not all use the same numbers and have good reasons for their differences. Writing them into a system forces a decision that was previously implicit, and that decision is not a software decision.

CodeBranch surfaces this during Product Definition rather than discovering it in development, because a company that cannot settle its yields is not ready for a system whose entire value rests on them. Sometimes the right outcome is to formalize the estimating practice first and build the software after.

When the yields are settled, the rest is tractable. When they are not, no amount of software makes the estimate better — it just makes the disagreement faster to produce. That sequencing, settle the model and then build on it, is how CodeBranch structures software for construction companies, and estimating is the clearest case of why the order matters.