A general contractor and a facilities manager have almost nothing in common. Different software, different budgets, different decade of buying habits. One is racing to win a bid; the other is trying to find a shutoff valve behind a wall that was poured in 2009.
But hand each of them the same set of drawings and watch what happens. They both do the same thing first. They read the page. That’s the tell. They figure out what is a wall and what is a dimension line, which symbols are doors and which are diffusers, how this sheet connects to the four sheets it references. Before either of them can do their actual job, they have to turn a flat 2D drawing into a model of a real three-dimensional place in their head.
That step is the hard part. Nobody talks about it because everyone in the industry does it without thinking. It’s also the part software has never been able to do.
The capability
We started with construction takeoff because it is where the pain is loudest and the money moves fastest. An estimator stares at a stack of drawings and counts things: linear feet of conduit, square footage of drywall, number of fixtures. Get it wrong and you either lose the bid or lose your margin. It’s repetitive. It takes days. And it’s exactly the kind of work that breaks people’s attention right when accuracy matters most.
So we built a model that reads the drawings the way the estimator does. It’s not OCR. It’s not symbol-matching against a fixed library. It’s not a pipeline of thirty narrow detectors stitched together. A model that takes a 2D construction drawing and recovers the spatial reality it encodes: what connects to what, what sits above what, what the page is actually describing about a physical building.
Here’s the thing we didn’t fully appreciate when we set out. The takeoff is the application. The spatial understanding is the capability. And the capability is bigger than the application by an enormous margin.
Once a model genuinely reads a drawing into space, counting fixtures for a bid is one of the easier things you can ask it to do. The same understanding answers a different question for a different person at a different stage of the building’s life. The drawing hasn’t changed. The reader has.
Where it repeats
Walk the building lifecycle and the pattern repeats at every stage.
In design review, an architect or engineer needs to know whether the mechanical layout clashes with the structural plan before it becomes a six-figure change order in the field. That is a spatial reasoning question: do these two systems occupy the same space, and where. Today that check is either done by eye or it requires a fully built 3D model, which most projects never produce in time.
In BIM generation, teams spend weeks rebuilding, by hand, the 3D model that the 2D drawings already imply. The information is all there on the page. The labor is in the translation. A model that reads drawings into space is doing most of that translation already, as a side effect of how it works.
In facilities and operations, the building is finished and the drawings go in a drawer. Years later someone needs to find the valve, trace the circuit, plan the renovation. The as-built drawings are the only record, and they’re unreadable to software, so the knowledge lives in the heads of whoever was there. A spatial model turns that drawer full of paper into something you can actually query.
None of these are adjacent products we would have to build from scratch and pray they work. They are the same model answering a different question. That is the difference between a feature and a platform, and it is the entire bet.
Platform, not tool
The word “platform” gets used loosely, so let me be precise about what makes this one.
A tool does one job. You wire it to a workflow, it produces an output, and if you want a second job you build a second tool. Most construction software is a pile of tools. That’s why firms run a dozen disconnected products with a person in the middle copying data between them.
A foundation model is different in kind. It learns the underlying structure of a domain once, and that learned structure transfers to tasks it was never explicitly built for. The same way a language model trained to predict text turned out to translate, summarize, and write code, a model trained to understand construction drawings turns out to do takeoff, clash detection, model generation, and retrieval. The transfer is the point. We’re not building products on top of the model. We’re building one model and exposing it through products.
This also explains why the data compounds the way it does. Every drawing the model reads, across every stage and every trade, makes it better at reading the next one. An estimation workflow and an operations workflow look like different businesses, but they feed the same understanding. The flywheel doesn’t respect the org chart of the construction industry. That’s a feature.
The market
I am going to resist the urge to put a single big number on this, because the honest answer is that the number depends entirely on where you draw the box, and the market-research firms that size this category disagree with each other by wide margins.
What I can say plainly is this. Scope the opportunity as “construction takeoff software” and it’s a real market and a good business. Scope it as “every task in the building lifecycle that starts by reading a drawing” and it’s a different order of magnitude, because design, engineering, construction, and operations are each large industries on their own, and the spatial-understanding step sits underneath all of them.
The reason most software companies never get to make that second claim is that their core capability doesn’t transfer. Ours does, or at least the early evidence says it does. That’s the claim the next eighteen months have to prove.
What’s next
The plan isn’t to sprint into four markets at once. That’s how you build four mediocre products and lose the focus that got you the first one.
The sequence is deliberate. We deepen the core in estimation until the spatial reading is good enough that the harder tasks come almost for free. Then we move outward to the stage that shares the most with what we already do well, which is design review and clash detection, because a model that already understands how systems sit in space is most of the way to telling you when they collide. From there, model generation and the operations layer, where the same understanding becomes a way to query a building long after it is built.
Each step is the same capability pointed at a new reader. Each one makes the model better at all the others. And each is a market we enter with a product that already works, rather than a promise we’re hoping to keep.
We could be wrong about how far the transfer goes. Maybe operations turns out to need something the estimation model never learns, and we have to build more than we think. That’s a real risk. I’d rather name it than paper over it.
But the bet isn’t complicated. The building industry runs on drawings. Every job starts by reading one. And nobody has built software that can actually do the reading. We can. The next year and a half tells us how much of the rest of the stack that one fact lets us take.
Victor Augusteo is the CTO of Boon AI.
