Re-Planning the Beer App Around the Customer's Phone

Sprint 1 was ticketed and ready to go. Instead of starting it, I stopped, because I wasn't happy with the app. Not with a specific bug. With what the app is. The build so far is a beer catalog with admin CRUD screens, and the product is supposed to be something a customer uses on their phone while sitting at the bar. Those are different things, and the gap wasn't going to close by working through tickets written for the old framing.

So this session was a planning session: a full code audit, a hard look at one integration assumption, a UX re-plan, and a new set of features aimed at the person who actually pays for software like this, the bar owner.

The audit made it concrete

I had an agent audit the whole codebase, backend, frontend, and infrastructure, and then verified the findings against the source. A few standouts:

The frontend's API address is hardcoded to localhost. On a customer's phone, localhost means the phone itself. The app cannot work from a real device at all today.
No admin or bartender account can exist. Registration hardcodes everyone to the customer role, and the seed data assigns no users to the other roles. Every admin-only endpoint is protected so well that nobody can reach it.
The JWT signing key is committed to the repo and used as the live fallback.
A real bug: editing a beer always looks like it failed, because the client tries to parse a JSON body from a response that has no body.
There is no search. Two hundred beers, one flat list, on a phone.

The pattern across all of these is the same. The app demos fine on a laptop where the developer is also the admin. Every assumption breaks the moment a real customer opens it on a real phone.

Check the API before you plan around it

The re-plan leans on Open Brewery DB to give beer pages real content. My working assumption was that beer information could be pulled from it. Before writing that into any document, I hit the live API.

It turns out Open Brewery DB is a brewery directory. Name, type, address, coordinates, website. There is no beer-level endpoint at all. No styles, no ABV, no individual beers.

That one curl request changed the design. The tavern's own list stays the source of truth for the roughly 200 beers, which is honest to the product anyway, since the club is about this tavern's list. Open Brewery DB enriches each beer's detail page with real brewery information and powers brewery autocomplete when an admin adds a beer. Five minutes of verification saved a sprint of building toward an API that doesn't exist. This is the cheapest risk-reduction work a PM can do, and it only counts if you do it before the plan is written, not after.

The defining moment

The re-planned UX is built around one scene. A customer orders a beer, pulls out their phone, searches for that beer, reads about it, and gets it counted toward their 200. Everything in the docs now serves that:

Search is the front door. Autocomplete, filter by style or brewery, and a filter for "had / not had yet."
The home screen is the customer's progress, not a catalog welcome page.
Beer detail pages are worth reading, with brewery info pulled in from Open Brewery DB.
A new "I'm drinking this" action lets the customer do the finding on their own phone and queues a one-tap approval for the bartender. Confirmation stays bartender-gated, same as the paper sheet's initials, but the bartender's work drops to a single tap.
Beer create/edit/delete moves off the customer surface entirely. It's an admin task and it was sitting in the customer's navigation.

Features the bar owner would pay for

A digital scoresheet is a nice-to-have. What makes this worth running for the business is retention, so the feature map now has a section judged by one test: does it bring a member back in, or tell the owner something actionable?

Milestone badges at 25, 50, 100, and 150, because a 200-beer climb needs smaller wins along the way. Notifications for new beers, "only eight to go" nudges, and win-back messages after inactivity. Seasonal mini-challenges for people who finished or stalled. A QR membership card so lookup at the bar is instant. And owner analytics: which beers get confirmed most and least is a purchasing signal, and a lapsed-member list is a promotions signal.

What didn't change

Sprint 1. The bartender confirmation loop is still the product, and none of the new features have anything to attach to until a beer can actually be confirmed. The re-plan added two named epics to the roadmap, one for the phone experience and one for retention, but per the project's own grooming rule they don't get broken into issues until they're next up.