Service Well

The Problem

Working bars run on knowledge they can't look up

Friday night service. Ten servers, ten drinks each on every order. A barback gets promoted to the well with no formal training and finds out, in real time, that he doesn't know how to make half of what's being called. He needs the answer immediately. He cannot be seen searching for it. The venue is paying him to look like the answer. That's the floor where the idea began.

The fallback was the canon — Death & Co, Smuggler's Cove, the Dead Rabbit Drinks Manual — the same library a serious bar program owner keeps in the office, the same shelf I'd later find in the back of a celebrated tiki bar. The information exists. It's just bound, paginated, scattered across multiple volumes, and built for studying, not for a Friday at eleven.

The other half of the problem is institutional. A well-liked spot where I worked had a recipe binder where roughly half the recipes were wrong, and the bartenders working from it made the same drinks differently. Recipes aren't copyrightable — they're facts — which means the canon is freely available and freely getting butchered. A working bar needs a single source of truth. Most don't have one.

By the Numbers

The Solution

The canon, queryable, at the speed of service

Bartender's Black Book takes 181 recipes from the published masters and structures every one of them across 44 data points: spec, glassware, ice format, garnish, build method, technique notes, balance profile, lineage, common mistakes, substitutions, and the rest of the working bartender's mental model. Most cocktail apps store eight to ten data points and call it a database. Forty-four is the difference between a recipe and a reference.

The interface is engineered for the heat. Voice activation is designed for subtle invocation — no obvious wake word, no "Hey app" broadcast, no breaking the front-of-house illusion. A bartender mid-build can ask a question without the guest at the rail noticing the lookup happened. The answer arrives in the time it takes to reach for a jigger.

Every recipe is curated from the canon, not generated, not crowdsourced. The published masters spent careers refining these specs. Bartender's Black Book treats their work with the respect that's missing from the average bar binder. Original recipes — from Moonlit Mixology & Events Co., the bar-program spin-off that emerged from this work — are roadmapped for a separate publication later.

Built on the Canon

Curation as the moat

Most bartender apps lean on user-generated content. Recipes uploaded by anyone, rated by anyone, with no vetting and no provenance. The result is a dataset that mirrors the binder problem: a hundred Negroni variations from a hundred contributors, half of them subtly wrong, all of them claiming authority.

The 181 recipes here come from the canon — the same published works any serious bar program owner already trusts. Each recipe is sourced, structured, and consistent. The depth of the 44-point schema means the app can answer questions a recipe alone can't: what's the balance profile, what technique does this need, what historical variation am I being asked for here. Sourced facts cited to their masters. Not opinions claiming to be facts.

Designed for the Heat

Stage presence is part of the spec

The original problem was as much social as technical. A bartender visibly searching for a recipe is a bartender losing the room. The app's primary lookup paths are designed to be invisible: subtle voice triggers, single-tap retrieval, screen-off audio response when needed. The performative side of the bar — the eye contact, the patter, the apparent ease — is preserved.

Every interaction is built around the constraint of working service. No multi-step wizards. No quizzes between you and the recipe. No tutorials interrupting at 11pm on a Friday. The fastest path from question to answer wins. The second-fastest path is unacceptable.

From Bartender to Bar Program

Built behind the stick, designed for the venue

The product began as a single-bartender reference, but every feature roadmapped from here was sketched while working actual service across actual venue types — high-volume casino bars, upscale restaurants, brewery floors, craft beer and wine programs, themed entertainment venues. Each venue type surfaces a different shape of the same underlying problem: knowledge management for a moving target.

Onboarding training was the first venue-level layer in production. A new hire's first two weeks — the period where most inconsistency originates — can be standardized against the same source of truth the rest of the program uses. Expanded training modules (technique drills, certification paths, well-defined progression from barback to lead) are in active development. Menu engineering analytics ship next to it as the second in-production layer, treated below in its own section.

Floor plan management is roadmapped as the next venue feature. The tools that ship with most POS systems are built by people who've never run a Friday-night service — tables that can't be split, sections that can't be rebalanced without a manager override, layouts that don't survive a private event. The opportunity is straightforward: design floor plan tools the way a bartender or floor manager actually uses them, not the way a pre-2010 enterprise software contract assumed they would.

The Bar Model

Beyond the 1982 baseline

