The GitHub for Construction: A Property Ledger From Land to Keys

Construction and property development don’t fail because people don’t work hard.

They fail because information breaks and money breaks.

• The “latest drawings” are in someone’s email.
• Variations get agreed verbally and disputed later.
• Quotes come back as PDFs you can’t compare.
• Council / consent documents are scattered.
• Payments are “in progress” until a contractor collapses and the supply chain finds out the hard way.

QSME’s long-term goal is simple:

Build a versioned, auditable “property ledger” for every project — from land acquisition to handover and maintenance — so the truth is easy to find, and trust is earned from real records.

If you’re familiar with software, there’s a useful analogy: some teams use tools like GitHub to track changes and keep one shared source of truth.

In construction, the idea is the same — a clear history of what changed, when, and why — without needing to be technical.

The real source of truth in construction is not “the schedule” — it’s the drawings

In practice, the most valuable artifact is the design package:

• Architectural drawings
• Structural drawings
• Services (MEP) drawings
• Specifications
• Geotech / site reports
• Revisions, markups, and clarifications

Everything else depends on these.

When the drawing set changes, scope changes.

When scope changes, SoQ/BoQ changes.

When SoQ/BoQ changes, quotes change.

When quotes change, budgets and timelines change.

So if your drawings are not:

• shared
• versioned
• annotated
• linked to the scope and the contract

…you don’t really have control. You have hope.

Why version history matters (without the tech talk)

The key is not “a folder with files.”

The key is being able to answer, instantly:

• Which drawing revision was used for tender?
• When did the kitchen layout change?
• Who approved it?
• Which SoQ line items changed?
• Which quote was based on which revision?
• What variation was created as a result?
• When did it get priced, accepted, and paid?

That is what versioning gives you: traceability.

From concept to construction: one record across the full lifecycle

Most platforms focus on one phase.

QSME’s vision is a continuous record across the entire property lifecycle:

1) Concept + feasibility

• Feasibility spreadsheets, assumptions, constraints
• Early budget ranges (with provenance)
• Risk register
• Initial scope notes and priorities

2) Land acquisition

• Title records and key title documents
• Sale & purchase agreement (and variations)
• Due diligence artifacts
• Conditions, deadlines, and signed confirmations

3) Council / consent / compliance preparation

• Applications, RFIs, responses
• Conditions of consent
• Engineer producer statements, compliance documents
• Inspections and signoffs

4) Design development (where things get expensive)

• Drawing versions and issue sets (IFC, tender set, construction issue)
• Specs, schedules, materials selections
• Change log: what changed and why

5) Procurement: RFIs → RFPs/RFQs → quotes/tenders

• Tender packages linked to drawing set versions
• Responses standardized for comparison (apples-to-apples)
• Clarification Q&A captured and versioned
• Award decision recorded with rationale

6) Construction execution

• Milestones, progress claims, QA checklists
• Variations (requested → priced → approved → paid)
• Site instructions, photos, inspection outcomes
• Delivery evidence for “done means done”

7) Handover + defects + maintenance (the “after” that matters)

• Warranties, manuals, as-builts
• Defects list and close-out evidence
• Maintenance work orders and payment records

The promise is not “more admin.”

The promise is less ambiguity.

The hard problem: money breaks projects

Even when the work is good, payments can fail.

And when payments fail, relationships break fast.

One of the most damaging scenarios is when a head contractor becomes insolvent:

• subcontractors can end up unpaid,
• retentions become complicated,
• and “who is owed what” becomes a legal fight instead of a project workflow.

This isn’t theoretical — it happens repeatedly.

For example, RNZ covered the Ebert Construction failure and the resulting shortfall in retention funds owed to subcontractors.

Sources:

