This post in 30-seconds or less; what you need to know:

• An in-house land intelligence platform is not a one-time software project. It is a permanent data operation.
• Building moves five risks onto your organization: delivery, decision accuracy, continuity, competitive position, and a commitment that is hard to reverse.
• Most of the cost and risk sits in the data: sourcing, reconciling and re-reading parcel and zoning records, every year, in every market.

Every few months a land acquisition team reaches the same conclusion. Parcel data is public record. Zoning ordinances are published. We have AI, a data team, a cloud contract, and a mandate to modernize. Why license this when we could build it?

It is a fair question, and the teams asking it are usually the most sophisticated buyers in the market. They are not looking for a reason to say no. They are trying to work out what they would actually be buying.

So here is the honest answer, which may not be the one you expect from a vendor: you should build the things only you can build. The problem is that most in-house land intelligence projects are not scoped as what they are. They get scoped as an application. They are actually a permanent data operation.

That difference matters most to the people who sign off on it. A build decision is not only a cost decision. It moves risk onto your balance sheet: delivery risk, decision risk, continuity risk, competitive risk, and the risk of a commitment that is hard to undo. When you license, a vendor carries much of that risk, and managing it is the vendor's whole business. When you build, your organization carries all of it, usually without a line in the business case that says so. 

The test we would apply to ourselves

We published a buyer's guide (link to guide) for this category. It is a set of questions to ask any vendor, covering data foundation, zoning, AI depth, enterprise readiness, partnership, and customer validation, each with a note on what a strong answer sounds like.

If you build in-house, you do not get to skip those questions. You become the vendor. The same standard applies, you answer it yourself, and you answer it again every year. And every question you cannot answer well is a risk your organization now owns.

Run your own build through the guide before you commit. 

Six questions do most of the work.

1. Where does your parcel and ownership data come from, and is it one source or several?

An internal build licenses the same commercial data any platform licenses, without the volume of a vendor spreading that cost across a customer base. Single-source data is the cheaper path, and it is the reason coverage and accuracy vary market to market. Prophetic runs dual-source national parcel data reconciled record by record, at 99%+ population coverage, because no single vendor is best everywhere.

The risk for leadership: gaps in coverage are invisible until a deal lands in one. Your team will not know which markets are thin until they are already relying on them.

Ask your internal team which sources they plan to license, what the annual line item is, and who reconciles them when two sources disagree about the same parcel.

2. How will you read every zoning code, and keep reading it?

This is where in-house builds stall, and it is worth being specific about why.

There are more than 23,000 municipalities in the United States, across all 50 states. Each publishes its own ordinance, running 500 to 1,000 pages. When we counted the distinct ways American zoning codes describe a single-family home, the answer was 9,378.

Reading them once is a project. The codes change, which makes reading them an obligation with no end date. And reading is not the hard part. Structuring the output into common fields, so a team can filter an entire market on permitted use, density, minimum lot area, setbacks and height, is what turns zoning from something you look up into something you search.

The risk for leadership: a zoning code that changed last quarter and was never re-ingested still looks current in your system. Stale data does not announce itself. It shows up as a bad assumption in an underwriting model.

Ask who owns re-ingestion in year three, after the person who built the pipeline has moved to another team.

“Site AI caught the irrigation canal under three parcels in Bend that would’ve cost us 10 lots, 20% of my initial estimate… it would’ve likely turned into a loss for the company.” Keith Caylor, Land Acquisition Manager, Pahlisch Homes

3. Is the answer cited back to its source?

Any build can produce a number. The question is whether a land director will put that number in front of a committee.

Prophetic's platform cites every interpreted value to the page and section of the ordinance it came from, so a user can verify it in seconds rather than taking the system's word for it. An internal build that returns an uncited answer tends to get used twice and then quietly abandoned, because nobody will stake a deal on a number they cannot check. Adoption failure is the most common way an in-house build dies, and it rarely appears in the business case.

The risk for leadership runs both ways. If the team does not trust the tool, you paid for something nobody uses. If they do trust it and it is wrong, an acquisition gets approved on a number no one can trace. Ask who is accountable when that happens.

4. Was it built natively on AI, or will AI sit on top of a database?

This is the wedge question in our guide, and it cuts the same way internally. Most in-house projects start as a warehouse of licensed data with a map on the front and, increasingly, a chat window. That is a reference tool. It tells you what you can build on a parcel you are already looking at.

