$ Farpost

I didn’t set out to build a building-intelligence platform. In late May 2026, an insurance adjuster I knew had a rural claim and couldn’t find anyone to work it — no contractor, no inspector willing to make the drive out from the city for one job. It wasn’t a technology problem, it was an availability problem nobody’s software was built to solve. I built a dispatch app in about a week to fix exactly that: get the right professional to the right claim, regardless of how far out it was.

Three weeks later, deep into a second, unrelated project — an Android compliance app called TapLog, built around RFID tags for verifying physical inspections — I found out another company was already building almost the same thing. Not similar. The same thing, down to a striking number of features I’d built without ever knowing theirs existed. That’s a hard thing to sit with three weeks in, and there wasn’t a version of finishing TapLog that still made sense, so I stopped.

I didn’t throw the idea away, though. The part of TapLog that actually mattered — an RFID tag verifying a physical location, logging what happened there over time — got folded straight into the dispatch app I’d already built. Dispatch the right professional to the right building, and keep a real, tag-verified record of what happened at that building afterward. That fusion, arrived at by mid-June 2026, is what Farpost actually is.

The problem that matters most: it dies with the owner. The facts that actually matter about a building — where the water shutoff is, the model and serial number on the furnace, who did the roof and when, where the warranty and manuals live — exist in exactly one place today: a single owner’s head. When that person sells, retires, or just forgets, the knowledge is gone with them. Farpost anchors those facts to the building itself, via an NFC tag on the physical structure, so they survive the person. It pays off at 2am hunting a water shutoff, at a sale, or handing a job to a new contractor who’s never set foot in the building before. This is the core value proposition, deliberately designed to work for a single owner with zero network effect — nobody else has to be using Farpost for it to already be useful.

The rural service-availability gap — where this all started. National restoration franchises decline claims outside their service zones across North Hastings, cottage country, and the wider Canadian Shield. Farpost’s dispatch flow connects adjusters directly to local contractors who’d otherwise never get found for that work. It’s real, live, and still fully supported — it’s just no longer the platform’s defining feature, since the “it dies with the owner” problem turned out to be the deeper, more durable one.

Every professional starts from zero. An inspector who’s been to a building before, a contractor who already knows its quirks, an adjuster who already has the claim history — none of that persists or connects across roles today. Every visit starts cold. Farpost builds one living record tied to the building, so the right professional already knows what they’re walking into instead of re-discovering it every time.

No neutral, portable building history exists. Right now, an owner’s building memory is effectively locked to whichever insurer or professional relationship happens to be active at the time. Farpost is carrier-neutral by design — the “Switzerland” that owners, brokers, and contractors can all trust — so the record survives a carrier switch. No insurer would ever build this themselves: they’re structurally conflicted, and an insurer-owned version of this record could never actually be neutral.

A smaller mechanic worth mentioning: staleness, not just presence. Facts about a building don’t all age the same way — a foundation photo is good for years, but “current occupant” can be stale in months. Farpost tracks that decay per fact and surfaces it plainly (“this record is three years stale”) rather than passing judgment on it. Consistent with the platform’s broader principle: it documents, it doesn’t evaluate.

Building Farpost solo means there’s no one else to catch drift between what a feature was supposed to do and what it actually does — so I built that check into the process itself. Every non-trivial change starts as a written proposal (what’s changing, why, and the exact behavior expected of it) before any code gets written, and nothing merges until a deliberate drift audit confirms the shipped behavior actually matches what was proposed — not just that it works, but that it works the way it was supposed to. It’s the same discipline behind this site’s own Salesforce case study, built the same way: propose, implement, audit for drift, then finalize.

Alongside that, I keep a contemporaneous log of genuine technical uncertainty resolved through real experimentation, written down as I hit it — not reconstructed from memory after the fact. It’s the same discipline Canadian SR&ED tax credits ask of R&Dwork, kept up because it’s good practice for hard problems regardless of the tax angle, and it’s paid off enough as its own habit that it’s becoming a small project in its own right.