Can you stand behind the numbers?
Estimating software lives or dies on that one question. This page explains how TakeoffQS works, what it doesn't do, how we handle your data, and how we secure it. Plain answers to the questions your estimators and your IT team will actually ask.
01How it works
TakeoffQS reads residential plans through a 5-stage pipeline: page classification, detection and segmentation, reading the drawing, geometry and rules, then verification.
- 01 Page classification
- 02 Detection and segmentation
- 03 Reading the drawing
- 04 Geometry and rules
- 05 Verification
The models find things. The geometry computes things.
Detection is the part that can be wrong, and it's the part your estimator can see and check right on the plan. Once an element is confirmed, its length or area comes from arithmetic, so every quantity traces back to something visible on the drawing. A model asked to output the number directly can't offer that trail.
We deliberately don't hand the whole plan to a language model and ask for a takeoff. The failure mode of that approach is confident, plausible, wrong numbers with no traceable origin.
The full technical breakdown, including all 13 detector families and what we're changing next, is in The AI models behind TakeoffQS.
02What it doesn't do
TakeoffQS produces a draft takeoff for supported residential scopes. That's the product. It is not:
- An engineering certification
- A compliance statement
- A bracing calculation We detect and read bracing annotations on the plan, we don't calculate bracing adequacy.
- A finished quote you can send without looking at it
Results also depend on the plans. Clean, complete drawings get better first drafts than scanned, partial or heavily revised ones. And when the system reads a value off a drawing, it validates the reading against a schema; a value that doesn't validate gets discarded rather than guessed at.
03Your estimator stays in charge
We think "how accurate is it?" is the wrong lead question, and we've written about why. Takeoffs fail on wrong scale, outdated revisions and misread symbols. Those are workflow problems, and the fix is a workflow: fast first draft, then verification that's required and fast.
So the contract is explicit
TakeoffQS produces the draft. Your estimator confirms the scale, reviews the detections, corrects the edge cases and owns the export.
Responsibility for the final quantities sits with the professional, and we're not building toward a version where it doesn't.
You'll notice we don't publish a single accuracy percentage. One number can't describe performance across every plan style, page type and scope, and a number that can't be trusted everywhere shouldn't be published anywhere.
Here's what we will say. Once the drawing scale is calibrated, measurement is arithmetic. The length of a confirmed annotation on a correctly scaled plan is the length; the numbers are what they are. The uncertainty lives in detection (did we find every wall?) and interpretation, which is exactly what verification covers.
We audit that number path constantly: from measured geometry, through the variables it feeds, to the quantities that show up in front of your estimator. A quantity that can be derived two ways gets derived two ways, and a disagreement is surfaced rather than averaged.
The target we're optimising for is practical: a takeoff estimate the construction industry accepts, at the tolerances estimators actually price to, produced in minutes and verified by your team.
04Your data
Three things worth saying plainly.
Your corrections train our models
When your estimator fixes a detection, that geometry correction feeds back into training our own detectors. It's how the system gets better for everyone, and it's a big part of why we're building this in NZ on NZ plans.
Your commercial data never does
Pricing, catalogues, margins, quote values: none of it is used to train anything.
No third party trains on your data, ever
Our AI subprocessors are not authorised to use client data for model training. Through the first half of 2026 we moved model training and hosting in-house, onto our own infrastructure, so the training corpus and every model checkpoint sit in our own storage.
Our full subprocessor list, with regions and the categories of data each one touches, is available on request: email privacy@takeoffqs.com. We give clients 30 days' notice before adding to it.
05Security
Everything runs on Google Cloud in the Sydney region (australia-southeast1): the application, the database and file storage.
Tenant isolation is enforced in the database
Queries run behind Postgres row-level security scoped to your organisation. It's a database rule, and our CI blocks changes that would weaken it.
No static database passwords exist
Services authenticate to the database with short-lived Google IAM credentials. Secrets live in Google Secret Manager, scoped to the specific services that need them.
Your files are private
Storage buckets have public access prevention enforced. Plan downloads use short-lived signed URLs.
Backups run continuously
Point-in-time recovery covers the last 7 days, encrypted at rest. Our disaster recovery plan commits to a full restore test at least annually.
Logs are scrubbed
Email addresses, long digit strings and credential-shaped values are redacted before anything reaches our logging systems.
Sign-in
Brokered by Google Identity Platform, with email and Google sign-in. Per-customer enterprise SSO (SAML/OIDC into your identity provider) is on the roadmap.
We're working toward SOC 2 and ISO 27001 certification now. Until they're done, the controls above are the honest answer to the security questionnaire, and we're glad to walk your IT team through any of them.
Incident response
We have a documented incident response process with severity levels, a 1-hour triage target and breach notification obligations under the NZ Privacy Act 2020 built into our standard agreement.
06Questions
If your IT or procurement team has a security questionnaire, send it over. We'd rather answer it properly than have you guess. Email privacy@takeoffqs.com and it lands with our CTO.
For what happens after you sign — the implementation phases, how long it takes and what we need from you — see How we work.