Thingamabin

The problem

I own an unreasonable number of small parts. Resistors, connectors, sensors, fasteners, cables, all spread across bins, drawers, and at least one box labeled “misc.”

The failure mode never changes. I need a part. I’m fairly sure I have it. I can’t find it, so I order another one. Two weeks later the original turns up. Now I own three, and one of them is in the misc box.

What it is

An inventory system shaped like how making actually works, rather than a warehouse tool squeezed into a garage.

Every item has a home bin, a quantity, a minimum, and whatever attributes matter for its category: resistance and tolerance for a resistor, voltage and pinout for a regulator. Bins get QR labels. Scan one to see what’s in it, or search a part number to find which drawer it’s hiding in.

Around the parts it tracks the boring things that turn out to matter. Purchase orders, what things cost and when, a movement ledger so stock changes are auditable, projects with bills of materials, and checkouts for the reusable tools that wander off and don’t come back.

The part I actually care about

Thingamabin exposes its catalog over an API, including an MCP server, so an assistant can query it directly.

That’s the bit that changes things. I can ask for help planning a project and have it check what I already own before suggesting an order. It comes back with a pick list grouped by bin, tells me what’s short, and doesn’t invent stock it couldn’t verify.

The API is read only on purpose. Nothing reserves or decrements anything without me saying so. An assistant with write access to my garage is not a feature I’m looking for.

Where it stands

Running, in daily use, going public soon. I’ll link it here when it is.

The interesting problems aren’t the CRUD. They’re how to model attributes that differ per category without the schema exploding, how to make label scanning fast enough that I actually bother, and how much authority to hand an assistant over physical things.