Work / Case Study
An operations platform for crossbore CCTV pipe inspection, built and operated by VTS. Operators enter typed field data. The system derives a live infrastructure graph. Project managers resolve problems inline on the graph — in production daily since early 2026.
248
production releases, Feb–Jul 2026
10
typed field-entry kinds
0
stored pipe models — the graph is derived
AGPL
open source, v3.0-or-later
When a gas line is bored through a sewer lateral — a crossbore — it can sit undetected for years until a plumber's cutter head finds it. Crossbore-prevention crews run CCTV cameras through sewer mainlines and laterals to prove that every address on a project is clear. Each crew turns in a daily submission: camera runs, taps discovered, access problems, photos, footage.
The hard part isn't collecting that data — it's knowing what it adds up to. Which addresses are actually proven complete? Which laterals were seen but never verified? Which runs conflict? General-purpose tools — paper forms, spreadsheets, folders of video files — can't answer those questions, because they don't understand that the data describes a connected network of pipes.
Pipetree was designed by someone who has run these crews. That's the difference: it encodes how the work actually happens in the field, not how an office imagines it happens.
There is no Pipe table, no CAD import, no pre-defined segments. As operators log inspections, segments connect into chains, chains group by address, and completeness is computed from the actual run data on every read. Delete an entry and the tree updates. Reroute a lateral and it reflows. There is never a sync bug between the data and the derived graph — they are the same thing.
A questionable camera run still shows the pipe on the map — but only a successful run (or one a PM explicitly accepts) proves the endpoint complete. A lateral can be visible and unproven at the same time, and the UI says so. Conflating those two axes is how inspection operations end up trusting maps they shouldn't.
There is no click-through-every-submission verification workflow. Project managers see the same graph the operators built, annotated with action tags — needs cleanout, orphaned branch, unlinked, pending review — and clear them inline. Accept flips a questionable run to success; Reject drops a wrong run so the next-newest wins automatically. Every change is audited.
Captured from a demo instance seeded with fictional inspection data.
Operators don't get input gates — they get suggestions and warnings. Bad data is a review concern, not a submission blocker; a tap GPS reading 1,000 feet from its siblings surfaces an amber warning without stopping the save. Drafts auto-save every two seconds and sync across devices, so a submission started on the truck laptop finishes on a phone. Photos are typed slots per entry — the operator sees exactly which shots this entry still needs, and requirements are enforced at submission, not mid-crawl.
New entries pre-fill from the previous one — but only fields where being wrong costs nothing to fix. Addresses carry forward; lateral IDs never do. Getting that boundary right is field knowledge, not software knowledge.
One Next.js process, one PostgreSQL database, one Linux host. No message broker, no queue, no background-worker fleet — scheduled work is CLI subcommands the app ships, run by systemd timers. Boring is what lets one engineer ship 248 production releases in five months without an ops team.
Application
Next.js 16 (App Router), React 19, TypeScript — one process, custom server entrypoint with WebSocket upgrade and graceful shutdown
Data
PostgreSQL with Prisma, Zod validation at every API edge, native Postgres enums for closed sets
Field UX
PWA with offline-aware service worker, 2-second draft auto-save with cross-device sync, typed photo slots with HEIC-to-JPEG processing
Auth
Session auth for people, service tokens for machines, one dispatch path for both
Geo
Google Places + Maps with per-tap GPS anomaly warnings
Deploy
GPG-signed RPMs from self-hosted CI onto hardened Fedora + systemd — no containers, no cloud dependency
Pipetree's source is released under AGPL-3.0-or-later. If someone modifies it and runs the modified copy as a service, the people using that service get the source — reciprocity that survives the SaaS era. Install it, self-host it, hack on it; the deployment contract is real and documented.
Pipetree exists because the person writing the code has run the crews. If your operation needs software built by someone who speaks both languages, let's talk.