Build Story
1. The Problem With Every Other Option
I run a repair shop. Tube amps, synthesizers, guitar electronics, pedals, studio gear. For a while I managed it the way most small shops do: paper intake forms, text files, spreadsheets, and memory. It works until it doesn't. A repair note gets lost. You forget what you already tried on a unit six months ago. A job sits at the back of the bench for three weeks and nobody notices.
The commercial shop management tools are built for car shops and phone kiosks. None of them understand that diagnosing a vintage Fender amp is different from replacing a cracked phone screen. None of them track voltage readings. None of them have a knowledge base for failure modes on a Juno-106. And they all require a subscription and a live internet connection.
So I decided to build my own.
2. Designing the Data Model
The core structure is: Customer → Unit (the piece of gear) → Job (the repair event). A job contains intake, diagnostics, work performed, parts used, estimate, invoice, payments, notes, file attachments, and an optional knowledge base entry.
A customer can have multiple units. A unit can have a full service history across multiple jobs over the years. That history is searchable, structured, and permanently mine.
Diagnostics are structured JSON templates per equipment category. When I open a tube amp job I get a tube amp diagnostic form — bias readings, B+ voltage, power rail checks. When I open a synth job I get a synth diagnostic form. That makes the data actually queryable later.
3. The Status System
Not just open or closed. The actual states a job passes through:
NEW → INTAKE → QUEUED → DIAGNOSING → AWAITING APPROVAL → APPROVED → REPAIRING → TESTING → READY FOR PICKUP → COMPLETED
With branches for WAITING PARTS, ON HOLD, CALLBACK, and SCRAP. Every transition is logged with a timestamp. You can see exactly where every job is and how long it's been there.
This is the thing that prevents jobs from disappearing into the back of the bench.
4. The Build Plan
Built in deliberate phases.
Phase 1 — SQLite schema with FTS5. Customers, units, jobs, diagnostics, parts, estimates, invoices, inventory, knowledge base, status history. Foreign keys and indexes correct from day one.
Phase 2 — Pure Python data access layer. No Flask yet. Clean separation between the database and everything above it.
Phase 3 — Business logic. Job workflow validation, status transition enforcement, estimate and invoice calculations, backup automation.
Phase 4 — CLI first. new_job, update_status, add_note, add_part, today, search. Fast, scriptable, testable before there's any UI.
Phase 5 — Flask web UI. Dashboard, job list, job detail, new intake, customers, inventory, knowledge base, search, settings. Dark theme.
Phase 6 — Dashboard with real operational metrics: open jobs, on bench, waiting parts, awaiting approval, overdue, due this week.
Phase 7 — Phone wallboard. Single page, big text, auto-refreshes every 60 seconds. Designed to be glanced at from across the room.
5. The Long Game
If I use this system consistently — and I will, because I'm building it to be faster than not using it — then after a few years I'll have something most repair shops don't have: a complete, structured, searchable history of every job I've ever worked. Every failure mode. Every part. Every voltage reading. Every callback.
That's the real product. Not the software. The data the software accumulates.
At that point AI integration becomes genuinely useful. Not a chatbot. A system that can say: you've seen this symptom on this model four times, here's what it turned out to be each time, here are the parts you used. That's a real tool for a real bench technician.
