Building a 412,000-parcel site-intelligence engine

Scout started as a narrow question: is this address a good short-term rental?To answer it we needed parcels, comps, zoning, and live market data in one place. To answer it at scale we needed the same thing for hundreds of thousands of points — so we built an ingestion layer over county GIS servers and ended up with a national parcel database of about 412,000 owner records, plus substations, exclusion layers, and wholesale price data.

Then a second question arrived from a completely different business: where should a wind project go? And a third, from a waste-to-fuel company: which cement plant sits closest to enough feedstock? Three industries, three vocabularies, one underlying shape — score a point on a map by what surrounds it.

The temptation, and the mistake

The obvious move is to keep bolting features onto the tool: add wind, add cement plants, add feedstock. Do that for long enough and you get a swamp — an engine that “knows” about wind turbines and landfill tonnage, impossible to reuse and impossible to reason about. A general tool stops being general the moment one vertical’s data lives inside it.

So we split it. The engine became five primitives that know nothing about any industry: proximity (nearest facility of any kind), within(everything inside a radius, for basin aggregation), owners_near(counterparty lookup from the parcel DB), overlay (is this point inside a polygon — floodplain, protected land, restricted airspace), and a composite scorer where the caller supplies the components.

Recipes, not forks

Each vertical writes a thin recipe in its own codebase: it loads its own data, computes one weighted component per dimension, and asks the engine for a 0–100 grade. The energy recipe is wind×grid×land×price×exclusions. The real-estate recipe is comps×demand×regulation. The waste recipe is feedstock-basin×offtaker-fit×logistics. Same engine, different recipe — and no company’s data ever touches another’s.

The payoff is boring in the best way: adding a new vertical is a config exercise, not a rewrite, and the shared core stays small enough to trust. The most reusable thing we built wasn’t the parcel database. It was the decision about what to leave out of it.