Case study
Japan Voyage: three sites, four languages, one Rails app on Ruby master
Our own product: one Rails 8.1 codebase that serves three sites in four languages, with iOS and Android apps, running in production on the development branch of Ruby.
The product
Japan Voyage helps people find golf partners, ski partners and travel ideas in Japan. It is three public sites, golf, snow and travel, plus the portal that ties them together. All of them come from a single Rails application. It also serves this website.
We built it, and we run it. Everything on this page is a decision we made and still live with.
The stack
- Rails 8.1 with Hotwire (Turbo and Stimulus) and ViewComponent. No separate JavaScript front end.
- One codebase, three sites. The subdomain picks the site; colours, venues and copy follow from it. Shared features like chat, events and profiles are written once.
- Four languages: English, Japanese, Finnish and Traditional Chinese, with path-based locale URLs and hreflang on every page.
- iOS and Android apps built with Hotwire Native, reusing the web screens, with push notifications through Firebase.
- Real-time chat over ActionCable.
- SQLite in production, the Falcon web server, and Kamal for deploys straight from CI.
- Data: more than 2,000 golf courses and more than 500 travel destinations, kept in version-controlled seed files with tooling that checks each edit.
Running on Ruby master
Japan Voyage runs in production on Ruby master, the nightly build of Ruby's development branch, not a released version. We do it on purpose: it shows us how the next Ruby release will affect a real Rails application months before our clients upgrade.
It is not free. On 26 August 2026 a change in Ruby master moved the fiber scheduler to a new interface version. The io-event gem, which Falcon depends on, still implemented the old one, so every write under the scheduler spun without making progress. Workers burned 100% CPU, never reported healthy, and five deploys in a row failed.
We found the cause, upgraded io-event to the release that supports the new interface rather than pinning Ruby, and wrote a smoke test that boots a hello-world app under Falcon on a given image. It now tells a Ruby or Falcon boot failure apart from an application failure in under a minute. The same kind of problem is what our upgrade work finds for clients, before it reaches production.
We wrote up the earlier move from Ruby 3.4 to 4.0 in a blog post (in Japanese).
What carries over to client work
- Multilingual Rails done properly: locale routing, hreflang, sitemaps, translation workflow
- One codebase for web, iOS and Android with Hotwire Native
- Small-team operations: SQLite, Kamal, CI that deploys on merge
- Early warning on Ruby and Rails changes, from running ahead of them
Tell us about your project
Send a few lines about your application and what you need. We reply within two business days, in English or Japanese, with next steps and a rough estimate.
Services
Rails and Ruby upgrades
Move an old Rails application to current Rails and Ruby step by step, without a rewrite and without stopping feature work. We start with a fixed-price roadmap.
Upgrade roadmap: $1,500
Ruby on Rails development
Small, well-defined Rails work at a fixed price: a first version of a new application, one feature, a fix, or monthly maintenance.
Feature or fix: from $1,000
Code audit and second opinion
An outside review of your Rails codebase, or of a proposal you have been given, written up in plain language so you can decide what to do next.
Second opinion: $500
JRuby and Java integration
Run Rails on the JVM, call Java libraries from Ruby, or embed Ruby in a Java system. We contribute to JRuby itself, so we can fix the problem where it starts.
JRuby assessment: from $2,000
Spinel: compile Ruby to native binaries
Spinel is Matz's new ahead-of-time compiler: it turns a subset of Ruby into a standalone native binary. We contribute to it, and we can tell you whether your code fits.
Feasibility study: $2,000