I build software and get it shipped.

There are two ways to store things. On pallets, you scan a spool into a box, four spools per box, then the box onto a pallet. You can remove at every level: a spool from a box, or a box from a pallet. Racks are the bigger part. Operators scan a spool and place it at a specific position in a rack, and a 3D view of the rack, built with Three.js, shows what's where.

Managers add racks directly in the app, and only managers can. The layout is set up by the people who use it, not hard-coded by a developer. When something is removed, the user can record a reason, and the system tracks who added and who removed each item, so there's a full audit trail.

It works on Zebra handheld scanners and on PC. On the scanner, every screen is designed around scanning instead of typing. It handles about 50–70 boxes in an average week, with four spools per box.

It was two builds. I built the original storage system alone in about two weeks. Later I built the rack expansion alone in about two more weeks, and part of that time went into gathering requirements, going back and forth with the people using it, and agreeing on what to call the parts of a rack.

The API takes one SQL statement or a batch. It parses each one into its operation, tables, joins, predicates and columns, and checks the result against a rules table that says which operations are allowed on which columns of which tables. Then it chooses the database, runs the query and returns the result.

The parsing sits on Microsoft's SQL parser library. I wrote my own override classes that record table names, clauses and the rest while the parse tree is walked.

For that area, database access rules live here, in one place. To pick a database, it reads the same per-table routing data as the migration below. The API covers one area, and the routing logic covers everything.

So new apps don't start from an empty folder, I built an internal .NET 10 starter platform, which sets up the app structure and shared patterns. I also built a hosted design library to go with it: themes, shared CSS and reusable components like dialogs, tables, KPI blocks and layouts. The goal was one consistent look and structure across internal apps, and less boilerplate.

Both apps got a modern UI and better practices. Old blocking calls moved off the UI thread into background work, so the screen no longer freezes while the app waits.

Operators fix common problems themselves. Before, if a spool was loaded into the wrong chamber, or a cycle stopped in the middle and had to be aborted, the operator had to call the support team, and the support team reset the database by hand. Those calls came at any hour, including 2 a.m. The fix was just a few queries, but it often took a long time. Now the recovery is on the screen.

Every cycle has a name on it. The old app had one global login that never timed out. Now an operator logs in to start every cycle, and to reset one, so every cycle and every reset is tied to a person.

Engineers get their own data. Detailed metrics are in the app, and trend graphs of the machine data show where things are heading and help catch machine failure. Engineers decide without asking my team for logs or data.

One tap to report a problem. On the 50+ machines, a button sends a screenshot of the screen and the end of the log file to my team, for errors or anything else. Nobody has to describe a problem over the phone any more.

One chamber kept producing bad runs. Some spools came out wrong, and some never came out, because a timer kept resetting and the run went on indefinitely. It was a nightmare to track down.

I built graphs of the machine data, and once it was plotted the pattern was obvious: the chamber was slowly losing pressure. Below a certain pressure, the machine's own controller broke the cycle and restarted the timer. Nobody knew that threshold existed.

It looked like a software bug, a timer that wouldn't stop. The cause was physical, gradual, and set by a rule in the controller that nobody had written down. You couldn't see it in any single record. On a chart it was obvious.

Now the app draws the threshold as a line on its pressure graph, and the dashboard warns when pressure drops below it. The cutoff itself still belongs to the controller. The acknowledgement fix below is from the same chamber app.