The lab logger that can’t lose a run
Sample characterization runs at SunThru were living in scattered spreadsheets: the same measurements taken before and after processing, logged a slightly different way every time. A lab tool is only trusted if it never eats data, so I built one whose whole design revolves around not losing a run.
| Role | Design & development (solo) | For | SunThru · early-stage hardware R&D |
|---|---|---|---|
| Tools | Python 3, standard library only, single file | Timeline | 2026 |
| Result | 16 tracked fields/run · 0 dependencies · lock-proof persistence | Status | In daily lab use |
The problem
Every run produces the same set of measurements: a handful of before-and-after readings, a follow-up check the next day, condition notes, and a verdict. Scattered spreadsheets meant inconsistent columns, missed fields, and no single source of truth. The lab needed structured logging, but a lab PC is a hostile environment for software: no admin rights, no package installs, and Excel permanently open on the very file you want to write.
Constraints
- Zero installation: must run by double-clicking one file on any machine with Python
- Fully offline: measurement data never leaves the lab PC
- Output must be Excel-friendly, because Excel is where the team actually reads data
- Must survive the guaranteed failure: someone logging a run while the CSV is open in Excel
One file, no dependencies, on purpose
The entire app is a single Python file using only the standard library. It spins up a local HTTP server, opens the UI in the default browser, and everything (form, table, and the derived percentages and ratios the team cares about) is served from that one process. No pip, no IT ticket, no version drift between lab machines. Sixteen fields per run, with the derived quantities computed for you.
Designing for the failure you know will happen
The data layer is two files with different jobs. A JSON master is the source of truth: every save writes to a temp file first, then atomically replaces the master, so a crash mid-write can never corrupt it. If the master is ever found unreadable, it’s quarantined to a backup instead of being overwritten; a corrupt file must never be mistaken for an empty one.
The CSV is a mirror for humans. Excel holds an exclusive lock on open files, so mirror writes fail routinely, and that is fine. The run is already safe in the master; the app tells the user the CSV is stale and catches it up automatically on a later save, once Excel lets go. Logging never blocks on someone else’s open spreadsheet.
The result
- 16 structured fields per run, derived values computed automatically
- 0 dependencies beyond a stock Python install; deployment is “copy one file”
- Atomic persistence: no crash or lock can corrupt or silently erase the log
- number of runs logged to date here
What I learned
Reliability engineering is not reserved for big systems: a 400-line lab tool deserves the same failure-mode thinking as a flight computer. Enumerate what will go wrong (Excel lock, mid-write crash, corrupt file), then make each one boring. The tool people trust is the one that already planned for their Tuesday.