From Caffeine Addict to App Builder: How I Vibe Coded a Pour-Over Coffee App in One Afternoon

I have a problem.

Not the kind that requires an intervention. More the kind where I own three different coffee grinders, have opinions about water temperature measured in single-degree increments, and once spent 20 minutes explaining to a barista why their bloom time was too short. I am, by any clinical definition, a coffee person.

What I did not expect was to create another one.

The Origin Story (Blame the Gooseneck Kettle)

It started innocently enough. My wife asked for a gooseneck kettle for Christmas. I bought her a nice one. She made a cup. Then she made another cup. Then she asked me what the difference was between a 1:15 and a 1:17 ratio. Then she asked about water temperature. Then she started reading the roast dates on bags at the grocery store, frowning and putting them back.

I had created a monster. A wonderful, discerning, "is this single-origin?" monster.

Within a few weeks, she was weighing beans on a kitchen scale, timing her pours, and gently correcting my technique. The student had become the master. And the master, being an engineer, thought: "I should build an app for this."

A Brief History of Me vs. Swift

I've been building iOS apps for over a decade. My app TravelTimes has been in the App Store since 2014. It provides real-time commute data for Milwaukee drivers, and I still maintain it today. Most recently, I built a full production notification system for TravelTimes in a single day using Claude Code.

But let me be honest about what iOS development used to look like for me.

Before AI-assisted development, building a new feature in Swift meant weeks of work. Not because the logic was complex, but because the surface area was enormous. You'd spend a day just setting up the project structure. Another day fighting Auto Layout constraints (or, in the SwiftUI era, figuring out why your preview wasn't rendering). A few more days writing boilerplate for data models, view models, navigation, persistence, and the dozen other things a modern iOS app requires before it does anything useful.

My TravelTimes app took weeks of evenings and weekends to reach its first version. Every feature after that was measured in days, sometimes longer. The notification system I built recently was a turning point: one day, start to finish, 1,800 lines of production code. That was with Claude Code and Opus 4.5 acting as a thinking partner.

But PourCraft? PourCraft was different. PourCraft was an afternoon.

The Vibe Coding Session

I sat down on a Saturday with a clear idea, a warm cup of coffee (medium roast, 1:16, since you asked), and a detailed prompt. Not a vague prompt. A real spec: features, color palette, data model, file structure, typography choices, and design direction. I've written before about how spec-driven development is the difference between vibe coding that works and vibe coding that produces expensive garbage. This was the former.

Here's what the app needed to do:

1. Let you select a roast level (light, medium, or dark).
2. Enter your coffee weight in grams.
3. Calculate the exact water amount using the Golden Ratio.
4. Provide a step-by-step brew guide with bloom water, pour water, and temperature guidance.
5. Offer pro tips on grind size, water quality, and technique.

Simple in concept. But "simple" in iOS still means MVVM architecture, a SwiftUI color system with light and dark mode, computed properties for real-time calculation, @AppStorage for user preferences, proper typography hierarchy, and enough visual polish that my wife would actually want to use it instead of just Googling the ratio.

The spec covered all of it. And Claude Code turned that spec into a working application structure in hours, not weeks.

What Changed (and What Didn't)

Let me be clear about what AI-assisted development does and doesn't do.

It does not think for you. Every architectural decision in PourCraft was mine. The choice to use MVVM with @Observable. The decision to compute bloom water as 2x coffee weight. The color palette inspired by the actual gradient of coffee, from morning gold to dark walnut. The typography pairing of a warm serif for headers with a clean sans-serif for body text. Those are design decisions, and they require taste, context, and intent.

What AI-assisted development does is collapse the implementation timeline. The distance between "I know what I want to build" and "I have working code that does it" has shrunk from weeks to hours. That's not a small change. That's a fundamental shift in what's possible for builders who have ideas but limited time.

I think about this a lot in the context of my day job leading 250+ engineers. The bottleneck in software has never been typing speed. It's always been the gap between intent and execution. Tools like Claude Code are compressing that gap, and it changes how individuals and teams can operate.

The Coffee Nerd Details

For those who care about the brewing science (and if you've read this far, you care), here are the ratios baked into PourCraft:

Dark roast (1:15): Bold, heavy body. 20g of coffee gets 300g of water. This is for people who want their coffee to make a statement.

Medium roast (1:16): The sweet spot. Clean, balanced, and the best representation of what the bean actually tastes like. 20g of coffee, 320g of water. This is where most specialty coffee drinkers live.

Light roast (1:17): Bright, floral, sometimes tea-like. 20g of coffee, 340g of water. If you're drinking a washed Ethiopian Yirgacheffe and not using this ratio, we need to talk.

The bloom step is universal: pour double the weight of the coffee (40g for 20g of coffee) and wait 30 seconds. That releases the CO₂ trapped during roasting and sets up even extraction. Skip this step and your cup will taste uneven. I have strong feelings about this.

What I Learned (Again)

Every side project teaches me something I bring back to my teams. PourCraft reinforced a few lessons:

Specs beat vibes. A detailed prompt with clear requirements, a defined color system, and an explicit file structure produced better results than any amount of iterative prompting would have. This mirrors what I see at scale: teams that invest in clear requirements before writing code ship faster and with fewer defects.

The tools are accelerating faster than most people realize. A year ago, I was writing about trusting GenAI with more of my code. Six months ago, I was building production features in a day. Now I'm scaffolding entire applications in an afternoon. The trajectory is steep, and it rewards people who invest in learning how to work with these tools.

Side projects keep you sharp. I lead a large engineering organization, and it would be easy to let my hands-off-keyboard time grow. Building PourCraft reminded me what our developers experience daily: the friction of tooling, the joy of seeing something work, and the quiet satisfaction of shipping something real.

The Real Win

My wife uses the app. That's the whole point.

She opens it in the morning, taps her roast, adjusts the weight, and follows the brew guide. No Googling. No guessing. No asking me (which, if I'm honest, was the secondary goal all along).

She still corrects my pour technique, though. Some things even the best app can't fix.

---

The code, color palette, and full Claude Code prompt for PourCraft are available on my blog. If you're a builder with an idea and a free afternoon, I'd encourage you to try spec-driven vibe coding. The gap between "what if" and "it's on my phone" has never been smaller.

Want to discuss AI-assisted development, pour-over technique, or the ethics of turning your spouse into a coffee snob? Find me on LinkedIn or at vinny.dev.