Deepblocks PRO proved real estate rules could become software
Any architect can tell you what you can build on a parcel. Give them the address, a day and the zoning ordinance, and they will come back with an answer.
Nobody could tell you that for every parcel in a city at once.
Both questions matter to an investor. But the second one, which sites in the whole city can hold the project the market needs, measured against what is standing on them today, was impossible to answer in 2016. The information lived in a PDF, a map and someone's head, one parcel at a time. Ten years later, in most of the country, it still does.
Deepblocks PRO was our first attempt to answer the second question. Everything we have built since comes from what PRO proved and what it cost.
Explore DEV to prove if a site pencils: Drop a pin, model in 3D, and watch returns move.
What We Set Out to Build
When we started Deepblocks, no national dataset existed that would tell you, city by city, how much could be built on each property. Every county publishes parcel data in its own format. Every municipality writes its own zoning, in its own language, with its own logic.
I had trained as an architect at Columbia University and then in real estate development at the University of Miami. As an architect I could answer the capacity question for one site. As a developer I needed it for thousands of sites, filtered down to the few worth pursuing, and no tool did that.
So we built the dataset ourselves. Three years digitising zoning across 30 cities, then 250 more cities over the following three years as the automation improved. In the beginning, a single city took about three months to digitise. Today a city takes 24 to 48 hours.
PRO was the software on top of that data, and it did two jobs in one screen.
The first was canvassing. Say you wanted to build 50 or more units. You asked PRO to find every parcel in the city where the zoning allowed that and the lot had almost nothing on it today, and it returned those parcels on a map.
The second was feasibility. You selected one of those parcels and PRO showed a table of its zoning rules, then maximised the unit mix inside them: how many units fit, how much parking they required, how many floors they occupied after setbacks, and a 3D model of the result. From there you adjusted the unit types and sizes, the amenities, the loss factor, the expected rents, vacancies and operating expenses, and the return on cost updated as you went.
The point was not the exact building. It was to see, in a few minutes, what fit on a site in a general way, and whether the investment made sense before anyone spent money finding out.
What Explicit Programming Bought
Everything PRO showed came from a rule we had read in the ordinance and written into the software. If a district allowed 150 units per acre, PRO multiplied 150 by the acreage and applied that city's rounding rule. If the FAR was 7, the buildable area was 7 times the lot. The same parcel produced the same answer every time, and the user could open the rules table the answer came from.
Software has a name for that method: deterministic code. The same inputs always produce the same output.
For real estate, that precision was the product. A developer will not put money behind a unit count they cannot trace, and every count in PRO came from a rule we had read in the ordinance.
Precision also scaled. If I heard that a parcel had been rezoned, I could run PRO around it and see, within a half mile, which neighbouring sites already carried far more by-right capacity than the buildings sitting on them. That is what a city's worth of programmed rules could do when the question matched what we had built.
What the Data Cost
Everything had to exist before anyone could ask.
The county was the easy part, and the county took days. A county publishes the parcel attributes: what exists on each lot today. Every county publishes them in its own format, so adding one meant days of studying fields, translating definitions and rebuilding the data into ours.
Then came the jurisdictions inside the county, and each of those took weeks. A county holds dozens of cities, each with its own zoning. For every one, we layered the zoning map over the parcels to learn which district each lot sat in. Then we opened the ordinance and interpreted each district, more or less, into what could be built.
We limited ourselves to about ten parameters per district, because even that took forever. Including everything in a zoning ordinance would have taken years. So overlays were left out. Conditional uses were left out. State-wide programmes were left out. At first the data was really incomplete.
Then we discovered that zoning does not sit still. Cities amend their ordinances constantly, some of them quarterly, and every amendment meant going back. The data alone was a nightmare.
Even then, our customers loved it. Nobody had done this before. If we gave them by-right unit density and FAR for every parcel in a city, they were happy. That is how far behind the technology was.
There was a reason for all that translating. A deterministic question can only be asked once if every city speaks the same language. Ask "find every parcel that allows 50 or more units" and the software has to know how a unit count is calculated in Miami, in Dallas and in Los Angeles, and hold the result in the same field, in the same format. Without that, every question has to be rewritten for every city. Standardising hundreds of jurisdictions was the price of asking one question everywhere.
So we paid it. Then the questions changed.
Every Investor Finds Arbitrage Differently
The idea behind PRO was simple. Put the data in software and let customers search.
It worked. But only up to a point. Because every customer had a different definition of opportunity.
For one investor, the signal was proximity. For another, recent sales activity. For another, zoning capacity, or underbuilt parcels, or existing building condition, topography, parcel assembly, municipal momentum, or some combination of all of it.
Then geography made it harder. Local investors wanted deep context in a few neighbourhoods. Regional and national investors wanted to scan entire markets, sometimes across hundreds of municipalities.
And here the cost of deterministic software stopped being a data problem and became a product problem. A city was more of the same work, and we had learned to do it. A question we had not planned for was different. It meant a software engineer at Deepblocks opening the codebase, writing the filter and testing it, before the customer could ask it once.
To serve all of that in traditional software, we had two options.
The first was to write a custom algorithm for every customer. Their definition of opportunity, programmed by us, one at a time. That does not scale.
The second was to make PRO so flexible that customers could build their own searches, the way an analyst builds a query in GIS software. That hands the work back to the customer. It asks a developer to undergo a huge learning curve, and it gives up the thing PRO was for: an easy filter that finds the opportunities and hands back a 3D model and a pro forma at the end of the process.
Neither felt right.
A software product has one layout. One set of filters. One default workflow. One way it wants the user to think. For years, we asked customers to adapt to our interface.
The Tension PRO Left Behind
PRO proved two things at once.
Real estate rules could become software. A zoning ordinance could be read once, programmed once, and applied to every parcel in a city with the same precision each time. In 2016 that did not exist at national scale, and the industry ran without it.
And the method that gave us the precision was the method that set the limit. Precision came from programming the behaviour in advance. Reach required behaviour nobody had programmed yet. Every new jurisdiction and every new kind of question meant substantial additional work, and the questions arrived faster than we could write them.
We did not have an answer yet. We had a very good calculator and a growing list of questions it had not been built to hear.
Explore DEV to prove if a site pencils: Drop a pin, model in 3D, and watch returns move.
