Brew Buddy | Ryan Shea

The Experiment

Brew Buddy started as a personal product idea: a small-batch homebrewing companion for tracking active brews, browsing recipes, scaling ingredients, managing brew-day steps, and keeping pantry stock visible.

The point of the case study is not just the app. The point is the production model. I wanted to see how much product could be created when the AI implementation process was not starting from vague taste, but from a clear design system, a target architecture, and one representative dashboard screen.

What I Provided

The initial prompt gave the build just enough structure to move fast without flattening the product into a generic mobile UI.

A Figma design system for visual foundations, components, spacing, and tone.
An intended architecture for how the app should be organized.
A home dashboard screen that established the product's first real interface pattern.

That combination mattered. The design system supplied the visual grammar, the architecture supplied product logic, and the dashboard supplied an example of how the system should behave in context.

Brew Buddy intended architecture map showing login, home, recipes, batches, inventory, recipe library, tools, settings, and nested screens — The architecture map gave the build a navigation model before implementation started: login, home, recipes, batches, inventory, online recipe library, tools, settings, and the deeper screens under each area.

Original Brew Buddy home dashboard design file with Sweet Stout feature card, beers brewed, weekly deals, and latest brews — The original home dashboard design established the brand, card language, bottom navigation, featured beer moment, and latest-brews pattern.

What Got Built

The first committed prototype became a working mobile app shell with Home, Recipes, Batches, Inventory, and Settings. From there, the build expanded through quick, testable increments instead of one large handoff.

Recipe library with detailed one-gallon beer recipes, profiles, ingredient lists, mash steps, boil schedules, fermentation notes, and bottling flows.
Batch-size scaling so recipe ingredients could redraw from a one-gallon default to larger whole-gallon batches.
Mobile-native batch-size selection, moving from a web dropdown to a bottom sheet with larger tap targets.
Header navigation logic that kept top-level tabs clean and only showed back affordances on drill-in recipe screens.
Active brew cards, featured brew artwork, circular latest-brew labels, Porter Sans branding, and playful beer-label visuals.
A recipe phase timer with start, pause, reset, and done states for brew-day control.

Product Screens

By the final polish window, the prototype had enough surface area to feel like a real product: a branded home dashboard, recipe browsing, brew-day timing, active batch detail, and stock management.

Brew Buddy home dashboard with featured Sweet Stout card, yearly beer count, weekly deals, and bottom navigation — Home dashboard with featured beer artwork, year-to-date activity, promotional card, and bottom navigation.

Brew Buddy recipe list with search, beer type selector, and recipe cards — Recipe library with search, beer-type filtering, and scannable one-gallon recipe cards.

Brew Buddy brew day timing screen with phase timer, pause, reset, and done controls — Brew-day phase timer with start, pause, reset, done, and step-by-step process states.

Brew Buddy Red Fox IPA batch detail screen with recipe, stats, and ingredient sections — Active batch detail for Red Fox IPA, combining stats, recipe information, and visual beer-label identity.

Brew Buddy inventory category screen with equipment, bottles, grains, hops, and yeast — Inventory categories for equipment, packaging, grains, hops, and yeast.

Brew Buddy hops inventory detail screen with scan item and manual input actions — Hops detail view with stock levels, freshness guidance, scan action, and manual input.

The Pace

The chat log shows a realistic rapid-build window: the first Brew Buddy design-system message appears around 4:27 PM, the user direction to inspect the pages and components followed shortly after, and final-ish polish was happening around 7:32 PM.

In roughly three hours, the product moved from design-system review to a working mobile prototype with recipes, batch scaling, bottom-sheet interaction, mobile testing, Git checkpoints, brand polish, label artwork, and a brew-day timer. The late-stage polish still moved in minutes: the featured brew card update took about 1 minute 45 seconds, the Porter Sans wordmark update took under a minute, the circular latest-brews artwork took just under two minutes, and the final recipe phase timer took about 5 minutes 57 seconds from request to committed change.

That pace came from reducing ambiguity. The implementation could reuse the same product shell, data model, visual language, and interaction patterns instead of redesigning each screen from scratch.

Design system Architecture Dashboard Prototype Mobile testing Brand polish Timer controls

Testing Shaped the Product

The design system accelerated the build, but the product still improved through hands-on testing. A recipe-size selector first shipped as a freeform input, then changed to a whole-gallon dropdown, then became a bottom sheet because that pattern felt more appropriate for iOS and Android.

Device testing also exposed a real interaction bug: the recipe detail screen and recipe card handler were using the same data attribute, so taps inside the detail view were being interpreted as recipe-card selections. Renaming the internal state unblocked the picker and made the prototype usable on a phone over the local Wi-Fi server.

Brew Buddy mobile screen showing cramped recipe step text before the layout was corrected — One of the useful parts of the build was seeing issues immediately. This cramped recipe-step layout appeared during testing, then became a concrete fix instead of an abstract QA note.

Prototype Scope

The three-hour build was not intended to prove a production-complete app. It was intended to show how quickly a product can become real when the agent starts from a strong design system, a clear architecture, and one representative screen.

Some areas were deliberately left at prototype depth. Settings had not yet been visually developed, and a few forms still needed deeper validation, save states, and completion flows. Those gaps are important to name because they mark the boundary between rapid product assembly and full product hardening.

The follow-on work can still happen through the same agent workflow. Once the primary pages and flows were set, the remaining effort shifted from invention to completion: filling in settings, finishing forms, tightening edge cases, and packaging the web app and Android APK as shareable artifacts.

Why the System Worked

The design system did more than make the app look consistent. It created a shared contract between product intent and implementation.

Visual decisions were already constrained, so iteration focused on behavior and product usefulness.
Components had enough definition to support new screens without inventing a new style each time.
The architecture gave the AI a map for where features belonged and how navigation should behave.
The dashboard acted as a north star for tone: practical, warm, mobile-first, and specific to brewing.

The Takeaway

Brew Buddy shows the difference between asking AI to make an app and giving AI a product system to build from.

With a strong design system, a clear architecture, and one screen that demonstrates the intended experience, the work moved from concept to a functional, testable product surface in a very short cycle. The result was not just faster output. It was faster alignment: fewer arbitrary design choices, smaller implementation loops, and more time spent improving the actual brewing experience.

Final Artifact Package

Open mobile app Download Android APK