X-Builder — takeoff and estimating from construction plans

Context

Every construction bid starts with measuring the drawing, and that measuring is manual: an estimator counts rooms, doors and windows off a PDF and types quantities into a spreadsheet. It takes hours, it is the bottleneck before a bid can go out, and two estimators working from the same plan rarely produce the same numbers — which makes the bid hard to defend when the client asks how it was reached.

The constraint that shaped the product is what an estimator actually receives: not a CAD model with layers and metadata, but a flat PDF, often a scan, at a scale printed in the corner.

Decisions

Chose Detecting geometry with a vision model, then computing dimensions deterministically from it over asking a general multimodal model to read the plan and report quantities
A bid is a commercial commitment. A quantity that cannot be traced back to something visible on the drawing cannot be defended to the client who receives it — and cannot be debugged when it is wrong. Detection plus arithmetic can be shown on top of the plan and checked; a number produced by a model that read the whole page can only be trusted or not.
Chose Exporting to Excel and CSV over keeping quantities inside the platform behind our own pricing and bidding tools
Estimators price jobs in spreadsheets they have refined for years, with their own rates, margins and formulas. Replacing that is a much bigger product and a much harder sale than removing the hours of measurement in front of it. The product takes over the tedious half and hands the result to the tool the estimator already trusts.
Chose Taking a plain PDF as the only input over requiring a CAD file, or a conversion step before upload
The drawing an estimator is sent is a PDF, frequently a scan, and whatever the pipeline cannot read that way is work the customer has to do before getting value. Every preparation step is a place to give up and measure by hand instead.

What I did

I built the pipeline that reads the drawing. YOLO and OpenCV detect rooms and openings on the uploaded PDF; the drawing's scale is established and then applied as ordinary geometry to turn detections into real dimensions; quantities come out the other side and export to Excel or CSV.

The upload path is a drag-and-drop PDF and nothing else — no CAD export, no file conversion step, no plugin — because anything more is a reason for an estimator to go back to measuring by hand.

Outcome

An estimator drops in a plan and has quantities in minutes rather than hours, with the detected rooms and openings shown against the drawing so a number can be checked against the thing it came from. The output lands in Excel or CSV, where estimators already keep their pricing.

In hindsight

Detection was the interesting problem; scale was the one that decided whether the output was usable. A room detected perfectly but measured against the wrong scale produces a confident, wrong bid — worse than no answer, because it looks like an answer. I spent proportionally more effort on the model than on establishing and verifying scale, and would invert that next time: quantities are only ever as trustworthy as the units underneath them.