Yukisaki

Discover where to go from the time you have, not a destination. Yukisaki finds towns reachable from your station and turns spare time into a small, unexpected trip—sometimes decided by dice.

Comment

Inspiration

My wife once said to me, “Even on days when we have nothing planned, I want to be able to just head out somewhere. It would be great if I could instantly see which stations are within 30 minutes of our nearest station. Could you make an app for that?”

That was the entire reason I started building Yukisaki. Really, that was it.

What it does

Users enter their nearest station—or any station they like—and choose a travel time. Yukisaki then shows stations they can reach in roughly that amount of time, together with nearby places to explore.

Rather than showing only famous landmarks, Yukisaki tries to surface smaller, less obvious places that might be interesting during an aimless walk.

Users can also let a dice roll decide where to go. This felt naturally connected to the original idea of spontaneously heading out on a day with no plans.

I later expanded this into Gachi Dice Journey, which turns long-distance travel into a chain of dice rolls. After each roll, the selected station becomes the starting point for the next one. Users can even choose their nearest station as both the start and finish, creating an entirely unexpected day trip that eventually brings them home.

How it makes money

Searching and everyday dice rolls are free. Two things are paid, both through RevenueCat:

  • Hardcore Challenge Ticket: a single-use consumable (¥200). Gachi Dice Journey has three levels. Light (a day trip) and Medium (might turn into an overnight) are free; Hardcore means at least one night away, and each Hardcore journey uses one ticket. In Hardcore, the app checks your location before each roll, so the trip has to happen for real.
  • Yukisaki Plus: a monthly or yearly subscription. On the map, 15 and 30 minutes are free; Plus unlocks every time band up to 180 minutes and lets you stack them all at once.

A consumable fits an app that many people open for a specific outing rather than every day, and the subscription is for people who plan outings often.

How we built it

Yukisaki originally existed as a web app built with vanilla HTML, JavaScript, and CSS. I used that version as the foundation and rebuilt the experience in React Native.

A mobile app can preserve an ongoing journey across sessions more naturally than the original web version, so I added features that fit that environment, including persistent Gachi Dice journeys and records of past outings.

During development, I used Claude Fable 5, Opus 5, and Sonnet 5, as well as Codex 5.6 Sol, Terra, and Luna. I switched between them depending on whether I was exploring a design, implementing a feature, reviewing code, or running simulations.

Challenges we ran into

The most difficult feature was Gachi Dice Journey.

At every stage, the app must generate six possible destinations from the user’s current station. However, the choices could not simply move the user closer to the final destination every time. That would make the experience feel like an inefficient navigation app rather than a game.

At the same time, making the choices completely random could create an endless or impossible journey. The route needed detours, surprises, and occasional bad luck while still making eventual progress possible.

I ran multiple Codex 5.6 Luna agents in parallel and repeatedly simulated Gachi Dice journeys. I used the results to adjust the candidate-selection rules until the journeys produced more interesting stories instead of simply calculating the shortest route.

Accomplishments that we're proud of

First and most importantly, I was able to publish an app that solves a real problem my wife had.

I am also proud that Yukisaki uses a smartphone to help people step away from their smartphones. The app gives the real world a new point of view, then encourages users to go outside and experience it for themselves.

Yukisaki is not intended to keep people inside the app. Its purpose is to create a reason to visit a station or town they might otherwise never have considered.

What we learned

This was my first iOS app, so I learned how much more operational work is involved compared with publishing a web app. Building the product was only one part of the process; signing, store information, privacy declarations, review requirements, in-app purchases, and release management all had to be completed as well.

I normally work as a backend engineer and do not design or implement user interfaces professionally. Building Yukisaki made me appreciate how every small UI detail, transition, and animation exists because someone deliberately designed and implemented it.

As a software engineer, I already understood that anything moving on a screen must be implemented in code. But creating all those details myself made that fact feel much more real.

I also learned something when I released the web version: many people reacted as if Yukisaki had been made specifically for them. It reminded me that there are still many small inconveniences—and many moments of boredom—in everyday life that software can transform.

What's next for Yukisaki

I want Yukisaki to give people who feel that everyday life is inconvenient or repetitive more ways to enjoy the towns around them.

The app is already good at creating a reason to visit an unfamiliar station or town. The next question is what happens after the user arrives.

I want to explore that part in Yukisaki’s own style: giving users only an approximate idea instead of a complete, optimized itinerary. Yukisaki should not tell people exactly what to do. It should provide just enough of a prompt for them to start walking, look around, and discover something for themselves.

Awards we're entering

HAMM Award (Help Apps Make Money): The ticket ledger lives on our backend (Cloudflare D1) and is reconciled against RevenueCat, so a ticket survives a reinstall or a new phone and is used exactly once when a journey starts. Getting this right was harder than I expected. My first design looked up each purchase by its store transaction ID, but the RevenueCat v2 API cannot look purchases up that way. I rebuilt reconciliation to sync the customer's full purchase list and match it locally, which made recovering stuck purchases automatic and re-syncs safe to repeat.

RevenueCat Design Award: Please look at the dice roll with haptics, the Challenge Ticket that gets stamped when it's issued, every element rising in with a 40 ms staggered delay, and the Liquid Glass tab bar.

Built With

Share this project:

Updates

Submission history