Hacker Newsnew | past | comments | ask | show | jobs | submit | wcisco17's commentslogin

Fair callout — Bluebeam Max does touch estimation. That said, we've talked with 20+ subs and almost none know them know exists.

The reality is people that work in construction (Excluding field work), refers to AI as a scam and compares it to the crypto hype back in 18 .. compares it to crypto in 2018 — all hype, no landing.. seriously they do not like it.

I built this selfishly. Eight months ago I wished I had a programmatic interface to interact with drawings. So I built one.

last point: our customers aren't just doing takeoffs and they aren't just subs or gc's either — they're building tools in the construction tech space and estimation is one use case. The broader opportunity is making all that structured data accessible.

great q!!

Also I didn't see Claude there "ai" tool (a bit weird they are letting the model providers own the entire interface) count any fixtures, and if it did it was probably pulling it from the markup's table which is enabled via their api, which you can technically just slap an llm on top of it. But hey kudos to them - this space is not easy. (https://developers.bluebeam.com/s/studio?language=en_US)


Have you tried using it with Finnish construction documents? It should work for the detections that cover drawings.


Hey thanks!! For estimation we cover division 08 (doors and opening) you can use it for your estimating purposes with these two endpoints:

- Counting all the doors: https://www.getanchorgrid.com/developer/docs/endpoints/drawi... - Extracting schedules in architectural drawings: https://www.getanchorgrid.com/developer/docs/endpoints/drawi...

and use Claude or any other AI tool to wire up the UI

We're releasing toilets (division 10) later this week, then floors and pipes next.


Fair point and thanks for the tip. No AI here though.


Yep we're constantly improving we're currently above 0.87 for doors

we're thinking of adding a params for the ROC curve so that you can decide your own optimal thresholds depend on when false positive true positive rate is acceptable


Oh nice! I spend a good amount of time eyeballing drawings for overlooked details, so even finding most is a handy tool to me as my brain can skip the marked areas


Lovely. Are you in the construction space or are you a dev or both?


Construction, coding is a hobby from before I realized a desk wasn't for me. Sadily we are always under NDAs, so using a tool like this would require a lot of hoop jumping unless it definitely didn't cache or anything


Yeah OCR for technical is largely solved we're targeting the construction documents space For construction specs we have a few endpoints: - https://www.getanchorgrid.com/developer/docs/endpoints/specs... - https://www.getanchorgrid.com/developer/docs/endpoints/specs...

so you would want these documents translated lets say to German, mandarin, ect?


interesting yeah parsing DWG/DXF natively makes sense when the source file is clean and well-structured. The precision argument is valid in controlled environments.

The challenge we kept running into is that construction drawings in the wild aren’t always that clean. Unresolved xrefs, exploded dynamic blocks, version incompatibilities, SHX font substitutions — by the time a PDF hits a GC’s desk it’s often the only reliable artifact left. The CAD source may not even be available.

That’s why we see vision becomes the more pragmatic path — not because it’s more precise than structured CAD parsing, but because PDFs are the actual lingua franca of construction. Every firm, every trade, every discipline hands off PDFs. So we made a bet on meeting the document where it actually lives.

On consistency and reproducibility — that’s a real challenge with vision models. Our approach is to keep detection scope narrow and validate confidence scores on every output rather than trying to generalize broadly. Happy to go deeper on that if useful.


As a part of our product development, we had fought with PDF so much, even we have a generic PDF parser with triple pipeline (One for single column, another for multi column and third for complex table based layouts) yet we are not getting 100% accuracy, I would say that it's bit risky to bet on PDF. PDF often is the most complex format ever made and it was never made for data extraction. And You are right that vision models are the only way but hallucination is real.


good q — we don't train on customer drawings. Our detection models are trained on a curated dataset of architectural drawings we've sourced and labeled ourselves, focused on the most common fixture and element types across CSI divisions.

The generalization problem you're pointing at is real and it's the hardest part of this. Our approach is to keep the detection scope tight — rather than trying to generalize across every firm's conventions, we train on a small but high-quality set of fixtures and optimize for precision within that scope.

The result is high confidence outputs on the elements we support, rather than mediocre coverage across everything.

We're expanding the detection surface incrementally as we validate accuracy division by division!


How in the world is an answer to a question from the account posting TFA replying directly to said question getting killed?


Anyone building in or for construction tech — whether that's a startup building estimating or project management software, a construction company with an internal tech team solving this themselves, or a builder looking to automate their workflow. The common thread is drawings. Every one of those groups lives and dies by their ability to extract actionable data from a PDF that was never designed to be machine-readable. We're building the layer that makes that possible so they don't have to start from scratch.


Why does the workflow lie at the level of a real or virtual piece of paper and not in the metadata from the applications used to create that piece of paper? Seems like a CAD tool would allow you to identify each element of the drawing, assigning metadata as required.


Only a small set of construction stakeholders participate in the CAD ecosystem (e.g., architects, large GCs) while a broader set of stakeholders (subcontractors, trades, smaller GCs/CMs) do not receive BIM files and work with PDFs. CAD/BIM is a wonderful aspiration but for many the reality is PDFs.


Re. "CAD/BIM", technically speaking CAD doesn't imply BIM, and the industry's promotion of BIM is akin to AI promotion among software engineering teams - the benefits aren't clear upon detailed review of the advertised capabilities. The CAD part, on the other hand, is generally recognized as the essential tooling for the profession and I'm surprised to hear that it just is a "wonderful aspiration".


"The profession" actually is a wide variety of trades, not just architects and contractors. Electricians, plumbers etc. where CAD is not yet widely spread. Which hopefully will change in the near future, with open source BIM tool chains, boosted by generative/agentic AI.. Finally, a huge source of confusion and execution hiccups will be overcome.


Until then pdf rules!!!


Oh you sweet summer child. These draws are anywhere from 0 to 120 years old and might just be something pulled out of a floppy disk from 1970 to scanned in coffee ridden pieces of paper sitting in a desk folded a hundred times.

The world in which metadata is a common thing attached to any file doesn't exist, and probably never will, no matter how much you try to improve CAD work flow.


> Oh you sweet summer child

I know you're just repeating a phrase from a TV show but do you know how incredibly condescending this comes across to most people?


Thanks!!


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: