Five Things I Learned Building a Coffee Tasting App (Again)
By Raymond Brigleb
Back in 2006, we built a coffee rating website for a 24-hour Rails Day competition. It was simple: rate your coffee, remember what you liked. Back then, it felt novel—one of the first of its kind.

Fast forward to today, and I’m rebuilding it at Cuppin.com. What started as a fun way to use a domain we’d been sitting on became an education in how dramatically coffee culture has evolved. Here’s the thing: we’ve been designing for coffee companies this whole time at Needmore. But working with coffee businesses versus being deep in home brewing culture? Totally different worlds.
Here are five lessons from the journey (so far).
1. Coffee Got Serious While I Wasn’t Looking
The first thing that hit me? I don’t know modern coffee anymore.
Well, that’s not quite right. I know the business side—Needmore works almost exclusively with coffee clients! But the home brewing side? That evolved into something less recognizable while I was busy designing for industry players.
When I was deepest in home coffee culture 25 years ago, your brewing options were limited: get an espresso machine, make a French press, or do a basic pour-over. That was pretty much it.
Today it’s a different world entirely.
People are treating their water with specific mineral profiles. They’re measuring extraction yields. They’re following brewing recipes with the precision of laboratory protocols. I’ve had AeroPress coffee that rivaled good espresso—something I wouldn’t have believed possible back in the day.
There are entire websites dedicated to collecting recipes for individual brewing methods. The level of precision and care that home brewers bring now makes my old “coffee snob” days look positively casual.
Lesson: Your domain expertise has a half-life. What you knew deeply can become outdated faster than you think.
2. Capture Everything That Matters (Not Just What You Think Matters)
When I started rebuilding the service, I thought I knew what to track: coffee name, roaster, score, maybe some origin details and tasting notes. Simple, right?
The first feedback I got: "Can you add recipes?"
It was so obvious in hindsight. I subscribe to a monthly espresso service, and every shipment includes the roaster’s specific recipe—dose, yield, time, temperature. This tells you how to pull a shot that tastes how the roaster intended. If someone’s recording a coffee they loved but not how they made it, the data is incomplete. What if they found a modification that made it even better?
I was asking for the brewing method, but that tells you almost nothing. It's like asking what kitchen you cooked in instead of what recipe you followed.
Lesson: Listen to early users obsessively. They'll show you the gaps between what you built and what actually matters.
3. Maybe Skip the Beta
This might be controversial, but I’m starting to think the whole “closed beta with invite codes” thing was unnecessary friction.
My reasoning for the beta was classic developer paranoia: What if the data models change? What if I need to restructure everything? Better to limit the damage, right?
But here’s what actually happened: I haven’t had to make any destructive changes. Modern migration systems handle schema evolution gracefully. The friction of invite codes probably cost me more in lost users than any data migration headaches would have.
Lesson: Perfect is the enemy of launched. Your infrastructure is probably more resilient than your anxiety believes.
4. Coffee Data Is a Fascinating Mess
This is where things get a bit philosophical. How much structure should you impose versus letting things be freeform? Should you be able to write a recipe like you write a blog post... or should every ingredient and step be its own series of inputs?
Take time input for recipe steps, as an example. If someone types “90” for a step duration, do they mean 90 seconds or 1:30? (They're the same, but people think differently.) I built a parser that handles both, plus things like “1:90” (which becomes 2:30... just for good measure).
Or processing methods—at first, I had one single grouping. Then I realized coffee can have multiple: washed at origin, then decaffeinated later. Is decaf just a toggle, or another processing method? (It's another processing method.)
The really tricky part is collaborative data. If User A adds a coffee but only knows the roaster, can User B add the origin info later? What if they disagree? I ended up with a "first person locks the field" system—not perfect, but it prevents chaos, and allows the data to improve over time organically.
Lesson: Real-world data is messy. Embrace the mess, but create smart constraints to keep it useful.
5. Switching Costs Are Real (And That’s Okay)
Here’s the sobering truth: There are tons of coffee apps now. It's not 2006 anymore.
People have notebooks full of reviews. They’ve paid for AeroPress recipe apps. They have communities on Reddit or Discord where they share their experiences. Even if Cuppin is “better,” is it better enough to justify moving years of data?
This isn’t defeatist—it’s liberating. Instead of trying to be everything for everyone, I can focus on building exactly what I want. The people who find value in that specific vision will come.
Lesson: You can’t compete with switching costs. You can only offer something different enough that starting fresh feels worth it.
The Meta-Lesson
Building Cuppin (again) taught me that the best side projects exist at the intersection of three things:
- Something you used to know (provides foundation)
- Something that’s changed (creates learning opportunity)
- Something you personally need (ensures you'll keep going)
The gap between my 2009 coffee knowledge and 2024 coffee culture forced me to become a beginner again. That discomfort? That’s where the interesting design decisions live.
Your Cup Awaits
Cuppin’ isn’t fully launched yet, but it’s getting there. Every feature I add teaches me something new about how coffee culture has evolved—and how much more there is to learn.
Despite what I said earlier, you do presently need an invite code! Visit cuppin.com and use NEEDMORE as your code to get an early peek.
Because if I’ve learned anything, it’s that the best insights come from the people actually using the thing.