harryliu.space / projects / terralink
Project · Case Study

TerraLink

A year of product and business-model discovery — reshaping a cross-border procurement problem from marketplace into concierge.

2024–2025 Personal · business-model discovery 12 documented pivots · 4 personas · AI extraction + compliance RAG
§ 01 — Context

Builders who could save 40% — but won't, because of trust.

Australian residential builders overpay for construction materials. Buying directly from overseas suppliers offers 30-50% savings on commodity items like windows, doors, and glazing — but the combined friction of language barriers, compliance uncertainty, payment risk, freight visibility, and supplier credibility makes direct sourcing inaccessible to most small builders. The ones who do it have internal procurement staff. The ones who can't afford that staff pay retail.

The product hypothesis was straightforward: bundle the procurement expertise into a platform. Use AI where it makes the builder's life easier — extracting specs from construction drawings. Use human expertise where trust matters — supplier curation. Use escrow where money matters. Lower the cost of competence so that small builders can access the savings without hiring a procurement team.

I built TerraLink to test that hypothesis. Twelve documented product versions later, the answer was yes — but in a sharper, narrower form than the original plan proposed.

§ 02 — The pivot that mattered

Marketplace died in user research. Concierge lived.

The original design was a marketplace. Builders post requirements; verified suppliers compete on quotes; the platform takes a percentage. Clean model, well-understood unit economics, proven pattern in other commerce verticals.

It died in user research. Builders don't want a marketplace — they want a procurement concierge. Someone who owns the outcome end-to-end, not just the introduction. The marketplace model put the coordination burden back on the builder, which is exactly the burden they'd pay to have removed. "I still have to manage five suppliers, translate five quotes, verify five compliance claims, chase five shipments" is not a product — it's the job they were trying to escape.

Builders care about immediate savings, not a future procurement OS. The service-led concierge pivot was the single most important product decision I made on TerraLink.

The pivot to service-led concierge cascaded through everything:

  • Narrower category. Windows, doors, glazing — not all materials. Depth over breadth, and depth requires focus.
  • Different business model. Margin on managed procurement (buy-low-sell-fair), not a percentage of supplier invoice.
  • Different product surface. Fewer public screens, more internal workflow tooling. The platform became half buyer-facing and half operations-facing.
  • Different brand posture. Trust-and-competence, not marketplace-neutrality.

The cost of the pivot was three months of marketplace-era code I had to leave behind. The value was a product someone could actually buy. The PM principle at work — five user interviews beat any amount of internal conviction. Every pivot on this project came from interviews, not intuition.

§ 03 — How it works

Four personas. One underlying state. Twelve stages.

The platform coordinates four personas — builders, suppliers, admins, and a compliance layer — through a shared workflow. Each persona sees a different UI, but they all read and write to the same underlying state for any given project.

01
Quote request — web form, optional drawing upload, no login required
Builder
02
AI extraction — PDF text + OCR on schedules + vision models on elevations and callouts
System
03
Human verification — admin confirms extracted specs before quoting
Admin
04
Compliance RAG — specs validated against AU Standards, surfaced inline with pricing
System
05
Supplier matching — admin selects best-fit verified suppliers; not open bidding
Admin
06
Builder portal — magic-link to compare quotes, no password friction
Builder
07
Quote acceptance — structured, line-item accept with change-order tracking
Builder
08
Digital contract — e-signed supply agreement with escrow terms baked in
Builder / Supplier
09
Escrow — funds held until milestone verification; the trust pillar
System
10
Production tracking — supplier updates flow into the builder portal as narrative, not jargon
Supplier
11
Shipping translation — customs status turned into builder-legible language
System
12
Delivery + feedback — photo confirmation triggers escrow; review feeds supplier ranking
All

A few technical choices worth naming:

  • AI extraction pipeline. Primary PDF text extraction handles schedules and text-heavy specs. OCR handles scanned tables. Vision models handle elevation drawings and callouts that text extraction misses. A human verification step sits after extraction — the AI drafts, the admin confirms. This was a deliberate choice: the cost of a mis-extracted window specification is a wrong supplier quote, which is worse than a slower process.
  • Compliance as UX, not a disclaimer. The RAG layer checks quotes against Australian Standards (AS2047 for windows, AS1288 for glass) and surfaces compliance confidence next to pricing, not buried in a PDF. The goal: make "is this compliant?" a present-tense question answered in the UI, not a future-tense audit after purchase.
  • Magic-link onboarding. Every friction-reducing choice came from conversion data on early versions. Registration-first killed first-quote conversion; magic links for the builder portal brought it back.

Stack, briefly: Next.js + TypeScript frontend, NestJS + PostgreSQL backend, vector store for the compliance corpus, vision models for the extraction layer. The engineering was AI-assisted — I'm not a full-stack engineer by speciality, and I wouldn't have shipped this solo three years ago. What I brought was the persona design, the pivot discipline, and the product decisions about which rules mattered most.

§ 04 — Outcome

A validated business model, a working flow, and three months of code killed.

12
Evidence-led pivots, ending in a sellable business model

The real outcome isn't the build. It's the validated value proposition at the end of twelve pivots — service-led concierge procurement, AI extraction where it compounds, human expertise where trust lives, escrow where money matters. Builder interviews confirmed both the price pain and the trust barriers; the pivot from marketplace to concierge matched what they'd actually pay for. The working end-to-end flow is evidence the model holds together — not the headline outcome.

The pilot is now live with two local builders. Willingness-to-pay lands specifically on the AI extraction layer — the bit that turns hours of manual construction takeoffs into minutes — and the pilots are converting per-transaction through a consulting engagement. Concrete enough to keep building on; narrow enough to stay honest about scope.

What travels out of this project: a sharper instinct for when to kill code, a model for persona-specific UIs on shared state, and the muscle for letting five user interviews overrule three months of conviction.

12
Evidence-led pivots
Marketplace → concierge
Validated business model
2 builders
Active pilot · per-transaction
§ 05 — What I learned

Business model is a product decision. Killing code is a skill.

Three things travel out of this project.

Business model is a product decision, not an operational one. Marketplace vs. concierge changes everything downstream — onboarding flow, success metrics, support model, pricing, brand voice, even which users count as "the customer." PMs often treat business model as a given to work around; TerraLink taught me it's one of the earliest variables to test, because getting it wrong makes every downstream decision harder.

Killing code is a product skill. Three months of the marketplace codebase had to die so the concierge version could live. The emotional tax of that decision — watching working software become irrelevant — is where most solo founders stall. Doing it deliberately, with evidence, and with the next version already sketched, is the muscle that separates "pivoted" from "drifted."

And the design principle that ties this to everything else I buildsimple on the surface, rigorous underneath. The builder sees a magic link, a clean quote, a delivery date, a compliance tick. Underneath: AI extraction, persona-specific UIs on shared state, RAG validation against AS2047/AS1288, escrow milestones, supplier performance tracking. The rigour is for me to worry about. The surface is for the user.

Every pivot on this project came from five-user interviews. Every pivot I refused to make came from wanting to protect code I'd already written. The second pattern is the one to watch.