The Takeoff AI
AI for Industrial Estimation
We are building The Takeoff AI, which reads industrial construction drawings and produces the quantities an estimator needs to price a job. Piping and structural steel, mostly for contractors on the US Gulf Coast.
Before we wrote any of the model, our engineers spent months doing takeoffs by hand. Mostly computer science majors, none of whom had seen a piping and instrumentation diagram before. Thousands of drawings, each one checked by estimators with decades in the industry.
It was slow and expensive and it is the only reason the product works.
Here is what it taught us. We had assumed the job was counting. A drawing has symbols on it, so you build something that finds and counts the symbols and hands over a total. That is what we set out to build.
Estimators do not work that way. They pull the expensive items straight off the schedules, the valves and the equipment, then factor the thousands of small things, the fittings and welds and bolts, from line length and specification using ratios they have carried for years. Nobody counts every elbow. Counting every elbow is the slow way to do it, and we were about to automate it faithfully.
So we reordered everything. Structured tables first, then scaled drawings with parametric rules on top, and symbol detection only when nothing better exists.
One other decision. We do not publish an accuracy percentage. Everyone in this category leads with one and none of them can be verified by the person being sold to. Every number we produce can be clicked instead, and it shows the drawing and the rule behind it, so a chief estimator can audit it and decide for themselves.
Happy to answer anything about the domain, it is a strange one.
3 Comments
The months of manual takeoffs seem like the strongest part of the story. You didn't just train the model on drawings; you first learned how experienced estimators actually interpret them.
Hey, congrats on theTakeoff.ai — automating material takeoffs from P&IDs and isometrics is a real pain point that's been underserved forever.
I actually ran your product through Zarek (an AI launch co-pilot I built — [zarek.tech](https://zarek.tech/)) to see what a structured launch roadmap looks like for it. Here's what came out:
What Zarek mapped out for theTakeoff.ai:
Positioning copy — "The only takeoff tool with a native ASME code engine. Built for P&IDs, isometrics, and legacy scans — not architectural blueprints."
Demo content — A short screen recording showing: upload a P&ID → Zarek extracts line numbers, identifies components, applies ASME codes → exports a bid-ready estimate. Zero manual input.
Targeted directory listings — ENR, Autodesk Construction Community, niche EPC forums, ProductHunt (under "Developer Tools / Construction Tech")
Outreach copy for IH/Reddit/LinkedIn — Each channel gets its own voice. The LinkedIn version leads with "weeks → hours." The Reddit version leads with a war story about a bad estimate.
SEO seed post — "How EPC contractors are losing bids on bad takeoffs (and what's changing)" — drives long-tail traffic from estimators Googling the problem.
Takes maybe an hour to go from zero to a full draft plan + copy ready to review.
If you want to try it for your own launch, drop me a message: wangc2016217@gmail.com or just hit [zarek.tech](https://zarek.tech/).
The elbow line is the whole post. You set out to automate the task as an outsider would describe it, and months of watching taught you to automate how the work actually flows, schedules first, ratios for the long tail, counting only as the fallback. Most AI products never make that turn. They ship the faithful automation of the wrong method and wonder why practitioners shrug.
The no-accuracy-percentage decision is the braver one though, and I think it generalizes. Every category with AI in it right now leads with an unverifiable number, and buyers have learned to discount them all to zero. "Click any output and see the drawing and the rule behind it" replaces a claim with an audit. You're selling the chief estimator confidence in their own judgment instead of asking for faith in yours. Building in a different space (business systems) and we landed somewhere similar: don't claim reliability, show the reasoning before anything applies. The trust transfers better.
Question from the domain outsider: what happens when a parametric rule is wrong for a specific job - new spec, odd client standard? Is there a path for the estimator's correction to flow back into the rules, or does each correction live and die on that one takeoff?