01 / Product direction
One core behavior.
A smaller release.
My early brief made recording the primary behavior. Instead of several competing actions, I asked for one core loop: record a drink, keep a visual memory, and return to it later. Maps, calendar entries and public discovery would grow from that record. This gave the product a clear center while leaving people different ways to revisit what they had saved.
The exploration was broader than the first release: recipes, cellar management and at-home drinking were among the early concepts. I kept those directions outside 1.0 and focused on recording, discovery and personal memories.
Early scope explorations Outside the 1.0 release
A reference, not a release feature.
Recipes, cellar and at-home drinking were part of the broader exploration. The first release did not include these directions.
This preserved Figma Make export documents an early recipe concept. It is not evidence of a feature built and later removed.
02 / Design decision
Let the record lead.
Let the map follow.
A map makes drinking history tangible, but requiring a venue would make it dictate every record. I specified that a check-in could be saved without selecting a place. The record remains the primary object; location and visibility determine which additional surfaces can use it. Keeping a memory, putting it on a map and sharing it are separate decisions.
A place adds context.
It does not grant permission to record.
One drink.
One record.
The memory is always kept.
Board & Memories
A personal memory in every case
My Map
Needs usable coordinates
Public discovery
Stays out of public discovery
Public Map
Needs both location and public visibility
That choice appears in the form: nearby venues are suggestions, and saving without one remains valid. Drink name is required; rating and richer category details are optional. Detail cards can be skipped and reopened. Records with usable coordinates can appear on the map; those without coordinates still belong in the board, Memories and their detail view. The tradeoff is less structured data in exchange for a lighter record.
Public visibility makes a record eligible for discovery, rather than automatically placing it in every feed. I also required seeded venues to be distinguished from public activity: a listed place should not imply that somebody has posted there. My review criteria covered meaning as well as presence—where a record appears, whose activity it represents, and what remains private.
Two views, different meanings.
View full source artwork (opens in a new tab)03 / Design decision
Make the center a collection,
not just a shortcut.
Creation gains the context of a collection. The tradeoff is one more tap.
- 01Imagery makes previous records visible.
- 02New record stays within reach.
The early IA treated the center entry as a direct route to a check-in form. During the native migration, I explicitly changed that destination to the monthly Sticker Board, with “New record” inside the collection. Looking back, this connects creation to something accumulated. The tradeoff is an extra tap for someone who only wants to log quickly; it is a product judgment to evaluate, not a measured improvement.
“The 5-tab IA is now correct, but the UI still looks like a rough scaffold.”My feedback to Codex · May 2026
Figma Make provided the visual reference, while Expo React Native and native components became the product implementation. I told Codex that the five-tab architecture was correct but the interface still looked like a rough scaffold. My feedback specified softer surfaces, lighter typography and a floating tab bar, with a less blocky center control. I limited the next pass to the shared visual foundation before refining individual screens.
The board foregrounds drink imagery and compact labels; Memories offers calendar and timeline views of the same records. I can evaluate those as two different retrieval paths—recognizing an image or remembering a date—without claiming that either has been proven faster. The original photo remains available when subject cutout fails. The collection still depends on the quality of the photograph and on keeping its labels readable.
04 / AI-assisted build & acceptance
System uncertainty.
Human intent.
I used Codex to implement the app and checked the resulting experience on device. Tapping a map marker sometimes flashed a preview and then closed it, or only worked after panning. The important distinction was between a delayed photo and a cancelled choice. My feedback identified the preview opening before its selection was cleared.
Keep the choice.
The same place is still present. Updating data should not undo the tap.
- Selection
- Preserved
- Preview
- Open
- Camera
- Unchanged
I required selection to survive an ordinary refresh, even when marker objects were replaced.
Preserve intent,
not a timer.
I defined the acceptance rule: a preview should open immediately, photos can arrive later, and an ordinary refresh must preserve the selected place. I rejected an arbitrary delay that would hide the symptom. Codex corrected how selection survived data updates. The design criterion was continuity of intent, not simply a screen that rendered without crashing.
Recover the map.
Keep the context.
Physical-iPhone QA exposed a second issue: a temporary map-loading error could leave the map permanently non-interactive. I first asked whether the selection fix had caused it; Codex traced it to earlier behavior. I then required recoverable errors to preserve the map, camera and selection. Temporary system uncertainty should not look like a new user decision.
The recorded checks covered refreshes, marker replacement, intentional deselection, confirmed removal and loading recovery. I subsequently confirmed that the problems were fixed and requested a small improvement to the remaining preview hesitation. That final polish still needed device confirmation. The evidence supports an acceptance loop, without a claimed speed gain.
05 / Release & reflection
From a design direction
to an app people can use.
OneSip reached the App Store as version 1.0 on August 22, 2026. I owned the product definition, interaction and visual design, AI-assisted development, QA and release as the Solo Product Designer & Builder. The delivered product connects a drink record to discovery, a personal map and visual memories.
This project taught me to define acceptance through what survives change: a selected place during refresh, or a saved memory while its photo is processed. After launch, feedback about sparse maps also put venue coverage on the agenda. That is post-release content work, separate from the features shipped in 1.0. I would evaluate it alongside the extra step through the board and whether public visibility is understood. Those are questions for the next iteration, not outcomes already demonstrated.