Industry: Consumer / Food & Beverage
Time: Ongoing
Project Type: iOS
Completion: V1 2026
After trying dozens of coffee journal apps, I noticed a pattern: they were either too sterile, too complex, or simply didn't make journaling enjoyable. The apps that existed were built for obsessives. Someone just starting to care about their coffee had nowhere to go. Orsa was built to fill that gap: a journal that feels like a companion, captures what actually matters, and gets out of the way.
Share and new brew screens
Built in Cursor using Swift
Eliminating the repeat
Every coffee journal app I reviewed had the same problem. Every time you pull a shot, you're reentering the same parameters: machine, grinder, grind size, temperature, even though none of those things changed from yesterday. The logging experience treats every brew like a fresh start, when the reality is that 90% of the details are the same.
Orsa's core hypothesis was simple. If the app remembers your constants, you only have to log what actually changed. That reduces logging from a two-minute data entry session to a fifteen second ritual.
The target user is not the coffee obsessive who dials in a new bean every other day. It's the intentional coffee drinker: someone who cares enough to be curious, but doesn't want to manage a spreadsheet to make a good shot. That distinction drove every scoping decision in the product.
Research
To understand where existing apps fell short, I used them. Not just reviewed them, actively logged brews in them over time to feel the friction firsthand. The findings shaped the product directly.
The most significant gap: in every app reviewed, archiving a bean was a dead end. You could see the entry but it gave you nothing actionable. No grind setting. No temperature. No starting point for the next time you bought that bean. Orsa addresses this directly: the bean detail view lets you input your best dialed-in grind and temperature for each bean, turning the archive from a graveyard into a reference tool.
I also mapped a personal user journey before touching any design tool, built a working iOS MVP using cursor, and tested with real users throughout the process.
My design decisions were developed through Claude assisted design reviews. Each one was challenged, defended, iterated, and documented based on my own judgment.
❌ Problem
When coffee drinkers open a journal app to log a shot, they're asked to re-enter the same parameters every single time. Even the ones that haven't changed.
🚫 Why it's bad for users
Repetitive input creates friction at the exact moment the app should feel effortless. Users stop logging not because they stop caring, but because the process stops being worth it.
🚫 Why it's bad for retention
An app that feels like homework gets deleted. The value of a coffee journal is in the history it builds over time, but only if users actually log consistently.
Wireframes
Making it personal
The New Brew screen is the centerpiece of the app. The primary inputs are time, yield, rating, and optional notes. Constant parameters like grind size, temperature, and drink type live behind an edit button in the top right, accessible when something actually changes, invisible when it doesn't.
The screen opens with a personalized headline: Rome is making a cortado with Atticus by June. This was a deliberate decision to make the app feel like a companion rather than a form. It surfaces your name, drink type, and current bean into a readable sentence. The same headline is used in the share feature, giving each brew an identity rather than a data export.
Rating uses four emoji-based icons: thumbs down, neutral, thumbs up, and heart—rather than a number or star scale. The goal was to make the rating feel conversational, like telling a friend how a shot went, instead of evaluative. It also makes the brew log scannable: a row of hearts reads differently than a row of 4s.
✅ How it works
The app separates two types of settings that every other app conflates.
Brew Settings holds your active session parameters, the things you might adjust during a particular brew. Bean detail holds your best dialed in settings for a specific bean. A historical record, not an active control. Once you know what works for a bean, that knowledge lives with the bean permanently. The next time you buy it, you have a starting point.
Three screens. One job each.
Brews is a chronological log of every shot pulled. Each entry shows the bean name, roaster, drink type, date, and rating icon. The bean bag photography is added when logging a new bean and it carries through to every brew entry, making the list feel like a personal record rather than a data table.
Beans organizes coffee into three states: Current, On The Shelf, and Archived. The bean detail view goes deeper with roast date, origin, tasting notes as pill tags, and the stored dial-in settings that set Orsa apart from every app in the category.
Tools house equipment and app settings on a single screen. Users visit it rarely, only to add a new piece of gear or change a preference, so combining both on one screen keeps the navigation lean without burying anything important. Tools can be marked as primary for users who own multiple grinders or machines, surfacing their default setup at a glance.
New brew, brews list, parameters, bean detail, and share screens
What I'd validate next
V1 is scoped to espresso since it's the most variable and detail dependent brew method. Validating the core logging model here before expanding to pour over, French press, and other methods keeps the product focused and the data meaningful.
A few assumptions I'd pressure test with more users:
- Whether users who change beans frequently find the Brew Settings flow fast enough, or whether they'd want a quicker bean-swap shortcut directly on the New Brew screen.
- Whether archived dial-in settings are actually discovered and used when rebuying a bean or whether users start fresh out of habit. This is the most important assumption in the product. If the archive isn't being used as a reference, the feature needs to be surfaced more actively.
- Whether the personalized headline stays delightful over hundreds of brews or becomes something users tune out over time.
The biggest open question is scope. Expanding to other brew methods is the natural V2, but only after confirming the logging model works the way it was designed for the user it was designed for.