Moonbrew
The concept promised a drink chosen by the stars, and never said how the stars would choose.
- Problem
- A specialty coffee shop wanted an app that reads your birth chart and the current moon to pick your drink. What existed was two concept documents: no flows, no screens, no rules.
- Bet
- Guest access before any chart is read: a View Menu door for the people who just want coffee.
- My work
- Product designer, solo, no design review. 19 screens across 6 flows, a design system, and the recommendation engine built from scratch. No user research was conducted and nothing here was validated: every number is output, not outcome.
- Stance
- A concept is not a feature until someone writes down the rules.
Nobody had defined the core feature. I wrote the rules, and they became the product.
Moonbrew is a specialty coffee shop where your drink is chosen by the stars. The owner’s brief described the experience in prose: no wireframes, no user flows, and nothing that said which chart produces which drink.
Three problems sat inside that idea, and none of them had an answer written down.
I also designed a way out for the people who would not play along.
The spec said recommend a drink, and I had to decide what that meant
The concept described a personalized drink based on your birth chart without defining any underlying logic. Nobody asked for this deliverable. Each sign’s element sets a flavor temperament: fire bold, earth rich, air light, water deep. Each of the eight lunar phases sets an energy modifier: new moon calms, full moon amplifies. Four elements by eight phases is 32 drink and copy pairings, documented so a developer could implement them. Building the engine added roughly two weeks to my timeline. Without it the dev team had no spec to build from, and the core feature was still a concept.
AI was a workflow tool throughout the project. I used Claude to process client documentation into structured user flows, to research astrology systems and translate them into product rules for the recommendation engine, and to accelerate design system documentation: token naming, component specs, and usage guidelines. The visual design, component architecture, and all 19 screens were mine.
The eight moon states on one side, and on the other the card the customer receives: a drink, one line of copy, and the reading that produced it.
32
These 32 pairings are the part that did not exist: the rules a developer could implement, written down and handed over.
The owner assumed everyone wanted the ritual
The original onboarding had 10 screens, including two full screen animations, before anyone saw a drink. I cut it to 6: one data point per screen, with cosmic visuals that frame the input as unlocking your chart instead of filling a form. My estimate is that time to first recommendation drops from over two minutes to under 60 seconds. That compares two specs on paper, not two people using them.
I built 32 combinations and could not check a single one
The concept documents reflected the owner’s vision, and my job was to turn that ambiguity into something a team could build. So the engine shipped complete and unverified. If I did it again I would propose a two week pilot with four combinations before building all 32. Completeness without validation is the part I would handle differently.
“Personalization” means nothing without documented logic. That is product design, not just UX.
The gaps in the original spec were the most valuable part of the project. Each gap was a decision I had to make, and those decisions are what made the product shippable.