Working an entire market requires the inverse: tell me where, across a whole market, every parcel that fits what I intend to build actually is. Prophetic's SearchAI™ does that across 120+ development types. Prophetic's platform generates a yield estimate in seconds, against the alternative of a $3,000 to $10,000 engineering report and a two to three week wait, which is what makes it affordable to screen sites you would never have paid to study.

To be clear about the limit: a generated yield estimate does not carry a stamp and does not go to the city. It gets you to the point where paying for real engineering is worth doing, on far more sites than you could previously afford to look at.

The risk for leadership: AI capability is moving faster than any internal roadmap. A build scoped today against today's models is a version behind by the time it ships, and someone has to own keeping it current.

The most common version of this idea right now is simpler: point a general AI model at the ordinances and ask it questions. It will answer, and it will sound confident. But it will not tell you when it misread a table, missed an overlay or relied on a superseded amendment, and its answers do not come back as structured fields you can filter a market on. That is decision risk at its sharpest: a fluent answer that nobody can verify.

5. Who secures it, and who keeps it running at scale?

Single sign-on, role-based access, audit logs and an independent security review are table stakes for any system holding deal data across divisions. Prophetic is SOC 2 Type I. An internal build carries that scope too, and it is rarely in the original estimate.

The controls are the visible part. Underneath them is the work of deploying safely: separate environments, every change reviewed and tested before it reaches users, and someone watching the system after hours. Then there is scale. The platform has to stay fast when every division runs market-wide searches on the same morning, and keep up as parcel and zoning records grow every year. None of this shows up in a demo. All of it is a standing cost, and for a vendor it is the daily job.

The risk for leadership: this system will hold your land strategy, your pipeline and your pricing. An internal tool built fast to prove value is the one most likely to skip the controls that protect it, and the first to slow down once the whole company depends on it.

6. Who has already done this, and is it live across the whole organization?

This is the question with no internal answer. When you buy, you can ask for named customers live across every division rather than in a single pilot, and you can ask what daily use looks like. Ours runs at 95.3% daily active use across enterprise customers over a twelve-month period.

When you build, you are the pilot. There is no reference call, and no one else's lessons to borrow.

The risk you take on when you build

The six questions test whether a build can work. Leadership has a second question to answer: if it does not work, or works only partly, what does that cost the business? Five risks move onto your side of the table the moment you choose to build.

Delivery risk. Internal data projects rarely fail loudly. They slip a quarter, then another, while the scope grows to match what users actually need. The team keeps paying for the old tools the whole time. By the time leadership asks whether to stop, the sunk cost makes stopping feel harder than continuing. Ask what the plan is if the build is half done at month twelve, and who decides to stop.

Decision risk. Land intelligence feeds capital decisions. A missed overlay district, an outdated density limit or a misread setback does not stay inside the tool. It shows up as an acquisition that cannot be built as planned, a redesign, or a deal that should never have reached committee. When the tool is licensed, accuracy is the vendor's product and the vendor's problem. When it is built, it is yours, and there is rarely anyone whose full-time job is to catch the error before it reaches a deal.

Continuity risk. Most internal builds depend on two or three people who understand how the pipelines work. When they change teams or leave, the knowledge leaves with them. The system keeps running, but nobody is updating it, and the data quietly ages. This is the most common way a successful build becomes a liability in year three.

Competitive risk. Every month spent building is a month your competitors may spend using. They are working whole markets, reaching owners first and filling pipelines while your team is still in development. That ground is not recovered when the build ships, because the relationships and the land are already spoken for. Meanwhile the engineers on this project are not working on the things that make your company different.

Reversibility risk. A license can be ended at the close of its term. A build is much harder to walk away from. By year two there is a staffed team, a budget line, sunk cost and people whose roles depend on the project continuing. Even when the evidence says to stop, organizations rarely do. A decision you can reverse carries less risk than one you cannot, and that difference deserves weight.

Buying is not risk-free either. Ask any vendor, us included, who owns your data, how you get it out, and what happens if the relationship ends.

It is also worth asking which vendors the complaints are about. At an event we attended recently, we heard plenty of frustration with software suppliers: long waits for features, slow deployments, products sunset with little notice. Those complaints are real. They also describe vendors built that are not AI-native. 

