When we started building SiteAI™, we had a choice to make.

We could build a flexible drafting tool that lets users define a parcel boundary, draw their own road network, and estimate the lot count and density according to their human inputs. That product would have been useful to generate 60-70% accurate yield estimates. It would have been faster than waiting on an engineering report.

We chose to build something else.

The user defines the constraints, lot size, home product, stormwater, exclusion areas, and is able to reference the municipal zoning regulations via ZoneAI™, then SiteAI produces the road network, the lot configuration, and the yield estimate. Five minutes per parcel - with the yield mathematically maximized. Dozens of parent parcels analyzed in an afternoon.

The difference between those two products is not a feature gap. It is a category difference. And it comes down to one question that gets buried in most software conversations: who is the user, and what is their actual job?

The acquisition team's job is to evaluate, not to draft

Land acquisition teams at production homebuilders are not engineers. They are not site designers. Their job is to look at a market and decide which parcels are worth pursuing, which to walk away from, and which to push into engineering for full feasibility.

Most acquisition teams have endless parcels to evaluate. The bottleneck is not access to a tool that can draw roads and drop in polygons to estimate a layout they think is viable. The bottleneck is the time it takes to get from “this parcel exists” to “I can write an offer, confidently”, based on the max number of lots this parcel will yield.

A drafting tool, no matter how customizable, does not solve that bottleneck. It speeds up site design for the parcels you have already chosen to design. It does not help you choose which parcels to design in the first place, and it certainly doesn’t maximize yield. Quite the opposite. It leaves yield estimates to user error and the human eye, not a mathematical optimization approach that finds how to squeeze the most lots, and ultimately, write the most compelling offer that wins the deal each time you’re up against the competition. 

The architectural difference

A drafting tool takes a layout and tells you what the yield is. The user draws the road network and arranges the lots. The software does the math behind the design they already produced.

A generation engine is architected differently and works the other way around. The user defines the constraints: lot size, product type, stormwater pond requirements, exclusion areas, and zoning rules ingested from ZoneAI. The engine produces the road network, the lot configuration, and the maximized yield. The user's job is to define what lots are most suitable for the market. The engine's job is to find the best outcome inside the user’s inputs and the site’s constraints. 

The first model is faster than waiting four weeks on your engineering firm. The second model is a different category of work entirely. It is the difference between a tool that helps you draw faster and one that helps you decide better and win more deals. 

When an acquisition manager pulls up a parcel in SiteAI, they do not have a layout to draw. They have a question: what could this site yield, given the zoning, the lot product they build, the wetlands, the floodplain, the stormwater pond sizes and locations, the community open space and amenity space size and locations, and where should the roads enter? That question has thousands of valid answers. The job of the engine is to produce the maximum yield, within constraints, in five minutes or less, from which decisions can be made. 

Five minutes per parcel is not a feature claim. It is the only number that matters at the volume an acquisition team operates at. A drafting tool that takes sixty minutes per layout, no matter how good the output, evaluates a handful of sites in a workday. A generation engine that takes five minutes per parcel can filter an entire market in an afternoon.

“SiteAI gives us an accurate yield estimate for initial underwriting in seconds. What used to be a $5,000 engineering report and weeks of waiting is now part of the first conversation.”
Paul Onufer, Managing Member, JPMB Investments

That difference compounds across the year, across the team, and across the markets a builder operates in. All of this compounds into growth. 

What an engine catches that a draftsman does not

Last year, Keith Caylor, a Land Acquisition Manager at Pahlisch Homes, was evaluating three parcels in central Oregon. The site looked clean. Drafted by hand, it would have supported a fifty-lot subdivision.

SiteAI flagged the Central Oregon Irrigation District canal running underneath the parcels. The actual buildable yield was forty.

“Site AI caught the irrigation canal under three parcels in Bend that would've cost us 10 lots, 20% of my initial estimate, plus the development costs to enclose and backfill it. For that community size, it would've likely turned into a loss for the company. We needed to know that reality upfront to evaluate the deal properly.” Keith Caylor, Land Acquisition Manager, Pahlisch Homes

That is what generation does that drafting cannot. SiteAI reads the parcel, the environmental data, the infrastructure data, and the regulatory data, and surfaces the constraints that an acquisition manager driving past the property would not see. A drafting tool gives you a ruler. SiteAI gives you the answer you can act on.

Read the full case study with Keith Caylor propheticsoftware.ai/case-studies/this-regional-homebuilder-avoided-a-costly-mistake-before-breaking-ground

The user we built for

SiteAI is not trying to replace civil engineers, and we tell every customer that on the first call. The output that SiteAI produces is a defensible yield estimate for an acquisition decision, not a stamped construction document. When the deal moves forward, engineering still happens. That is the right division of labor.

The acquisition manager sits one layer up from that work. They are an evaluator, not a designer. Their job is to look at a market full of parcels and decide which ones deserve engineering's attention at all, and in-turn, which parcels justify that $5,000 to $10,000 site plan from engineering. That decision has to happen fast, before the parcel goes to another buyer, and it has to be defensible in a five-minute conversation with the seller and a ten-minute conversation with your VP.

This is the user we built SiteAI for. The yield estimate has to be good enough to act on and get you under contract. The constraint flags have to be accurate enough to walk away from a deal if it doesn’t pencil. The road network has to be plausible enough to defend. None of those things require engineering precision. All of them require speed, credibility, and rapid iteration based on stakeholder feedback.

Building for the evaluator is a different design problem than building for the designer. We chose the evaluator because that is where the bottleneck in land acquisition actually lives.

What this looks like in practice

The customers using SiteAI well are not running it once on a high-priority site to refine the design. They are running it across every parcel that surfaces via Prophetic’s SearchAI™ filters. Forty parcels in a market on a Tuesday. Yield estimate, environmental diligence check, and multiple scenarios modeled. Most of those parcels are not worth pursuing. SiteAI educates users in five minutes each, and they move on.

The handful of parcels that survive SiteAI’s analysis and a user’s buy-box go to engineering for final feasibility. Those are the deals that close. The economics of land acquisition are about how many parcels you can credibly evaluate, not how many site plans you can manually draw.

This is why we built SiteAI to generate and maximize.

The category bet

Building a generation engine is harder than building a calculation tool. It requires reading parcel-level environmental and infrastructure data at scale. It requires translating zoning code into machine-readable constraints. It requires generating road networks that look like real subdivisions, not human-inputted guesses. It requires being accurate enough to make decisions on, at scale, for any size parcel. 

We made this bet because we believe that the next generation of land acquisition teams will not look like the last. The acquisition manager who walked the market with a notebook and a pen for thirty years is retiring. The one replacing them grew up expecting software to give them the answer, not just a marginally better tool than back-of-the-napkin math. 

The companies that recognize this and build for it will own the category. The ones that bolt real-time math onto a manual drafting workflow are solving a smaller problem than they think. They're letting acquisition teams draw faster. They're not letting them decide better, evaluate more sites, or win more deals.

We built SiteAI for the evaluators. What they do with five minutes per parcel is what shapes the next decade of land acquisition. The technology is in their hands now. The category will be defined by what they build with it.