The cost data that actually matters in construction has never lived in a software platform. It lives in completed jobs.
Watch
How To Estimate Jobs For Contractors · Estimating 101
Featured talk · Will Spaulding
Hawktress is an attempt to fix that.
Every estimating platform in the market is built on the same premise: give builders a place to input numbers. The assumption is that builders already know what those numbers should be. For a first-time estimate on an unfamiliar build type, in a market you haven't priced in six months, that assumption is where margin starts to erode.
The problem is not that builders lack tools. It is that the tools lack real data.
Published cost guides, QS indices, and square metre rates are useful for feasibility. They are not useful for live estimating decisions. They are averages, smoothed across geographies, build types, and time periods that may no longer reflect current conditions. By the time that data is published, it is already historical.
The data that is actually reliable comes from one place: jobs that have been built and reconciled. What a concreter charged per square metre for a waffle pod slab in a specific postcode, in a specific month, with specific site conditions. What a joinery package cost for a 280m² custom home with stone benchtops, full-height cabinetry, and a butler's pantry. What the delta was between the estimated and actual cost, and why.
That data exists. It just has not been captured in a structured, queryable format. It sits in spreadsheets, in job files, in email threads, and in the memory of estimators who have priced enough work to develop a feel for what things actually cost. That feel is valuable. It does not scale, it does not transfer, and it disappears when a team member leaves.
Hawktress started as a simple question: what if every job we completed fed data back into the next estimate?
The answer was not to build another estimating platform. The answer was to build a cost intelligence layer that sits behind the estimate, pulling from reconciled project data to validate allowances before they are locked in. A reference database, not a workflow tool.
The architecture is straightforward. A record per trade package, per job, capturing estimated cost, actual cost, variance, postcode, build type, floor area, and completion date. Simple to input. Powerful to query.
The discipline was in what not to build. No dashboards before the data is dense enough to be meaningful. No automation before the input process is stable. Builders who build software the way they build houses, by starting with structure before finishes, end up with something that works.
In practice, an estimator pricing a structural steel package for a two-storey custom home in coastal Victoria can query Hawktress for comparable packages from the last twelve months and use the actual cost range to stress-test their allowance before the estimate is finalised. Not as a replacement for a trade quote. As a check against an allowance that might be sitting 8% below where the market has moved.
That is the function. Not prediction. Not automation. A structured reference that reduces the gap between what an estimator thinks something costs and what a subcontractor is going to charge for it.
The value of the database compounds with every job that feeds it. At fifty reconciled projects, it is a useful reference. At five hundred, it becomes a pricing intelligence asset that no published cost guide can replicate, because no published cost guide is built from the jobs you actually built.
For now, Hawktress is how BuildHawk makes the next estimate more accurate than the last one.
— BuildHawk