• RNZ: "Ebert subcontractors to be paid at least 75% of money they're owed" (https://www.rnz.co.nz/news/business/375804/ebert-subcontractors-to-be-paid-at-least-75-percent-of-money-they-re-owed)

The lesson is consistent: trusting that cashflow will “work itself out” is not a payment strategy.

The distinguishing feature: escrow that protects both sides (without drama)

Escrow is one of the cleanest ways to reduce payment risk without turning every conversation into a dispute:

• You don’t ship funds blindly.
• You don’t “trust the other party will do the right thing.”
• You define what “done” means and then release when it’s proven.

The escrow rule (as you described it)

In the QSME escrow model:

• The issuer (payer) can only release funds.
• The receiver (payee) can only cancel (i.e., refuse release / stop the flow) — they cannot unilaterally take funds.

The purpose is simple: funds are held safely until the agreed work is done, while preserving issuer control over release.

This solves a very real problem:

• Subcontractors need confidence the money is real and reserved.
• Owners/developers need confidence they won’t pay for work that isn’t done or isn’t compliant.

Where escrow runs (bank rails today, hybrid later)

QSME’s escrow is not “one payment method.” It’s a controlled workflow that can run on different rails depending on the project and country:

• Today (New Zealand): escrow can run through New Zealand banks using standard bank transfers and project-specific holding arrangements.
• Hybrid (where supported): where a country has open banking (or bank APIs), releases and confirmations can be automated more tightly while still using bank rails.
• Alternative rails (by choice, not forced): some projects may prefer escrow using an agreed stable token or a private network/token model (for example, where parties are already using regulated digital assets or security-token structures).

The key point is that the platform records the agreement, the milestone, the evidence, and the release event — the rails can vary.

How it maps to real construction workflows

QSME’s target workflow is milestone-based:

• Scope is structured (SoQ/BoQ)
• Milestones are defined
• Funds are placed into escrow per milestone (or per work package)
• Evidence is attached (inspection signoff, photos, approvals, delivery docs)
• Release happens when the milestone definition is satisfied

Because releases are linked to structured scope + evidence, disputes become easier to resolve:

• “Which line item?”
• “Which drawing revision?”
• “Which approval?”
• “Which milestone definition?”

That clarity is what reduces conflict.

On-chain records: not “crypto hype,” but tamper-resistant audit trails

When we say “on-chain,” the goal is not to dump all documents publicly.

The goal is:

• prove something happened, at a time,
• prove which version was used,
• prove who approved,
• and ensure it cannot be quietly rewritten after a dispute starts.

In practice, that often means recording hashes and key events (timestamps, signoffs, version IDs), while keeping sensitive documents encrypted and access-controlled.

This matters for:

• title and ownership proofs
• contractual approvals
• consent / compliance records
• payment and escrow release proofs
• maintenance orders that were requested and paid

It’s “verifiable truth,” not “public data.”

A living timeline for every property and project

Imagine opening a property and seeing the full history:

• the original feasibility assumptions
• land purchase + title documents
• every council document and condition
• every drawing issue set and change
• every SoQ version and tender package
• every quote, award, and contract
• every milestone, release, and variation
• every maintenance request and payout

Not as scattered files, but as a connected graph:

• each artifact linked to its upstream inputs,
• each decision linked to evidence,
• each payment linked to scope and outcome.

That’s how you turn construction from “memory + emails” into an actual system.

AI is optional — and only useful when it is anchored to real documents

AI is powerful in construction only when it’s used to organize and extract, not to invent.

In QSME, AI is most useful for:

• extracting scope from drawing sets and specs
• generating a structured SoQ/BoQ draft from real documents
• summarizing council conditions and compliance requirements
• highlighting inconsistencies (e.g., spec vs drawing mismatch)
• comparing tenders in a structured way (not just “which is cheapest”)

And critically: every output should keep provenance:

• which source files
• which versions
• which extraction method/model
• when it ran

That’s how you keep AI accountable and useful.

Why this matters: fewer disputes, fewer bankruptcies, more certainty

If you reduce the two biggest failure modes — information ambiguity and payment uncertainty — you reduce a huge portion of the industry’s pain:

• fewer “that wasn’t included”
• fewer variations discovered late
• fewer disputes over scope
• less time chasing documents and approvals
• fewer supply-chain failures caused by hidden cashflow risk

It’s not glamorous, but it’s foundational.

Construction doesn’t need more apps.

It needs a system that makes truth easy to find.

What we’re building toward

QSME’s north star is a property workspace where each project has:

• versioned documents (drawings, contracts, compliance)
• structured scope (SoQ/BoQ) connected to the drawings
• procurement workflows (RFP/RFQ, tenders, quotes) connected to scope
• escrow-based payments connected to milestones and evidence
• tamper-resistant records of key approvals and releases
• optional AI for extraction + analysis (always auditable)

That is what this “construction ledger” idea means in practice.

If you’re building, investing, or planning a development and you want fewer surprises, that’s the direction.