The case for building often rests on a fair point. With AI, your team can move faster than it used to. So can the best vendors. A platform built natively on AI improves continuously. Products don’t get sunset. They get rebuilt better, sometimes several times a year. If you are counting the speed an AI-first build would give you, compare it against vendors working the same way, not against the ones still stuck in the old one.

None of these risks means a build is wrong. They mean a build decision should be made with them priced in, the same way any other capital decision would be.

What the business case usually leaves out

Four costs go missing from almost every internal build estimate.

The current stack does not switch off. Your team keeps paying for parcel data, mapping, skip tracing and engineering reports for the full duration of the build. That is double-carry, and on an eighteen month project it is often larger than the first year of a license.

You may already be paying for the data. Many teams license parcel or ownership data today, sometimes inside more than one tool. A build keeps that line item and usually grows it, because one company pays the full price a vendor spreads across every customer. Licensing a platform can be the chance to retire that spend instead of adding to it.

The data needs people, permanently. Someone has to source it, reconcile it, re-ingest zoning changes and answer the call when a number looks wrong. At most builders that becomes a full-time job, and often more than one. Those salaries belong in the estimate for every year the system runs, not only the years it is being built.

Risk has a cost, even when it is not on the spreadsheet. A business case that prices the build at the happy-path estimate assumes it ships on time, stays accurate and keeps its team. Ask for the version where it runs twelve months late, or where one acquisition is underwritten on a zoning value that turned out to be wrong. That number belongs in the decision too.

To put the full picture in front of leadership, ask for the build estimate in this form:

Cost to launch = (build team size × fully loaded cost per person × years to build) + (data licensing per year × years to build) + (current tools per year × years to build)

Annual cost after launch = maintenance team + data licensing + security and compliance

Risk check: run both again with the build taking 50% longer, then compare the total against a license over the same period.

Most internal estimates include only the first term. The rest is where the business case changes.

What kind of business are you?

Software teams that are good at this got good through repetition. They ship, support, secure and rebuild the same product for many customers, every week, and each customer’s problem teaches them something.

A homebuilder can build that muscle. It takes the scale to run what amounts to a software company inside the company, with its own engineers, data team, security function, support desk and roadmap, funded for as long as the system runs. A few organizations have that scale. Most do not, and should not want to.

Without it, the build becomes a side job. Talented people work on it alongside their real work, and moonlighting rarely produces anyone’s best work. Your business is finding land and building homes. That is where your reps should go.

What is genuinely worth building

Your buy box. Your underwriting model. Your land position and the history behind it. The connection between land intelligence and the rest of your business.

None of that comes out of a box, and all of it compounds. Prophetic supports enterprise API access for corporate data lakes, so internal teams can build on top of verified parcel and zoning intelligence rather than spend years recreating it underneath. That puts your engineering investment where it creates an advantage, and leaves the data operation, and its risk, with a team whose only job is to run it.

Build up the stack, not down.

The head start is the real number

The Gove Group went from working 100 to 200 parcels per year to 3,000 in year one. Other teams have gone from 50 parcels per month to 1,000+ per month with the same team.

That capacity arrives in the first quarter of a deployment, or in year two or three of a build, assuming the build finishes. Meanwhile the advantage compounds for whoever has it.

"If your competitors adopt Prophetic first, it's already too late. The land contacts they'll make through Prophetic are contacts you'll never get." - 

Alexx Monastiero, Land Development and Acquisitions Project Manager, The Gove Group

Working the whole market is coming to your market either way. The question is whether your team spends the next two years building the capability or using it, and whether your organization wants to carry the risk of getting there.

Run the test

Take the six questions above to whoever is proposing the internal build, and ask for an answer with a date attached. Not a roadmap. A date. Then ask the five risk questions alongside them: what happens if it is late, who is accountable if it is wrong, who maintains it when the builders move on, what the market looks like by the time it ships, and how you would change course if it does not work.

If the answers come back strong, build it. If they come back as estimates, you have learned something useful about the scope, and the risk, before spending anything.

There is also a lower-risk way to decide. Run Prophetic in one market for a defined period while your internal team scopes the build. At the end, you are comparing a working result against an estimate, not one estimate against another. If the build still makes sense, you have lost nothing. If it does not, you have avoided a commitment that would have been hard to undo.

Or see what you'd be missing. Bring us a market you know cold, and we will show you what is there.

‍