Idle site cameras turned into a searchable record in three weeks

Context

Construction sites already have cameras. What they do not have is a way to answer a question. A project manager wanting to know when a particular pour happened, or whether scaffolding was up on a given week, scrubs through a timelapse by hand — which means the footage is used for disputes after the fact rather than decisions during the build.

The premium end of this market — OpenSpace, Buildots, Doxel — solves it by aligning capture to a BIM model and a schedule, and charges from ten thousand dollars a project upward. That tier was not the target. The gap was a fixed-camera product that could still answer questions in natural language.

What I built

• An ingestion path designed to be exposed to devices in the field: per-camera authentication tokens, a re-encode that strips EXIF and embedded payloads before anything touches disk, a content-type allowlist, a size cap, and path-traversal-safe serving.
• A two-detector vision pipeline — a standard model restricted to site-relevant classes, alongside an open-vocabulary detector running a construction vocabulary — with cross-detector deduplication and temporal flags for detections that appear and vanish. Tuning the input resolution took one test frame from zero detections to four.
• The feature that actually differentiates it: semantic embeddings per frame stored in pgvector, so a user can search site imagery by describing what they are looking for rather than by date. Most fixed-camera competitors cannot do this at all.
• An active-learning loop exposed to the customer, not hidden: confirm, correct or report a missed detection; a per-project review queue; per-tenant training statistics; and dataset export in a standard training format.
• Multi-tenancy taken seriously — three roles, a clients → projects → cameras → frames hierarchy, per-frame and per-camera access guards, and cross-tenant probes that return a not-found rather than a forbidden, so the existence of another tenant's data is not leakable.
• The delivery surface: async background jobs, PDF reports with generated charts and narrative, timelapse video export, a Next.js admin and client portal, and an Android app.

The part I am actually proud of

Not the model work. The release engineering. One command runs the full gate on a clean clone: backend tests against locked dependencies, a migration validation that proves a fresh database and a legacy database adopted into the migration system arrive at byte-identical schemas, a check that no release file is accidentally untracked, then typecheck, lint and production build on the frontend. CI runs the identical gate with locked installs only, and the dependency audit is blocking, gated on a triaged allowlist rather than a blanket ignore.

That is the difference between a demo and something you can hand to a client and still sleep. A late wave of work was entirely unglamorous for the same reason: MFA, session revocation, JWT validation, channel-bound refresh tokens, a verified content-security policy, and making backpressure fail closed rather than silently dropping frames.

The document that made the product better

Partway through, I stopped building and had the product torn apart against its three strongest competitors — capture model, AI, monetisation, and where each one is soft. The resulting assessment was not flattering, and that was the point. It stated plainly that inference was CPU-only and serialised one frame at a time, that billing was demonstration-grade, that detecting a hard hat is not the same as having a safety product, and that the BIM overlay named in my own project description did not exist anywhere in the code.

Writing down what your product cannot do, in the same document you use to plan, is the cheapest quality control there is. Every roadmap I have seen fail was optimistic in exactly the places nobody had written down.

Status, stated honestly

Deployed to staging and taken through a client-readiness audit with the findings remediated. It is not running a production customer today, and the scaling constraint is known and documented rather than discovered later: inference is CPU-bound and serialised, which is fine for a handful of cameras and not for a hundred.

Where this transfers

What it means for an employer: I take a product from idea to audit-ready in weeks, scope it truthfully, and build the controls in from day one. This is the full shape of delivering a technical product: a domain problem, a build, an honest competitive read, a security posture, and a release process that makes shipping boring. For an operations role the relevant part is that I can sit between a technical team and a commercial one and be genuinely useful to both — I have written the migration validation and the competitor teardown for the same product, in the same month.