Every sell rate in a priced schedule sits on top of six layers. Build them and the estimate can answer questions; paste in the top layer alone and it can only repeat them.
A first-principles estimate is one in which every rate has been assembled from the inputs that will actually be consumed to produce a unit of finished work — the crew, the plant that crew stands on, the materials placed and wasted, the subcontract packages engaged, and the rate at which that combination produces. Nothing is inherited whole. The component rates and the productivity evidence come from somewhere, of course, but they arrive as stated inputs a reviewer can argue with, not as one figure to be taken on trust.
The alternative is to carry a rate across: from the last job, from a published schedule, from a spreadsheet nobody has opened in three years. That is not illegitimate. But it is a different kind of number. A carried rate records what one unit of work cost once, under site conditions and market timing that were never written down, and it arrives with no internal structure. When the haul doubles or the work moves to night shift, it can only be nudged by judgement.
This is the practical argument for building. Not that built rates are automatically more accurate — a careless build-up with an optimistic production rate will beat a sensible benchmark for sheer wrongness — but that they are adjustable and defensible. Every change to the job becomes a change to a named input, and the arithmetic that follows is not a matter of opinion.
TX1:Trinity takes any unit rate apart down to the crew line, plant item and material row that produced it, on your own machine and your own library. Install it and price one real item end to end.
Start a free 14-day trialWork upwards. At the bottom sits the resource: one priced thing with one unit — an operator hour, a tonne of asphalt, a day of a 30 tonne excavator, a lump sum from a line-marking subcontractor. A resource rate is not a wage and not an invoice price. Labour carries on-costs, superannuation, workers compensation, leave and non-productive time; plant carries ownership, maintenance, tyres and fuel; materials carry delivery and the portion that never reaches the works. Get this layer wrong and nothing above it can be right.
Next comes the built-up resource: a crew or plant spread assembled from component resources and published as one hourly figure. A kerbing crew is a foreman, finishers, labourers and an operator, standing alongside a slipform machine, a small excavator and a truck on part-time call. Building the crew rather than the person is what stops the classic error of pricing productive hands while the idle plant beside them runs free.
Above that is the direct cost item: the schedule line with a quantity and a unit. It is where the crew rate meets the production rate — the quantity that crew delivers per hour under the conditions this job will actually impose. Divide the crew cost by the production rate, add the material consumed per unit, and you have a direct rate. Two numbers of equal weight sit in that sentence, and estimators tend to spend nine-tenths of their care on the first.
Then overhead apportionment. Site establishment, supervision, traffic management, environmental controls and testing are real costs belonging to no single item. They are gathered into a pool and spread across the items that caused them, so what lands on any one line depends as much on the distribution rule as on the size of the pool. Above that sits markup — business-level recovery, legitimately different for own labour and for a subcontract package already carrying somebody else’s overheads. Finally the sell rate: the number in the schedule, and the only layer the client ever sees.
What one hour, tonne or day genuinely costs once on-costs, ownership, delivery and non-productive time are inside it. Wrong here, wrong everywhere.
How much finished work the crew delivers per hour on this site, with this access and this supply chain. The most leveraged number in the estimate.
What is actually paid for per unit placed: loss on haul, trim allowance, over-order, laps and offcuts. Small percentages on the largest quantities.
Each layer fails in its own way, and the failures do not look alike from outside. Some produce an estimate that is uniformly wrong and therefore obvious. Others produce a total that looks entirely reasonable while the individual rates are badly distorted — far more dangerous, because that error survives review and surfaces only once the work is being claimed.
| Layer | What you build here | What a guess here costs |
|---|---|---|
| Resource | One priced input with one unit: labour with on-costs, plant with ownership and running cost, delivered material, subcontract package. | A systematic error repeated in every item that touches it. Because it is uniform, review rarely catches it. |
| Built-up resource | A crew or plant spread published as one hourly rate, equal to the sum of its component rows. | Idle plant priced as free, or a crew that could not physically perform the stated methodology. |
| Direct cost item | Crew rate divided by production rate, plus material consumed per unit, at the quantity measured. | The largest single source of estimate error. An optimistic production rate is invisible in the total and fatal on site. |
| Overhead apportionment | Time-related and fixed site costs pooled, then allocated to the items that drive them. | A total that is right while every rate is wrong. Early items look cheap; late items carry costs they never caused. |
| Markup | Business unit and corporate recovery, at rates suited to the resource mix in each item. | Double recovery on subcontract packages, under-recovery on self-performed work, and every make-or-buy comparison distorted. |
| Sell rate | The scheduled rate, traceable back through every layer beneath it. | Nothing to say when the rate is challenged, because there is no working to show. |
The one thing to take from this page: a rate you cannot take apart is a rate you cannot defend, cannot adjust and cannot reuse — and those three properties, not decimal precision, are what make an estimate worth having.
This is the whole argument, and it has nothing to do with precision. Suppose the diesel rate moves. In a built estimate that number lives in exactly one place. Change it, and the plant rates that consume diesel recompute; the crew rates built from those plant rates recompute as the sum of their component rows; every item priced with those crews recomputes; the overhead pool recomputes where it holds plant-based costs, and so does its apportionment across items; markup, calculated on a base that has just moved, recomputes; and every sell rate lands on a new number. One edit, one pass, and the estimate is internally consistent again.
In a pasted estimate the same change is a project. Someone has to work out which of several hundred rates contain diesel, in what proportion, and by how much each should move — and because the working was never recorded, that person is reconstructing an argument rather than recalculating an answer. In practice the change does not get made. The estimate is reissued with a global percentage adjustment, and the relationships between items quietly stop being true.
That is what is really lost when rates are carried instead of built. Not accuracy on the day of issue — a good benchmark can be very close — but the ability to stay correct as the job changes. Estimates are not read once. They are revised at every gate, re-based when the programme slips, interrogated when tenders come in above budget and dismembered when a variation is disputed. A built estimate survives that. A pasted one degrades from the moment it is issued, invisibly, until someone needs it to be right.
Precision at the bottom, guesswork in the middle. The commonest pattern in a poor build-up is a resource list priced to the cent sitting beneath a production rate somebody recalled. It looks rigorous, because the laborious work is the visible part, but the number governing the answer received no evidence at all. Research the crew cost, invent the output, and you have a guess with a decorative substructure.
Pricing the people and forgetting the machine. When a crew is assembled from labour lines only, the plant standing alongside disappears from the hourly rate and reappears, if at all, as a lump allowance in the preliminaries.
Nominal consumption factors. Concrete priced at the neat design volume; fill priced in-situ with no allowance for compaction and loss; reinforcement priced without laps and offcuts. Each error is small as a percentage and large in aggregate, because it applies to the biggest quantities in the schedule.
Flat-percentage overheads. Site overheads spread evenly across every item regardless of duration. A traffic management regime running eight months is loaded onto the items that finish in week three exactly as heavily as onto those that caused it. The total is unaffected, which is why this survives review, but the rate structure is now misleading — and it is the rates, not the total, that value variations and price the next job. The anatomy of an estimate is where that distinction does the most damage.
Uniform markup across a mixed resource base. The same percentage applied to a self-performed earthworks item and to a fully subcontracted electrical package means the package carries margin twice: the subcontractor’s and yours. Markup that varies by resource type is not a refinement; it is the minimum required to keep make-or-buy comparisons honest.
No base date. Undated rates cannot be escalated, compared with the estimate that preceded them, or defended once the market has moved. Recording the base date costs nothing and converts a stale estimate into an adjustable one.
Not every item deserves this treatment, and pretending otherwise wastes hours that belong to the items that matter. Sort by value, build what carries the cost, price the tail from quotations — then record which is which. Undisclosed mixed methods are how a reviewer loses confidence in everything else you have done. Which items must be built and which may be carried is set by the class of estimate you are producing, not by preference.
TX1:Trinity is a Windows desktop application on WPF and .NET over an EF Core and SQLite store, so the estimate is a local file rather than a tenancy on somebody’s server. Each of the six layers is a first-class object, not a spreadsheet convention the next person has to reverse-engineer. Resources are catalogued under a structured code — TYPE.FAMILY.SPEC[.MOD].PER.UNIT — with the leading letter naming the type: L. labour, P. plant, M. material, S. subcontract, O. other, G. group.
A group resource is the built-up layer: its published rate is the sum of its contributing component rows, recomputed rather than typed, so a crew cannot drift from the parts it is made of. Base rates carry an applied factor, EffectiveBaseRate = BaseRate × AppliedFactor, which holds a location, shift or condition adjustment as a visible multiplier instead of burying it in a hand-edited number.
Items are priced through a formula engine — a shunting-yard parser over an abstract syntax tree with a dependency graph and cycle detection, more than seventy functions, project and scoped parametrics written as #name, assignment with set(#VAR, expr), and line references such as #dc_total and SUM(L61:L62). That dependency graph is what makes the cascade automatic: the engine knows which values depend on which, so a change propagates in the right order and a circular reference is reported rather than silently producing a number.
Overheads are allocated rather than smeared, and the sell rate resolves as CalculatedSellRate = DirectRate + (TotalAllocated / Qty), so the apportioned part of every rate stays separable. The pipeline runs direct costs plus overheads to a total cost, then markup per resource type, then margins for risk, corporate recovery and profit. Libraries move between projects as .tx1 packages — compressed, checksum-validated, optionally AES-256 encrypted — which is how a build-up standard becomes an organisational asset instead of a personal one.
First-principles estimating builds every unit rate from the inputs that will actually be consumed to produce one unit of finished work: the crew, the plant on the crew, the materials placed and wasted, the subcontract packages engaged, and the rate at which that combination produces. Nothing in the rate is inherited from a previous project except the component rates and the productivity evidence, both of which are stated and can be argued with. The output is a rate you can take apart in front of a reviewer.
A benchmark rate is a record of what one unit of work cost on some other job, under conditions that were usually not written down. It is a single number with no internal structure, so it cannot be adjusted for a different haul distance, a different crew, night work or a wet season without guessing. A built-up rate holds its components separately, so each of those changes is a change to one input rather than a judgement about the whole number.
No, and trying to is a poor use of estimating hours. Sort the schedule by value, build the items that carry the cost, and price the long tail of minor items from benchmarks or supplier quotations. A mixed approach is normal practice and is recognised in the PCEM framework. What matters is that the basis of each rate is recorded, so a reviewer can see at a glance which numbers are built and which are carried.
Derive it rather than recall it. Work out how many cycles the governing resource can complete in an hour, apply a realistic efficiency allowance for the site, and sanity-check the result against the constraint that actually limits the crew, which is often the haul, the delivery interval or the curing window rather than the machine. Then write the derivation into the item. An estimator who documents an arguable production rate is in a much stronger position than one who quotes a confident number with no working.
Install TX1:Trinity, price one real item from its resources up, then change a component rate and watch the schedule move. The whole argument, in twenty minutes.