What prevented you from creating a PWA using pure HTML, CSS and WebAudio for text to speech? Would have given you instant feedback, hot reload, no deployment - maybe an idea for your next trip.
You are absolutely right. A PWA would probably have given us a much lighter workflow. Instant feedback, hot reload, no deployment cycle, no TestFlight delay. From a purely practical perspective, it would have been more efficient.
But the truth is we wanted to build a native iOS app. It was less about optimizing the workflow and more about the excitement of trying something new. I had never built a native iOS app before, and part of the motivation was simply curiosity and the challenge.
We also wanted to test the limits of Claude Code. That part honestly surprised us. We never had to roll back once. Every issue we ran into we were able to solve remotely through vibecoding. The entire development cycle happened over SSH from a phone, and it held up better than I expected.
Another important reason was offline usage. We generated the audio files asynchronously using ElevenLabs TTS and bundled them into the app so everything worked fully offline. We did not want to depend on a server connection while traveling. Especially in Japan, where you are constantly moving through stations, underground areas, or rural zones, reliability matters.
So yes, a PWA would have been technically cleaner. But this project was driven more by exploration and constraints than by optimizing for the perfect setup. And in that sense, going native was part of the fun.
Now I am working on another app, a multiplayer party game to play with friends, and for that I am exploring a PWA approach using Firebase. And honestly, for this kind of project it works really well.
The development flow is much smoother. Instant updates, no App Store review cycle, easy real time features with Firebase, and the ability to test quickly with friends just by sharing a link. For a social, fast iteration type of product, it makes a lot of sense.
If it gains traction and people actually use it consistently, then I would consider migrating it to native iOS and Android later. Starting as a PWA feels like the right balance between speed, flexibility, and validating the idea before committing to the overhead of native apps.
How much of the final app would have been different if you'd built it the traditional way at your desk in Spain? My guess is 40% of the features you shipped only existed because you were IN Japan using it. Context shapes product more than we admit.
The UI part was a bit challenging because we did not have immediate feedback. Every change required deploying a new build to TestFlight and waiting around 15 minutes before we could actually test it. That delay made fine tuning layouts and small interface details slower than it would have been sitting at a desk with instant previews.
That said, testing the phrases in real situations was invaluable. We could try them in restaurants, shops, or train stations, and even ask locals how something should be said more naturally. That real world loop shaped the app much more than instant UI feedback would have.
The app probably contains some translation imperfections, and we are fully aware of that. It was built by us and for us. The goal was not linguistic perfection but usefulness. And for our own trip, it genuinely worked and made things easier.
Interesting workflow.
What prevented you from creating a PWA using pure HTML, CSS and WebAudio for text to speech? Would have given you instant feedback, hot reload, no deployment - maybe an idea for your next trip.
You are absolutely right. A PWA would probably have given us a much lighter workflow. Instant feedback, hot reload, no deployment cycle, no TestFlight delay. From a purely practical perspective, it would have been more efficient.
But the truth is we wanted to build a native iOS app. It was less about optimizing the workflow and more about the excitement of trying something new. I had never built a native iOS app before, and part of the motivation was simply curiosity and the challenge.
We also wanted to test the limits of Claude Code. That part honestly surprised us. We never had to roll back once. Every issue we ran into we were able to solve remotely through vibecoding. The entire development cycle happened over SSH from a phone, and it held up better than I expected.
Another important reason was offline usage. We generated the audio files asynchronously using ElevenLabs TTS and bundled them into the app so everything worked fully offline. We did not want to depend on a server connection while traveling. Especially in Japan, where you are constantly moving through stations, underground areas, or rural zones, reliability matters.
So yes, a PWA would have been technically cleaner. But this project was driven more by exploration and constraints than by optimizing for the perfect setup. And in that sense, going native was part of the fun.
Now I am working on another app, a multiplayer party game to play with friends, and for that I am exploring a PWA approach using Firebase. And honestly, for this kind of project it works really well.
The development flow is much smoother. Instant updates, no App Store review cycle, easy real time features with Firebase, and the ability to test quickly with friends just by sharing a link. For a social, fast iteration type of product, it makes a lot of sense.
If it gains traction and people actually use it consistently, then I would consider migrating it to native iOS and Android later. Starting as a PWA feels like the right balance between speed, flexibility, and validating the idea before committing to the overhead of native apps.
How much of the final app would have been different if you'd built it the traditional way at your desk in Spain? My guess is 40% of the features you shipped only existed because you were IN Japan using it. Context shapes product more than we admit.
The UI part was a bit challenging because we did not have immediate feedback. Every change required deploying a new build to TestFlight and waiting around 15 minutes before we could actually test it. That delay made fine tuning layouts and small interface details slower than it would have been sitting at a desk with instant previews.
That said, testing the phrases in real situations was invaluable. We could try them in restaurants, shops, or train stations, and even ask locals how something should be said more naturally. That real world loop shaped the app much more than instant UI feedback would have.
The app probably contains some translation imperfections, and we are fully aware of that. It was built by us and for us. The goal was not linguistic perfection but usefulness. And for our own trip, it genuinely worked and made things easier.