I Built a Barcode Scanner for My Liquor Cabinet. Here's How I Actually Think.

It started with a TikTok channel idea and a liquor cabinet that had gotten out of hand.

I wanted to scan bottles, build a running inventory, and document the whole thing for a channel I'm starting called The Pour Index. Simple enough. A weekend project, maybe two.

Six weeks later I had a functioning app, a shared community database, Claude reading labels off photos, and a lesson I keep relearning in client work: the best decisions almost never come from planning. They come from actually using the thing you built.

Here's what happened — and why it matters for how I work with founders.

The first problem wasn't the problem I thought it was

The original idea was straightforward: scan a barcode, get the bottle info, add it to an inventory. Except barcode databases are built for cereal aisles. Mass-market spirits? Maybe. Anything from a smaller distillery, an import, or a store-specific label? Nothing. The databases that exist are either locked behind expensive APIs or too thin to be useful for anyone who drinks anything interesting.

I could have worked around that gap — queried multiple sources, cobbled together partial data, accepted the holes. Instead I asked a different question: what if the database didn't exist yet because nobody had built it the right way?

That shift — from "how do I work around this constraint" to "what if the constraint is actually the product opportunity" — is something I find myself doing constantly in client engagements. The presenting problem is rarely the real problem. The real problem is usually one level up.

So instead of patching around a bad database, I built a mechanism to create a good one. Every bottle someone names gets remembered — not just for them, but for the next person who scans that same barcode. No company curating it, no login wall, no licensing fee. Just people who actually drink this stuff building the database that should have existed already.

Almost none of the good decisions came from planning

The first version of "scan while you shop" was capturing photos of barcodes. Not labels — barcodes. Which sounds obvious until you're standing in a liquor store watching it happen in real time and realizing that the barcode is on the bottom of the bottle, not the front, and you've been designing for a scenario that doesn't match how people actually hold things.

A five-second "flip the bottle" pause in the UX fixed it completely. Five seconds. But I never would have found that sitting at a desk.

This is something I try to build into every engagement: the earliest possible contact with reality. Not a survey, not a workshop, not a 40-slide deck. Actual usage, actual friction, actual humans doing the thing. The Pour Index taught me that lesson again in miniature — the gap between "how I assumed people would use this" and "how they actually used it" was significant, and bridging it required being in the room with the problem, not analyzing it from a distance.

Meet people where they already are

I'd assumed everyone would start from zero. Scan bottles one by one, build the inventory from scratch, embrace the clean slate.

Then I remembered I already had a spreadsheet of my own collection. Names, quantities, rough notes. Completely unstructured by any standard, but mine — built over time, reflecting how I actually think about what I have.

So I built an import function. Drop in a spreadsheet as-is, and the app walks you through attaching a real barcode to each entry. No reformatting required, no starting over, no abandoning the system you already had just to fit the tool.

The instinct behind that decision is something I bring into every client engagement. Founders almost always have existing systems — sometimes informal, sometimes cobbled together, sometimes embarrassingly manual. The temptation is to replace them wholesale with something cleaner. The better move is usually to understand why the existing system exists, what it's actually doing for people, and build the improvement around that rather than against it. Nobody wants to feel like their history is a liability.

Optional depth, not mandatory complexity

One of the harder design decisions was the label reading feature. If you want to skip typing names entirely, you can drop in your own Anthropic API key and Claude reads the label straight off a photo — name, brand, distillery, all of it. Entirely optional. And because it's your own key, nobody else's usage shows up on your bill and you're never paying for someone else's scans.

That constraint — making the most powerful feature opt-in rather than default — was deliberate. Not every user needs it. Not every user wants to manage an API key. Making it mandatory would have added friction to the 80% of use cases that didn't need it in order to serve the 20% that did.

The same logic applies to AI integration in business operations. The question I always ask before recommending any AI tooling is: who is this actually for, and what happens to everyone else? The most expensive AI implementations I've seen fail are the ones that optimized for the exciting use case at the expense of the everyday one.

Free and reliable aren't the same thing

The shared database — the whole "one person names a bottle, everyone benefits" idea — quietly lost data when the free service underneath it deleted an actively-used entry with no warning.

I'd known this was a risk. Free infrastructure has a way of making that risk feel theoretical until it isn't. Once other people were depending on what I'd built, the calculus changed. I moved it onto real infrastructure I already had running for another project, and it hasn't happened since.

In client work, this shows up as the difference between a solution that works in a demo and a solution that holds up when it matters. Systems that depend on goodwill, free tiers, or manual maintenance feel fine until the moment they don't — usually the moment that costs the most. Building for resilience from the start costs a little more upfront and a lot less when things go sideways.

What this has to do with how I work with founders

The Pour Index is a side project about spirits. But the decisions I made building it are the same decisions I make in client engagements every week.

Find the real problem, not the presenting one. Get into the real world as fast as possible. Meet people where they are rather than where you wish they were. Make powerful things optional rather than mandatory. Build for the moment it matters, not just the moment you're watching.

None of this needed a team, a funding round, or months of runway. It needed a clear problem, a lot of small real-world tests, and a willingness to throw out an approach the moment it didn't hold up in practice.

That's how I think. That's how Large Fraction works.

If you want to see the result: The Pour Index is live on GitHub — free, still evolving, and genuinely useful if you have a liquor cabinet that's gotten out of hand.

And if any of this sounds like the kind of thinking your business could use right now — the first conversation is always free.