From spec-writer to builder: what shipping StockSnap taught me

I spend my days writing PRDs, defining agent architectures, and negotiating tradeoffs with engineering. So I set myself a constraint: build a real, working AI product end to end, by myself. The result is StockSnap — snap a photo of a vendor's handwritten delivery note, and AI reads it and updates a store's inventory.

“What I cannot create, I do not understand.”

The AI was the easy 20%

Sending an image to a vision model and getting structured items back? That part took an afternoon. The other 80% was everything around it: blurry photos, items the model wasn't sure about, messy handwriting that didn't match anything in the catalog, and giving a shopkeeper a way to confirm or correct before anything was saved.

That 80% is exactly where product judgment lives. When do you ask the user to confirm? How do you surface uncertainty without burying them in it? What happens when the AI is confidently wrong? Building it myself turned those from slide-deck abstractions into decisions I had to actually make.

Measuring accuracy changed the product

The same instinct from my enterprise work showed up at small scale: I added an accuracy metric so I could see how often the AI got an item right. The moment you can measure it, you start designing for the failure cases — suggestions for unmatched items, an easy 'add as new product' path — instead of pretending they won't happen.

Why it made me a better PM

Having built one, I spec AI products differently now. I'm sharper about the confirmation step, more realistic about edge cases, and faster to push for an evaluation metric on day one. None of that was new knowledge, exactly — but there's a difference between knowing something and having felt it. You can try StockSnap yourself; the link's on the Build page.