Sam Jennings
← ALL FIELD NOTES
004 · 2026-08-20 · BUILD NOTES · 3 MIN

It worked. I cut it anyway.

A finished Instagram-style story viewer for a taproom menu, deleted before any guest saw it. “It works” turned out to be the wrong bar.

There’s a finished feature in Camp Beer Co.’s codebase that no guest has ever seen. A full Instagram-style story rail for the taproom menu: tap-through cards, hold to pause, swipe down to dismiss. The progress bar’s fill animation was the advance timer itself, so the bar and the timing could never drift apart. I was quietly proud of that part. It worked on the first real test.

The idea wasn’t silly. The menu had just picked up a wave of new features, and a “first pour” rail felt like a natural front door: a few cards showing what’s worth knowing right now. Today’s patio weather. Tonight’s event. Whether Campy Hour is on. Guests already know the gesture from Instagram; tap, tap, tap, seated and ordering.

Then I reviewed it the way I’d want someone reviewing work they were about to sell me, and every card failed the same question: does this tell a guest something the page doesn’t already?

THE RAIL SAID              THE GUEST ALREADY KNEW

patio forecast         →   they're sitting on the patio
tonight's event        →   the events strip, one scroll down
campy hour is on       →   the live chip in the tab bar

The weather card is for someone deciding whether to come; the person scanning the QR code already came. The events card repeated a strip that sits one scroll below it. Campy Hour already announces itself from the tab bar on every screen. Three cards, three duplicates. The rail wasn’t a front door. It was a second front door, built onto a room that already had one.

The build took about a day, and that day was spent whichever way I decided. Shipping it wouldn’t have bought the day back. It would just have added a cost that never stops: one more thing for guests to tap past, one more thing to maintain, one more thing that can break on a Friday night. A feature that repeats the page it sits on isn’t a feature. It’s decoration with a maintenance bill.

“It works” is not the bar. “It earns its place” is.

So it’s still in the repo, wired to nothing. If the menu ever grows content the page doesn’t already carry, a rest-of-day patio forecast, say, the rail can earn its way back in an afternoon. Deleting it from the product didn’t mean deleting the work.

If you hire people to build things, here’s the transferable bit: feature lists are how software gets sold, but judgement is most of what you’re paying for. When you’re evaluating a builder, ask what they’ve cut. Not what they descoped for budget, but what they built, finished, tested, and then removed because it didn’t deserve the space. Someone who’s never deleted finished work isn’t reviewing their own output; they’re shipping their first draft and calling the length of the feature list progress.

The rebuild this came out of, flight spinner and all, is on the work page.

Working on something like this? hey@samjennings.dev