Tools shaped by the way we work, not the other way around.
I’m Michael. I run operations at The Juilliard Store in NYC, and I build the systems it runs on: purchasing, receiving, and special orders.
37,000 SKUs · 100+ supplier accounts · used daily by the whole staff
Selected work
ReStocky purchasing and receiving
Replaced the store’s purchasing app ahead of its planned shutdown. The shutdown was later postponed, and the team chose to stay on ReStocky.
Special Orders request to pickup
Every special order from the counter to pickup. It started as an order sheet printer and grew one request at a time.
Item Clearancer
Scan a SKU and get a clearance listing: a manual process of 5 to 10 steps, cut to one.
Annual Inventory Lookup Tool
Finds any item by where it was last scanned, refined over three inventory counts.
What I bring
Most teams have people who understand the operation and people who can build software. I do both: I know where the process breaks because I do the work, and I can build the fix carefully enough that a store runs on it.
Operations from the inside.
I run the store’s backend, from inventory and receiving to vendor accounting and the annual count, across 37,000 SKUs and more than 100 supplier accounts. How I got here →
Build or buy, decided on evidence.
When our purchasing app was being retired, I evaluated the market, tested the best option against our real workflows, and made the case to build. The decision →
Systems shaped around real workflows.
Special orders that sort themselves into queues, so nothing waits on someone’s memory. Purchase orders that stay one document through every partial delivery. Special Orders →
Changes made safely.
Sandbox copies, automated tests, and dry runs before anything touches live data, including moving years of order history between systems. How I check →
Rollouts people keep.
ReStocky replaced a system the team had used for years with almost no retraining. When the old one got a reprieve, they stayed anyway. What changed →
How I work
My coworkers are my clients.
I ship the smallest thing that helps, then let the people using it tell me what comes next.
Change what’s broken, not what people know.
Every change to a familiar workflow costs the team something, so each one has to earn its place.
Know what not to build.
A feature that makes a tool harder to use isn’t worth having, even if it’s easy to build.
Every decision is mine to defend.
I build with Claude Code. I decide what to build, own the architecture and data models, and define what correct behavior looks like. Claude Code writes the code and the tests. I verify every change myself in a sandbox before it reaches the store, and I can defend every decision.
Music, sociology, operations, software. How they fit together →
If your team needs someone who knows the operation and can build for it, let’s talk.
Contact