How I Would Build a Property Due Diligence System

Direct Answer

A property due diligence system is a coordination layer that identifies a property, pulls the records that describe it, extracts what each one says, and assembles the contradictions into one file a professional can sign. Enter the property, get what you are buying and what is wrong with it. Price and the decision to proceed stay with the lawyer and the engineer. This is a designed system, not a deployed build. It comes from the Shopify Your Industry lab and has never been sold to or validated with a customer.

Key Takeaways

• The buyer is already doing the integration work, badly, under time pressure. That work is the product.
• The product is the coordination layer: identification, retrieval, extraction, contradiction detection, professional review.
• The bottleneck is data access. Registries are rarely an API, and coverage is uneven.
• The verdict has to stay per-issue. An ownership defect and a permit deviation are not the same kind of problem.
• This is a model, like the freight booking system. The system I have actually built is the CRM follow-up loop.

What problem does this system actually own?

A buyer coordinates a lawyer, an engineer, a registry search, and a tax check, then assembles the answer themselves from four documents that do not reference each other.

Today the path usually runs like this:

1. The buyer finds a property and has weeks, sometimes days, to decide.
2. A lawyer is instructed to check title, and works from documents the seller provides.
3. An engineer inspects and checks the permit against what is physically there.
4. A registry extract is obtained, sometimes through a professional, sometimes not at all.
5. Each professional reports on their own piece, in their own format.
6. The buyer decides, holding four documents that never mention each other.

None of that is legal or engineering judgement. It is information moving between a registry, a seller, a lawyer, an engineer, and a tax office, each holding one piece of it. That is the coordination layer, and it is the product.

The existing workflow I would map first

Before any model call, I would sit with a lawyer and an engineer and walk one completed purchase and one that collapsed.

If that table is wrong, the system is wrong. I would rather spend a week on the table than a month on the wrong build.

How the system would run

Property identification

Everything downstream depends on identifying the right object: parcel identifier, building, horizontal property unit, and how those relate. Free-text addresses are not enough. The system resolves what it can, shows what it resolved it from, and stops rather than guessing when the identifiers disagree. A due diligence report on the wrong parcel is not a partial answer, it is a wrong one.

Registry and encumbrance retrieval

This is the step that decides whether the product exists. In Greece the records sit with the Hellenic Cadastre and, in areas not yet transitioned, with local mortgage registries. Access runs through professional e-services and paid extracts rather than an open API, coverage is uneven while the cadastral transition continues, and some retrieval is simply a person with credentials. I would build for retrieval that is partly manual and show the source and timestamp of every record, rather than pretending a registry behaves like a product API.

Document extraction

Deeds, permits, floor plans, prior transfers, tax statements. The system extracts parties, shares, areas, dates, charges, and permit references, and normalises them so the same field from four documents can be compared. Every extracted value keeps a pointer to the page it came from. Where a scan is poor or a handwritten annotation matters, the item goes to a human queue rather than into the report.

Risk assembly

Contradiction detection is the useful part: the area in the deed against the area in the permit, the owners in the title chain against the registry, the building as drawn against the building as described, a charge dated after the last check. Each finding is stated as what disagrees, what it might mean, and what would resolve it. Findings stay separate and typed. An unresolved ownership chain and an unpermitted balcony are different risks with different remedies, and I would not average them into a score.

Professional review

A lawyer signs the title position. An engineer signs the physical and permit position; in Greece that professional’s standing runs through the Technical Chamber. They can add, remove, or reverse anything the system found. The report the buyer receives is theirs, not the system’s, and the system’s contribution is that they started from an assembled file instead of an inbox.

What stays under human control?

• The legal opinion on title.
• The engineer’s assessment of the building and its permits.
• Any statement about what a defect costs to fix.
• Advice to proceed, renegotiate, or walk away.
• Anything that would be relied on in a transaction or a dispute.

The system prepares, a person signs. That is the same rule I follow in the CRM build, and Anthropic’s note on building effective agents makes the same argument: keep the workflow simple and inspectable before adding autonomy.

How I would measure the path

Baselines first, and only baselines, because nothing has been built:

• Days from instruction to a complete picture the buyer can act on.
• Hours the buyer personally spends reconciling documents.
• Findings discovered after the deposit rather than before it.
• Records that could not be retrieved at all, and why.
• Contradictions the professionals confirmed versus contradictions the system raised.

That last one is the accuracy measure that matters. Self-learning here means usage signals, professional corrections to extraction and flagging, and evaluation against confirmed findings — reviewed by a person. It does not mean the system deciding on its own that a discrepancy is immaterial.

When this is the wrong build

• The records cannot be reached. This is the bottleneck. Where retrieval is manual, restricted to credentialed professionals, or the area has not transitioned to the cadastre, the system is a report template and the cost stays with people.
• The professionals will not work from a prepared file. If the lawyer redoes everything from source regardless, the coordination layer saves the buyer’s time and nobody else’s, which changes who can be charged.
• The transaction is small or rare. A one-off buyer under no time pressure will use a lawyer and a phone. The design assumes urgency.
• Liability cannot be placed. Someone has to sign. If no professional will attach their name to a file assembled elsewhere, there is no product, only a research tool.
• The market is opaque by preference. Where sellers, agents, or intermediaries benefit from the buyer not assembling the picture, expect the supply of documents to be the obstacle, not the software.

How this connects to the engagement

This case is one of the models on Shopify Your Industry. The freight teardown has the same shape and a different wall: there the carriers, here the registry. The retrieval and cross-checking pattern is closest to the Deal Database, which gathers continuously and leaves the judgement to a person. The one system on this site that is actually running is the CRM follow-up loop.

If this coordination layer already exists in your company as four documents and a spreadsheet, the operating starting point is AI workflow automation. If you want it looked at honestly, describe the bottleneck. If you only want the next teardown, the newsletter is enough.

Summary

The abstraction is one line: enter the property, see what you are buying and what is wrong with it. The output is a file a lawyer and an engineer can sign, with a yes, a no, or a list of what to negotiate. Between those sits a boring coordination layer moving information between a registry, a seller, a lawyer, and an engineer. This is a model. It stays a model until someone with registry access and a signature describes where it actually breaks.