All work

    Client work · under contract

    Dirt Burner Monitor

    A paper burn log, replaced by a native iOS app

    Year
    2026
    Role
    Sole developer — spec, build, backend, App Store delivery

    Published 2026-07-23 · Updated 2026-09-30 · By Kai Myers, K.AI Consulting

    The problem

    The client runs a dirt burner: a thermal remediation plant that heats contaminated soil until it is clean. Operators record readings off a control-room chart recorder every hour, by hand, onto a paper Daily Burn / Maintenance log. Paper works right up until you need to find something in it — a reading from three weeks ago, proof that a temperature excursion was caught and acted on, or a shift record that has gone home in somebody's truck.

    The readings themselves are not optional. They are how the plant knows it is operating inside its permitted envelope, and how it demonstrates that after the fact.

    Dirt burner monitor home screen showing shift, hourly reading, burn, and dashboard entry points
    Shift hub — open shift and active burn surfaced at the top
    Dirt burner monitor hourly reading capture screen
    Guided hourly capture, ordered to match the control-room board sweep
    Dirt burner monitor alert limits configuration screen with threshold values blurred
    Per-reading caution and alarm thresholds — client setpoints blurred

    Screens captured from a demo account. The client's process setpoints and operational readings are blurred or absent.

    What I built

    A native iOS app that mirrors the control-room recorder screen-for-screen, so an operator already trained on the paper log does not have to learn a new mental model. Hourly capture is guided rather than free-form: the app asks for each reading in the same order the board is swept.

    Every reading is classified into a three-zone scheme — in range, caution, alarm — with per-supervisor configurable thresholds. Classification happens twice: once on the device for immediate feedback, and again server-side, authoritatively, so an out-of-range value cannot be missed because a phone was offline or a threshold was stale.

    Alerts fan out per recipient, deduplicated, over both push and email. Supervisors choose their own channels. Photo evidence is time-stamped and attached to the reading it belongs to, and each shift closes into a PDF.

    The whole thing is offline-first. An operator in a plant with bad signal keeps working; a client-UUID-keyed outbox syncs in order when connectivity returns, tolerating photo upload lag without duplicating or reordering records.

    Where it landed

    • Shipped to the App Store and in use by the client's crew
    • Less of each shift spent on paperwork, and no more digging through binders when a supervisor or inspector asks for a reading
    • Paper Daily Burn log fully replaced — capture, evidence, and per-shift PDF export in one place
    • Out-of-range readings reclassified server-side and dispatched to the right supervisor within the hour
    • Offline capture with ordered, idempotent sync — no lost or duplicated shift records

    Built with

    Expo SDK 54Expo RouterReact NativeNativeWindSupabase (Postgres · Auth · Storage · Edge Functions)TanStack QueryResendEAS Build

    Decision-support only. The app is not a safety interlock, a CEMS-certified instrument, or a regulatory reporting system, and the client remains responsible for plant operation, safety, and compliance. Client not named.

    Got a problem shaped like one of these?