Burning the Notebook

The notebook

For most of its history, my family's battery shop tracked its warranties in a notebook. One notebook. Someone would write the claim down by hand, and that was the record — until the handwriting got messy, or battery acid ate through the page, or someone took it out on a delivery run and it didn't come back.

That was the system. A single book, in one person's hands, slowly being dissolved by the product we sell.

Counts were no better: a printed sheet walked around the back, with no real trace of who counted what. The phone and the fax did the rest. We were still faxing orders to suppliers in 2020, and they let us know how they felt about it.

This wasn't a quirky inconvenience. It cost us. Customers stopped trusting a warranty process where returns got shuffled around and never resolved; some of them walked. Others we kept by eating the cost. A paper notebook was quietly bleeding money out of a business that had run for seven decades.

Why nobody had fixed it

The honest answer: the process mostly worked, so no one had the time, the means, or the care to replace it. Seventy years of "this is how we do it" is a heavy thing to move. I'd worked there long enough to watch paper cause the same mess over and over. So I decided to build the thing myself.

It took me three tries.

V1 was a warranty manager running on a Raspberry Pi in the shop. It proved the idea and not much else. V2 threw out that whole stack and started over in Laravel — better, but painful to iterate on as the shop kept asking for more. V3 is Laravel and Filament, and Filament does the heavy lifting for exactly this kind of internal CRUD tool. The third time, the tool finally fit the job.

I never seriously looked at off-the-shelf POS or inventory software. It came down to cost and simplicity. We didn't need a hundred features; we needed battery-specific warranty tracking without the clutter and setup that comes bolted onto generic products. Building it custom wasn't the ambitious choice — it was the simple one.

The hard part wasn't the code

It was getting people who'd used paper for decades to trust a screen.

So I designed around them, not around the database. I watched how staff actually worked, asked a lot of questions, and cut every click that didn't need to exist — automating the steps that used to be done by hand. Everything important stays within reach; everything else stays out of the way. The test I cared about: could someone who isn't comfortable with computers still log in and clock into a shift, or pull up a ticket? They can.

You earn that trust by iterating — shipping the thing they asked for, then making it one click shorter. Adoption isn't a training problem; it's an easier-than-paper problem. Make the screen genuinely less work than the notebook, and people switch on their own.

Today everyone in the shop uses it, every day. What started as a warranty tool now runs time tracking, payroll, inventory, purchase orders, bills of lading, and lead generation. Honestly, the place couldn't function well without it now. The line that drove it home came from the manager: "We should have done this sooner."

What it taught me

Building this was a lesson in the parts of software that don't show up in a tutorial: architecting for change, designing around real user problems instead of imagined ones, and keeping a system people depend on actually online — backups, uptime, the unglamorous stuff that decides whether anyone can work tomorrow.

I took a messy, decades-old, deeply human process and turned it into software the whole business now runs on. That is the work I want to keep doing.