Construction drawings aren't documents. They're data prisons.

We were deep in e-commerce — building an AI agent that cut through the noise and found exactly what you needed, when you needed it. Someone tried our demo, and saw something we didn't. Not a better shopping tool — a solution to a completely different problem. She ran a Division 10 estimating company, and the way our agent found signal in messy data looked a lot like what she needed to do with construction drawings every single day.

She reached out. One conversation later, we were in her office staring at a set of plans.

We were wrong about what we'd find.

We started with what we thought was the straightforward part — the schedules. If we could pull structured data from a set of drawings, we'd have a foundation to build on. We tried everything. AWS Textract, Google OCR, Mistral — you name it, we threw it at the problem. Everything broke. Not because the tools were bad, but because every single table was different. Different columns, different layouts, different conventions — and that's if the architect even bothered with a table. Sometimes it was just a list buried somewhere in the drawing set with no consistent format, no structure, nothing to grab onto.

Every dev's nightmare inconsistency at scale = Every plan is different.nobody tells you when you enter this space.

Elevations were a different kind of hard. We knew going into this it was a computer vision problem — no OCR tool was going to solve it. Our first attempt was text detection, trying to find keywords that looked like elevation markers and organize from there. It didn't work. Elevation markers don't follow a consistent naming convention across plans. We then tried converting the PDFs to SVG thinking we could extract the structure programmatically — that was worse. The conversion stripped out the very thing we needed, the spatial relationships between elements were gone.

What made it genuinely difficult is that elevations aren't just images on a page. They're views — a straight-on perspective of a specific wall or room, connected back to the floor plan through a numbering system. North, South, East, West. Each one a different shape, a different size, laid out differently on every sheet depending on the architect. And inside each elevation, fixtures that may or may not be tagged. Your job as an estimator is to connect all of those dots manually, room by room, page by page, across hundreds of sheets.

We couldn't find a single tool that understood any of that.

Months went by. Every time we hit a wall we did the same thing — we built something custom. There was no other option. What we observed along the way is that this industry is crowded with proprietary solutions gated behind paywalls, built in isolation, solving one problem for one type of user. Nobody was building infrastructure.

Every division in construction is its own world; a set of building blocks that snap together according to a unique set of rules.

So we built the Lego set an api that understands drawings.

The interface has been solved. Any team can ship a UI in a day — that's not the hard part anymore. The hard part is the pipeline underneath it. Getting an agent to consume structured drawing data and act on it the way an estimator would, the way a detailer would, the way a project manager would — in the right place, at the right moment, with the right context. That's where the future of construction is heading. Not another dashboard. An agent that actually understands what it's looking at.

We can't solve every problem in construction. There are too many divisions, too many trades, too many workflows. But we can make sure the next developer who walks into this space doesn't spend months building what should already exist.

That's what AnchorGrid is. Start Building with us.