PROPCHECK
AI Engineering
Two phone walkthroughs, one machine-detected difference — a rental-evidence product whose front end shipped and whose engine is still a specification.
01The problem
When a short-term rental guest damages a sofa, a wall or a floor, the host has to prove it, and the only evidence most hosts hold is a folder of ambiguous phone photos shot from wherever they happened to stand. Claims processes reject weak documentation, and a host with high turnover meets this every stay rather than once a year. In Hong Kong the same gap reappears at tenancy handover, where small claims are heard with no legal representation allowed, so the evidence has to speak for itself.
The existing answer is to photograph everything, twice, every turnover. It is slow, inconsistent, and still loses arguments, because a before photo and an after photo are rarely of the same thing from the same place. The gap is not take more photos; it is that a flat image carries no spatial ground truth to compare against.
02What I built
The design is a two-scan product: a roughly three-minute phone walkthrough before check-in and another after checkout, both reconstructed as 3D point clouds, aligned, and differenced. What exists today is the front end — a bilingual landing page with a scroll-driven browser scene and a waitlist that writes to a record store. The detection pipeline behind it is specified in full and integrated with nothing.
- Phone-only capture in the design: an ordinary walkthrough, no depth sensor and no specialist rig.
- Two-stage detection: point-cloud alignment and a distance threshold filter first, a vision model classifies second.
- A timestamped before-and-after report intended to survive a claims reviewer or an adjudicator.
- A scroll-choreographed browser scene: one point cloud carrying chaos, before and after position buffers plus a per-point difference attribute, morphed in a hand-written shader.
- Bilingual English and Traditional Chinese site with segment-tagged waitlist capture across five audience segments.
- An answer-engine layer built into the page: keyword set, long-tail question set, extractable answer snippets and structured FAQ data.
Drawn, not captured. The field of points stands in for the browser 3D scene, the three cards are the promised steps, and the row at the bottom is the waitlist. The three step marks are hollow on purpose: the only filled control on this page is the one that stores an email. No result screen is drawn because no scan has ever been run.
03As a product
- Who buys it
- Short-term rental hosts first, because high turnover makes the pain monthly rather than annual and the audience adopts tools without hand-holding. Secondary: property managers running many units, and Hong Kong landlords preparing deposit disputes.
- Value
- Turns a walkthrough hosts already film informally into evidence that survives a reviewer. The buyer is not paying for 3D; they are paying to stop losing arguments about who broke the sofa.
- Positioning
- Inspection apps are checklist-and-photo tools. Capture products sell a viewing experience, not a differencing engine. The wedge is the comparison rather than the capture, which makes this deliberately a middleman: license the reconstruction, own the brand, the flow and the report.
- Status
- Not commercialised. Landing page live and collecting waitlist signups, no paying customers, no revenue, detection pipeline never integrated with a reconstruction provider.
04How it works
- Stack
- Next.js, React and TypeScript with Tailwind, a react-three-fiber scene with a hand-written shader, an animation library, and a hosted table as the waitlist store, deployed on Vercel behind a bought domain. Designed and not built: a point-cloud library for alignment and differencing, a licensed reconstruction API, and a vision model for classification.
- Shape
- What runs today is a static page plus one route handler that writes a single record. The pipeline in the diagram below shares none of that code; it exists as a specification and a cost model.
Width uniform throughout — nothing in this pipeline has ever been instrumented, so every band is drawn at equal width and no quantity is claimed.
Geometry decides where something changed before a model is asked what it is, so a vision call can never be billed for an unchanged wall. That is the whole argument, and it is still only an argument: the threshold has never been tuned, and the share of a room that survives it has never been measured.
The decision I spent longest on
Whether the model should look at the whole scan or only at what changed. Handing entire before-and-after scans to a vision model is the obvious build and it fails twice: cost scales with the size of the room rather than with the damage, and the model invents differences in identical regions. The design inverts it. Geometry decides where something changed, deterministically and without an API call; the model only decides what it is, on a handful of small crops. The second decision was refusing to build reconstruction in-house, because that step is a commodity to license and the differencing is the defensible part.
05Retrieval architecture
Nothing in this section runs. The pipeline is a specification and a cost model, so what follows is the shape of a decision rather than the behaviour of a system, and every row below should be read as a claim about intent.
The claim worth making is that the corpus here is not a document set at all — it is a room, and almost all of a room is identical between two visits. The selection step is geometry, not similarity, which is the only reason the design would be affordable and the only thing about it that has never been tested.
ModelAt query time only. A vision model would run once per comparison, on crops chosen for it — in a pipeline that has never been executed.
- Corpus
- A room rather than a library. Two reconstructions of the same space captured at different times, returned as point clouds by a licensed third-party service, and meaningful only as a pair: neither scan says anything on its own, and the whole corpus for one comparison is the two of them side by side. This is designed. No scan has been run and no cloud has ever been received.
- Ingestion
- One pair per stay, by design: a roughly three-minute phone walkthrough before check-in and another after checkout, with no depth sensor and no specialist rig, uploaded by whoever cleans the unit. Reconstruction is deliberately bought rather than built, on the grounds that turning video into a point cloud is a commodity and the comparison is the defensible part. That integration was never started, so nothing has ever been ingested.
- Index
- None. A pair of clouds exists for the length of one comparison and is then finished with, so there is no set to search and nothing worth precomputing across. Indexing would only start to pay if scans were kept and queried across stays, and that is a data-retention position the product has no reason to take: holding a reconstruction of every guest’s bedroom indefinitely would be a much larger promise to a customer than the one being made.
- Query
- None. Nobody asks this system anything. A comparison is triggered by a checkout rather than by a question, and the predicate is fixed in the design: everything that moved by more than a threshold. There is no wording to parse, no ambiguity to resolve and no user in the loop at the point of selection — the only human decision in the whole flow is when to press record.
- Selection
- The mechanism is a distance threshold. The two clouds are aligned into a single coordinate frame, a distance metric is run across them, and only the regions whose displacement crosses the threshold survive — the same move as pulling a few passages out of a corpus before a model reads anything, except the ordering is displacement rather than similarity, and the score is deterministic, so there is no API call and nothing to hallucinate at the selection stage. What survives is then reshaped rather than passed on: the flagged regions are rendered back out as flat images, so the model receives a handful of small crops rather than a scene. The threshold has never been tuned and the surviving fraction has never been measured.
- Grounding
- None. Nothing constrains the model’s output, because there is no pipeline to put a constraint in front of. The design carries the ingredient a grounding layer would be built from — the model is never asked where something changed, only what it is, so geometry rather than a model decides what is real — but that is an argument, not a mechanism. No damage vocabulary has been fixed, no confidence floor has been set, and no report has ever been produced for a human to check or reject. Naming the gap is more useful here than describing a guard that has never run.
Present — this layer exists and runs.Absent by decision — the layer is not there, and the sentence beside it is the reason. Every one of the six is answered on every system in this chapter, so the rows can be read across pages.
06Numbers
| Measure | Figure | Basis |
|---|---|---|
| Idea to deployed bilingual landing page | 5 days | Verified |
| Shipped front-end codebase | 1,395 lines | Verified |
| Points animated in the browser scene | 18,510 | Verified |
| Waitlist signups | Not measured | Verified |
| Intended price per unit, per year | HKD 88 | Verified |
| Share of a scan reaching the vision model | Under 5% | Projected |
| Vision cost saved by the geometry filter | 10-20x | Projected |
| Capture time per walkthrough | ~3 min | Projected |
Verified — counted in the shipped source and the commit log, and confirmed live on 2026-08-12. The price is a documented target that has never been charged, and the signup count is genuinely unmeasured rather than zero. Projected — the filter share assumes a typical unit changes in only a few localised places, so an alignment-and-threshold pass rejects most surfaces; no pipeline run has measured this and the threshold itself is untuned. The cost saving follows arithmetically from that share. The capture time is the product promise, derived from walking a small flat, not from timed sessions.
07Timeline
- 2026-04 Concept worked out, including the two-stage pipeline and the decision to target short-term rental hosts rather than institutional landlords.
- 2026-04 Repository initialised, bilingual landing page built and deployed to its own domain.
- 2026-04 Waitlist route, the browser point-cloud scene and the answer-engine data layer committed. Within a day of launch the project was flagged internally as landing-only: deployed, with nothing behind the promise.
- 2026-08 Site still live and serving. Pipeline still not integrated; no reconstruction provider has been called once.
08Looking back
What broke
Sequencing, not code. The landing page, the bilingual copy, the answer-engine layer and the 3D hero all shipped in three days, and the part that makes this a product never started, so a visitor arrives at a well-optimised page promising something they cannot try. The live copy is also written in the present tense for a pipeline that does not exist, which is a stronger claim than this page makes; the gap was recorded within a day of launch rather than discovered months later, and it has not yet been closed in either direction.
What it changed
It forced a clear line between the parts of a 3D product worth building and the parts worth licensing. The confidence to draw that line came from adjacent work — running marketing for an XR studio that delivers real reconstruction captures for training simulations meant the cost, quality and turnaround of that step were known rather than assumed, which is exactly what made licensing it the obvious call.
Where it stands
Paused at prototype. Live marketing site and working waitlist capture; detection pipeline fully specified and never run. The next gate is a feasibility test against a real reconstruction API, before any further front-end work.