Case study

ReStocky

The Juilliard Store's purchasing and receiving system

The Juilliard Store runs its purchasing operation on software I built. Since August 2026, purchase orders, shipments, and receiving at the store (37,000 SKUs, 100+ vendor accounts) run through ReStocky, a system I designed and built solo in about six months while working my full-time role as Operations Manager.

At a glance

Role
Designed and built solo, alongside my full-time role as Operations Manager
Timeline
About six months; live since August 2026
Scale
37,000 SKUs and 100+ vendor accounts
Stack
Next.js, Postgres, and the Shopify Admin API, on Vercel
Used by
The store's four full-time staff daily; part-time associates through a lookup view
Size
Roughly 93,000 lines of TypeScript across 420+ pull requests

01The problem

Shopify announced it would sunset Stocky, the purchasing and inventory app our operation was built around. I was tasked with finding a replacement.

After evaluating the market I selected Qoblex as the closest fit, then ran a gap analysis against our real day-to-day workflows.

The gaps were material: no inline editing of retail prices and costs during purchasing, no margin visibility on purchase orders (which our buying decisions depend on), and a retraining burden across a team whose muscle memory was shaped by years of Stocky.

02The decision

I put the options side by side: adopt a good product that fit our workflows imperfectly, absorbing permanent compromises plus retraining across the team, or build a replacement shaped exactly like the workflows we already had. I made the case that building was the smaller total lift, and got sign-off to do it.

03What I built

Stack

  • Next.js
  • TypeScript
  • Postgres
  • Shopify Admin API
  • Vercel

A Next.js and Postgres application on the Shopify Admin API, deployed on Vercel. It reproduces Stocky's documented workflows with one deliberate deviation: shipment-based receiving.

How ReStocky fits together. Staff and the scanner PWA sign in through one gate; the app keeps purchasing data in Postgres and talks to Shopify, Shippo, and exchange rates. Open full diagram

Under our old workflow, every partial delivery had to be logged as its own purchase order; in 2025 that turned the store's receiving into 1,567 nominal POs, many of them fragments of the same original order. In ReStocky, PO numbers are immutable, every arrival is a numbered shipment against the original order, and backorders stay on that order, so a purchase order remains one document through its whole life.

One purchase order, start to finish. Each box is received as a numbered shipment on the same PO number, and short lines stay on the order until they arrive. Open full diagram
The purchases list. Each PO keeps one number for its whole life, with shipments, fulfillment progress, and late orders flagged against learned lead times.
A partly received purchase order. Retail, margin, and cost against basis sit on every line, where buying decisions get made.

Under the hood:

  • Reorder suggestions that don't mistake a stockout for low demand. Each SKU is classified by how it sells and routed to the forecasting method that fits it, with out-of-stock periods set aside. Every method is backtested on our own sales history, and none ships unless it beats the existing baseline. (Syntetos Boylan classification; SES, Croston, SBA, TSB, ADIDA; scored on RMSSE and MASE.)
  • Arrival dates staff can plan around. Each supplier's lead time is learned from its own delivery history, weighting recent deliveries more and counting overdue orders as they age, so every open order shows an expected date and flags itself when late. (A decayed weighted median with censored observations.)
  • Receiving that feeds accounting. Moving-average costs, landed cost with freight allocation, invoice matching, and GL coding all happen as goods arrive, not as a separate step afterward.
  • Changes that don't break the store. 53 test suites run on every change, new features are tried in a sandbox copy first, and 68 database changes have shipped without losing data.
A supplier's catalogue with reorder suggestions. Each item gets an ABC grade, a sales rate, and a projection against the supplier's learned lead time.
Receiving a shipment against the original PO. Costs and retail can be corrected inline, and the invoice panel below feeds landed cost and accounting.

04Working with the team

I didn't need a discovery phase to learn the workflows, because I had done them. I built and tested ReStocky against a sandbox copy of our data, and brought the team in through a couple of meetings before cutover.

The rollout itself was a walkthrough of the main workflows, and it went smoothly because ReStocky was designed to keep the shape of the old system: buttons where people expected them, steps in the order they already knew.

Since launch, I've told staff that any request is fair game, and I keep looking for places the work can be smoother.

05What changed

The store cut over to ReStocky in August 2026, built against Stocky's original August 31 sunset. Days before that deadline, Shopify extended Stocky's life to March 2027. The pressure that forced the project disappeared, and the old system stayed available as a fallback for another seven months.

We stayed on ReStocky. It holds its place on preference, not necessity: it matches how the team already works, keeps margins visible where buying decisions happen, and required almost no retraining.

It now carries the store's full purchasing volume, on the order of 1,500 receiving events a year, and is used daily by the store's four full-time staff, while part-time associates use a lookup view to see at a glance whether an item is on order.

The home screen. Open orders, boxes on the way, unpaid invoices, and how much stock has gone idle, at a glance.

Built solo with Claude Code in about six months: roughly 93,000 lines of TypeScript across 420+ pull requests. The architecture, the data model, and every design decision are mine.

Screens show ReStocky running on demo data.