· Jesse Edwards · Case Studies · 3 min read
How I Chose the Framework and Deployment for RenovationRoute
Why I stuck with Rails in 2026 instead of chasing the latest frontend flavor.

Welcome to the world of frontend development. Frontend frameworks remind me of a person who can’t make plans or hold a commitment. I have worked all of the place; Embedded to edge IoT. To this day you can still use C/C++, yes I like Rust more, but how long did that take? I remember seeing The C Programming Language by Brian Kernighan and Dennis Ritchie, some 40 years later C/C++ is still used. Microcontroller bugs were painful, but at least you could usually reproduce them and dig in. Some IoT problems I would argue involve distributed system that were also difficult, but I still would take those issues over frontend frameworks any day.
Web frontend frameworks? They change every couple years, each one promising to be the final answer. I started with PHP. Then Angular to React to Vue to Svelte to Solid. Every switch means rewriting chunks of UI, retraining muscle memory, and dealing with a new crop of quirky bugs. Frontend frameworks have me up the wall, and I really just want something that works, that will not change next week. I will say they have been getting better, but still. If you need to deliver content over the web, you basically have three realistic paths:
Full client side apps (Next.js, Remix, Nuxt, etc.) Great for marketing sites or consumer products where SEO and interactivity matter a lot. But you end up managing a lot of moving parts: API layer, auth sync, hydration issues, bundle size fights.
Low level or newer stacks (Phoenix/Elixir, Laravel, Django, NestJS, Go + HTMX, etc.) All solid in their own way. Some offer amazing concurrency or type safety. But hiring is harder, ecosystem smaller, and you’re often building things Rails gives you for free.
Rails with Hotwire (Turbo + Stimulus) Server renders HTML, sprinkles JS only where needed. No separate API for most flows, no context switching between frontend and backend concerns.
I am a python fanboy myself, but I picked #3.
Why Rails?
- I can onboard myself or a future hire in days, not weeks.
- Boilerplate features included; auth, payments, background jobs, mailing, admin panels all have mature gems.
- Hotwire has Turbo and Stimulus. Turbo avoids full page reloads and makes navigation feel instant. Stimulus handles the small bits of JavaScript I actually need.
- One language, one mental model Ruby everywhere. No bouncing between TypeScript and Ruby contexts.
I’m not saying Rails is perfect or that it will outlive us all. But in 2026 it’s a fast way for a solo founder, or small team, to ship a complex, transactional app without drowning in complexity. Once I settled on Rails, deployment became straightforward. Single reserved EC2 instance + Kamal for zero downtime deploys. PostgreSQL and Redis running alongside initially, split out later.
Focusing on actual business problem helping homeowners and contractors trust each other again is the more difficult part. Sometimes the “boring” choice is the competitive advantage.


