AI takeoff software is only as good as the plans it’s learned from. Most of the AI estimating tools sold into NZ were trained somewhere else, on drawings that don’t look like ours. That matters more than people think.
When we started building TakeoffQS, we set one rule early. We’d train our models on NZ residential plans, keep training them on NZ residential plans, and never shortcut that with a generic overseas dataset.
Every framing detail, every scale bar, every symbol the model sees comes from a real plan set produced by an NZ architect or drafter. Six months in, that decision already defines what the product does well and where overseas takeoff software falls over.
Here’s what breaks when the training data doesn’t match the market.
Scale defaults built for the wrong continent
A lot of overseas-built takeoff software was trained on plans from other markets. That means it learned on different sheet sizes, different scale conventions, and different layout standards than NZ drafters use.
Drop an NZ A3 1:100 plan into one of those tools and the scale detection is working across a format it wasn’t trained on. The estimator ends up doing calibration work the tool should’ve done for them.
Our scale detection was trained on A3 and A1 NZ sheets using NZ scale conventions (1:50, 1:100, 1:200). It looks for scale bars and title blocks the way they sit on NZ plans, not the way they sit on American or British ones. Small difference on paper, big difference in whether the first draft lands trustworthy or needs manual rework.
Symbol libraries from another country
Takeoff symbols aren’t universal. NZ drafters draw strip bracing, garage doors, fall arrows, and elevation openings differently from their US or UK counterparts. A model trained on overseas plans will misclassify the symbols or skip them entirely.
TakeoffQS was trained on NZ residential plans end-to-end. The models pull the things NZ suppliers actually need to count and measure:
- Floor plans: exterior walls, interior walls, wall widths, windows, doors, garage doors, floor openings, strip bracing
- Roof plans: outline, catchments, valleys, gable ends, soffits, and fall arrows for pitch and direction
- Foundation plans: perimeter, pods, ribs, beams
- Elevations: cladding surfaces, doors, windows, facade regions
When a plan lands in TakeoffQS, the model already knows what it’s looking at.
Trade terminology built for a different market
Ask most overseas AI estimating tools for a “balance of house” takeoff and they won’t know what you mean.
BoH is a NZ and AU supplier term. It’s the structural and surface quantities a material merchant quotes outside the prenail package: foundations, roofing metrics, cladding, soffits, painting, internal linings.
Overseas-built tools don’t carve the work up that way, because their customers don’t use the term. Ours does, because our customers asked for it.
Same story with prenail. Overseas takeoff software handles it as generic panelised framing. Our prenail output is shaped around what NZ frame and truss yards actually price: exterior and interior wall lengths, window and door openings, and the counts that flow straight into a yard’s pricing spreadsheet.
Plan layouts trained on the wrong drawings
NZ architects lay out plan sets differently from US or UK ones. Title blocks sit in specific positions. Page ordering follows a loose convention: site, floor, elevations, sections, details. Revision clouds and markup follow NZ drafting conventions.
Overseas AI takeoff software struggles with this silently. It processes the pages, but the part that sorts and routes them was trained on a different tradition, so it’ll misroute an elevation as a section or skip a critical detail page entirely. The estimator doesn’t always notice until the numbers come out wrong.
We trained our system on how NZ architects lay out plan sets. It knows where the site plan sits, where the floor plan sits, where the elevations sit, and it pairs those pages up so detections on each page are actually comparing like with like.
Why training data is the moat
Models can be cloned. The plans they learn from have to be earned.
Every verified takeoff that flows through TakeoffQS feeds back into the model. Every correction an estimator makes on a Christchurch townhouse, a Queenstown holiday home, a Hamilton subdivision. Each one sharpens the next plan the model reads.
Six months of this. Only NZ building plans. Growing every week.
If you’re evaluating AI takeoff software for NZ residential work, ask one question. What was the AI actually trained on? If the answer is “global construction drawings” or “tens of thousands of plans” with no NZ specificity, you already know what’ll break.
Same method, next market
We’re already training on Australian and US plans. The UK and Canada follow from there.
Each market gets its own set of training plans, pulled from real drawings produced by local architects and drafters. We’re not porting the NZ model across and hoping it holds. When we land in Australia, the models will know Australian drafting conventions and trade terminology. When we land in the US, they’ll know ANSI sheet sizes, imperial defaults, and US framing conventions.
That takes longer than training once and selling everywhere. It’s the only way to keep producing AI takeoff software that reads plans the way local estimators actually expect.
Elite products are made this way. Patiently, on the right data, for the people who have to live with the output.