Stockroom

Home page
Activity
Restock

Inspiration

You've had this happen. You ask someone working at a small shop if they have something in stock, they say "let me go check," they disappear into the back for two minutes, and they come back and tell you no. Sometimes they come back and they're not even sure.

Now think about what happens when you ask the same question at Target. The employee pulls out a little handheld, taps it twice, and tells you there are three on the floor in aisle four and six more in the back. Three seconds. No walking.

That gap bothered me. It isn't a knowledge problem or a caring problem. The person at the small shop knows their store way better than the Target employee knows theirs. It's a tooling problem. Big retailers spend real money on centralized inventory systems, and everybody who works there gets a window into the same live data. Small businesses get nothing, so they run on paper, memory, and one person who happens to know where everything is.

The cost of that is invisible but it's constant. A customer walks out without buying. A shelf sits empty for a week while the exact product is sitting in a box in the back room. Someone orders more of something they already have too much of. None of it shows up on a report anywhere, so nobody fixes it.

I wanted to build the thing that closes that gap.

What it does Stockroom is a shared inventory app for small businesses. The important word is shared. Everyone working at the store sees the same live data at the same time, on whatever device they've got in their hand.

The core screen answers one question: where is this item right now. You search or scan, and you get something like "3 on floor, aisle 4, 6 in back" instead of a single number. If it's out, it tells you what's at another location and when the next delivery is expected.

When somebody moves stock from the back to the floor, that change shows up on everyone else's screen within a second. No refreshing, no syncing, no one shouting across the store. Every movement gets logged with who did it and when, which is what makes a shared system trustworthy instead of chaotic.

On top of that, it tells you when to reorder. Not just "you're low," but "you'll run out Sunday, your supplier takes five days, order today."

How I built it I used Next.js and TypeScript on the front end, Supabase for the database and realtime subscriptions, and Tailwind for styling. It's a PWA, so it installs to a phone home screen and to the Mac dock and runs in its own window without a browser address bar.

The most important decision I made was in the data model, and it took us a while to get there. Most inventory software stores one number per product. Quantity: 14. We realized pretty quickly that a single number can't answer the question anyone actually asks, because "we have 14" is useless if all 14 are in a box in the back and the customer is standing at an empty shelf. So instead of storing quantities, we store locations. Floor, back stock, other location, on order, on hold for a customer.

The second decision was making movements the source of truth. Every change writes a row saying what moved, from where, to where, who did it, and when. Current stock levels get derived from that history rather than being edited directly. We did this for the audit trail, since a shared system where anyone can silently change numbers falls apart fast.

The forecasting came out of that almost for free, which was a nice surprise. Once you have a timestamped log of every unit leaving the shelf, you have sales velocity. Compare that against how long a supplier takes to deliver and you get an order by date. We didn't have to ask store owners to enter any extra data, which matters a lot, because they won't.

Challenges I ran into Scope was the hardest part. Inventory software can expand forever, and every feature we thought of sounded reasonable. Payments, supplier integrations, scheduling, accounting exports. I ended up writing an explicit list of things we were not building and checking new ideas against one test: does this help someone standing on the floor with a customer waiting? If not, it got cut. That test saved us more time than any tool did.

Realtime sync was fiddly to get right, especially handling what happens when two people look at the same product and one of them changes it. We also had to think about offline behavior, because back rooms have terrible wifi and pretending otherwise would make the app useless in exactly the place it's needed most.

The other real challenge was positioning. Square and Shopify already do inventory, and I had to be honest with myself about whether I was building something new. What I landed on is that those tools are built for the owner doing back office work: reports, reorder points, month end counts. Nobody hands a Square dashboard to a part time employee mid shift. Once we understood we were building the floor staff lookup device instead of another back office dashboard, a lot of design decisions got easier.

What I learned That the boring part is the valuable part. I came in thinking the interesting work would be the AI. It turned out the hardest and most useful thinking went into the data model, and the forecasting only worked because that model was right.

I also learned to be suspicious of features that sound impressive. The single best moment in our demo is showing a product with zero on the floor and six in the back, which is barely a feature at all. It's just the data model doing its job. That moment is worth more than anything flashy we could have added.

What's next Better forecasting once there's more history to learn from, including seasonality and day of week patterns. Receiving deliveries by scanning a packing slip. Multi location support for businesses running two or three shops. And most of all, getting it into an actual store to find out what we got wrong.

next.js · typescript · react · supabase · postgresql · tailwindcss · pwa · websockets · vercel