Live Studio OS
- Role
- Designed and built with the company’s CEO, a software engineer. Two people, no other engineering resource. In-house, Ad The Top.
- Problem
- Studio procedure, equipment records and fault history lived in separate documents that had begun to contradict one another. The answer to “what is in this room, and does it still work” depended on who you asked.
- What I built
- One web app the team opens on whatever is to hand — a phone on the studio floor, a desktop at the office. Standard settings and a shutdown checklist, per-room equipment guides, a health check that turns a walkthrough into action items, and a fault log that exports the monthly report. Google Apps Script serves a single page; a Google Sheet is the database, addressed by column name rather than position so staff can reorder and rename it without a migration.
- Constraints
- No budget for hosting or licences, no staging environment, and a team with no technical background. It runs on the Google Workspace the company already pays for. Every change deploys straight against the data the team is using that day — the database is a document they have open while the code is writing to it.
- Outcome
In daily use by the studio team, currently on its twentieth release. Requests now arrive as feature ideas rather than workarounds. The data layer is round-trip tested — written, read back, compared — so reordering a column no longer breaks anything. Four known limits are documented and deliberately unfixed, including a whole-table save that loses data if two people write at once, which needs the save path rebuilt.
The split was by strength: the CEO brought the engineering depth, I brought the studio floor and the operational discipline. The database rules the system is now held to, and the deploy order that stops old code redeploying over live data, exist because I asked for them — after both had already gone wrong once.
| Aspect | BEFORE | AFTER |
|---|---|---|
| Equipment records | A sheet per room, edited by hand | One register, read by the app |
| Fault history | Told in chat, then lost | Logged with room, phase and severity |
| Monthly report | Rebuilt by hand each month | Exported from the log as PDF or CSV |
| Source of truth | Two documents disagreeing | One dashboard, named as authoritative |
| Rule | BEFORE | AFTER |
|---|---|---|
| Column access | By position | By header name |
| Reordering columns | Broke the app silently | Free, and expected |
| Types | Coerced by Sheets, unnoticed | Converted on read, locked on write |
| Verification | Assumed | Round-trip tested |
Keepsake
- Role
- Sole designer and developer. Private commission, two users.
- Problem
- Two people wanted a single shared record of their life together that would outlive whatever platform held it. Consumer apps make that record someone else’s asset, and none of them promise you can get it back intact.
- What I built
- A private two-person archive: entries with photographs, tags and colour labels, a timeline, and an on-this-day view. One page, installed to the home screen. Cloudflare Workers with D1 and R2, behind Access allow-listing exactly two addresses.
- Constraints
- One of the two users is non-technical and had to manage on his own Android handset without instruction. Exactly one runtime dependency was permitted. The backup was not allowed to sit with the same vendor as the data.
- Outcome
- Deployed August 2026 with a nightly backup to a different vendor and a thirty-day retention sweep. The acceptance test was not a passing suite — it was the non-technical user creating a memory unassisted, on his own phone. He did.
| Decision | BEFORE | AFTER |
|---|---|---|
| Photo storage | Object storage on a paid tier | R2, zero egress at any volume |
| Thumbnails | An image transform service | Made on the phone before upload |
| Sign-in | Password screen and session code | Edge auth, two addresses allow-listed |
| Backup | Same vendor as the data | Nightly export to a different one |
The studio register
- Role
- Sole author. In-house, Ad The Top.
- Problem
- Equipment was tracked in a workbook whose formulas had to be repaired by script before anyone could trust a total. Warranty dates sat in a column that was only ever read after something had already broken.
- What I built
- A register of just over five hundred items held per room and floor, with a status breakdown, a by-floor rollup, and a warranty watch counting down remaining days. Python rebuilds the rollups and repairs the formulas from the room sheets.
- Constraints
- It had to stay a spreadsheet. The people maintaining it work in Excel and were never going to adopt a tool. Column order had to remain theirs to change.
- Outcome
- 501 items migrated into the studio system’s live register. The workbook stopped being the system of record and became its source.
| Aspect | BEFORE | AFTER |
|---|---|---|
| Where it lived | A worksheet per room | One register, one table |
| Warranty | A date, read after failure | Days remaining, watched |
| Rollups | Retyped by hand | Rebuilt by script |
| Condition | Known by asking someone | Four states, recorded per item |