The textbook tool for menu profitability is the Kasavana & Smith 4-quadrant matrix — Star, Plowhorse, Puzzle, Dog — published in 1982 and faithfully reimplemented by almost every menu-engineering product since. The canonical version is real and useful, and it stays available here as a toggle for like-for-like industry comparison. It also has limitations the textbook never modeled: a single global threshold pool makes a $3 shot and a $24 craft cocktail compete in the same statistical comparison, snapshot-only data hides whether a Star is rising or peaking, there's no signal for the regular who orders the same drink every Thursday, and items with too few orders to be reliable get classified anyway with no warning that the quadrant is unreliable.

The BBB Bar Model adds four bar-context refinements alongside the canonical model: per-category thresholds so cocktails, shots, beer, and wine only compete within their own group; a 28-day rolling trend velocity that distinguishes a peaking Star from a still-climbing one; a regulars-favorite flag for items where 30% or more of orders come from customers with three or more distinct visit dates — an item that looks like a Dog in raw numbers but anchors loyalty gets a tooltip warning against cutting it; and a low-confidence flag for items beneath ten orders in the analysis window. An optional toggle switches the profit axis from margin percentage to contribution per minute of prep labor — useful where a menu mixes fast pours with batched cocktails, off by default elsewhere because most cocktail prep times cluster tightly enough that labor weighting adds noise rather than signal. The point isn't to abandon a 44-year-old standard. It's to honor it by naming what it does and doesn't model, and shipping the parts the bar context actually needs.

The Hard Parts

What made this difficult

• A 44-data-point schema that doesn't become a data-entry hellscape Most cocktail databases are shallow because depth is expensive to maintain. Modeling 44 fields per recipe required a schema that supports semantic queries (find me the balance-profile sibling of this drink) without making curation prohibitive. The win was treating the recipe object as a knowledge artifact, not a row — with structured citations, technique linkage, and lineage relationships built into the data model from day one.
• Voice that survives a working bar A bar is the worst possible acoustic environment for voice input. Music, ambient noise, multi-person conversations, hard surfaces, and a bartender who can't use a wake word without breaking the social contract with the guest at the rail. The system has to listen on demand — not always — and respond on a timeline that's shorter than the time it takes to free a hand. The UX target is "the lookup happens and nobody notices."
• Recipe consistency as a first-class platform feature The institutional problem — same drink built differently by different bartenders — is solved by making the canonical spec the path of least resistance. Team menus inherit the canon. House favorites layer on top. Modifications are tracked separately rather than mutating the canonical record. The data model is the discipline.
• Cross-platform shipping with a one-developer budget Web alpha live, Android in active development, iOS scheduled to follow. Capacitor was the deliberate architecture choice: a single React codebase that ships to web, iOS, and Android with native shells around it, so every feature lands on every surface without three implementations of the same screen. The trade-off is real (some platform-specific work remains), but the alternative was shipping three apps and maintaining one.
• AI cost discipline so the free tier is actually free An AI-augmented reference can easily run a model call on every query, which would force a paywall to keep the lights on. The platform pairs prompt caching with a server-side response cache (identical Claude calls never hit the API), cutting the variable cost roughly 90 percent. Free working bartenders shouldn't be subsidizing the architecture of the cheap-to-run version.

Architecture

How it's built

React frontend, shipped to web, iOS, and Android via Capacitor. Supabase for Postgres, auth, and storage; Drizzle as the type-safe query layer over a relational schema with first-class support for recipes, ingredients, collections, team menus, and house favorites. The data model is the platform — everything else is a way to read it.

Anthropic Claude provides the language layer for natural-question retrieval and structured reasoning over the recipe corpus. Prompt caching plus a server-side response cache keep AI variable cost under control, which is the only reason the free tier survives sustained usage. Kokoro TTS handles voice output without sending audio off-device-where-possible to a paid vendor. Stripe and RevenueCat handle web and mobile monetization respectively. PostHog handles analytics, Sentry handles errors, Formspree handles contact.

Roadmap

From reference to bar program

Web alpha is live. Android is in active development. iOS is on the roadmap, scheduled to follow. The product trajectory tracks the founder's own progression through the industry: from individual bartender tool, to onboarding-training layer for new hires, to venue-level program tools (floor plans, expanded training, inventory), to a publishable house collection of original specs from the spin-off bar program.

The audience expands the same way. Working bartenders first. Bar managers and program owners next, with the venue-level features. Hospitality educators after that, as the training layer matures. Each layer is built by someone who actually worked the floor that requires it — which is the asset the rest of the category isn't shipping with.

A bar runs on knowledge. Most of that knowledge is published. Almost none of it is queryable at the speed a working service actually requires. Bartender's Black Book is the version I needed on my first night and didn't have. It's live now.