Why We Rewrote Our Entire Software in Rails After 12 Years

We looked at 12 years of code and decided to start over. Not patch it. Not refactor it. Build the whole thing again from scratch in a different language.

Node.js and Angular out. Ruby on Rails in.

A full rewrite of Micepad — starting from event check-in and badge printing, we now have a full suite that includes an event app as well.

If you've ever considered rewriting your product, you already know what everyone says: don't. Joel Spolsky called it the single worst strategic mistake a software company can make. For most companies, he's right.

But sometimes staying is the worse decision.

How we got here

We started Micepad in 2013. Back then, Node.js was the exciting new thing. Angular was the obvious frontend choice. The JavaScript ecosystem was booming and writing the same language on both sides, frontend and backend, felt like a cheat code.

So that's what we built on. And it worked. For years, it worked well enough. Google Cloud wrote a case study about us, praising our Kubernetes setup and how we cut infrastructure costs by 60%. The product did its job.

The codebase, though, was slowly becoming the thing that held us back.

Twelve years of code accumulation does something to a product. It's not one big disaster. It's a thousand small ones. A workaround from 2017 that nobody remembers why it exists. A frontend component that's three major versions behind. Dependencies that haven't been maintained since their creator moved on.

The frontend and backend were separate worlds. Two codebases. Two deployment pipelines. Two sets of problems. Managing a frontend team and a backend team for a small startup drains you in ways that don't show up on a balance sheet. Every feature needed coordination between both sides. Every bug meant figuring out which side owned it. Every sprint, we spent more time negotiating between teams than building for customers.

Then COVID nearly killed us

In 2020, in-person events stopped overnight. Our entire business, check-in software for physical events, became irrelevant in a matter of weeks.

We nearly died.

We did what everyone did: pivoted. Built virtual event features, then hybrid event features when in-person partially came back. It kept the company alive, but it also added layers of complexity to a codebase that was never designed for any of it.

When events came back fully, slowly, unevenly, I looked at our codebase and saw it for what it was. A system that had survived, but hadn't evolved. It had just accumulated massively.

We'd been paying tech debt instead of shipping features for years. Every quarter, we'd promise ourselves: this is the quarter we catch up. This is the quarter we start building new things. The debt always won. There was always another framework upgrade to wrestle with, another dependency to patch, another piece of infrastructure to babysit.

We were spending so much time keeping the lights on that we had almost nothing left for the work that actually mattered.

The breaking point

A customer asked for a lead capture app. Exhibitors scanning attendee badges at their booth to collect contacts. It should've been a week of work. When we scoped it, the answer came back: three months. Not because it was complex. Because of how the frontend and backend were coupled. Touching one side meant retesting the other. Adding a field in the API meant coordinating changes across both codebases, both teams, both deployment pipelines.

That's when I realized the architecture wasn't just slowing us down. It was deciding what we could and couldn't build. We weren't saying no to customers because of strategy. We were saying no because the codebase couldn't move.

On top of that, our infrastructure had grown into something we could barely justify. We'd adopted Kubernetes because that's what you do when you want to be taken seriously. But for a small team, it was overkill. The maintenance cost, the deployment complexity, the 2am debugging sessions across containers. Some months the infrastructure cost more to run than the product was bringing in.

I looked at it honestly: we had a frontend and backend that required separate teams to maintain, and an infrastructure bill that made no sense for our size.

That was when I stopped asking "how do we fix this?" and started asking "what would we build if we started over today?"

The answer wasn't even close to what we had.

Why Rails

If you'd told me five years ago I'd rewrite a product in Ruby on Rails, a framework people were already writing obituaries for, I would've laughed.

But while the tech world chased the next shiny thing, Rails got quietly, boringly good at running real businesses. Shopify processes billions in transactions on it. GitHub serves virtually every developer on the planet with it. And the thing that gets me: both started as small teams. DHH built Basecamp with a handful of people. GitHub was four guys. Rails was always a framework that let small teams punch way above their weight. That mattered to me more than any benchmark.

Garry Tan, Y Combinator's CEO, put it this way recently:

"I think people are sleeping a bit on how much Ruby on Rails + Claude Code is a crazy unlock — I mean Rails was designed for people who love syntactic sugar, and LLMs are sugar fiends."

He's not just talking. He personally writes 10,000 lines of Rails code a week with Claude Code for YC's internal tools.

That quote landed because I was already living it. The decision came down to a few things:

One developer, full-stack. This was the biggest one. Rails with Hotwire eliminated the frontend/backend split that was killing us. No more separate frontend codebase. No more coordinating two teams. One developer, one codebase. The hiring problem vanished because I stopped needing frontend and backend specialists. I just needed good developers.

Convention over configuration. Rails has opinions about how things should be built. After a decade of Node.js where every developer made their own architectural choices, I was done with "flexibility." I wanted a framework that told you how to do things. Follow the convention. Ship the feature.

No more Kubernetes. DHH has been saying for years that most companies don't need Kubernetes, and he's right. He pulled Basecamp and HEY off the cloud entirely. Rails 8 ships with Solid Cable, Solid Queue, and Solid Cache, built-in replacements for Redis, Sidekiq, and the background job infrastructure we were running across containers. We went from a multi-container mess to a single server that just works. Our infrastructure cost dropped and deployment became boring. Boring is good.

AI writes great Rails code. This is the Garry Tan point, and it's real. Rails has been around 20 years with strong conventions. AI models have seen millions of Rails codebases. When I use Claude Code to build a feature in Rails, it gets it right the first time more often than not. With our old Node.js + Angular setup, the AI would hallucinate patterns that didn't match our architecture. Rails conventions are AI conventions now.

The pain of rewriting

I'm not going to pretend it was clean. It hurt.

Rewriting a product that customers are actively using is like rebuilding a plane while it's flying. You're maintaining the old system, migrating data, building the new one, and trying not to break anything for the people paying you. All at the same time.

There's a specific kind of grief in deleting code you spent years building. Modules that survived the COVID era. Features you remember shipping at 3am, right before a customer's event. Even when you know the new version is better, watching the old one go is heavier than you'd expect.

The hardest part wasn't the technical work. It was the months where we couldn't ship new features because every hour went into the migration. Customers don't see your rewrite. They see a product that stopped improving. "We're investing in the future" doesn't land when they're asking for something today.

But the cost of not rewriting is invisible, and that's why people stay too long. You don't see the features you didn't build because the codebase was too fragile. You don't count the developers who left because they didn't want to maintain a legacy codebase. You don't measure the sales you lost because the product couldn't move fast enough.

That invisible cost was higher than the rewrite. It just took me 12 years to see it clearly.

What's different now

We ship fast. That's it. That's the whole thing.

Features that used to take weeks of coordination between frontend and backend teams now get built by one person in days. The self-serve signup, the new pricing page, the free tier, all shipped faster than anything we'd done in the previous five years combined.

We went from "contact us for a quote" to "start free in 30 seconds." That transition from sales-led to self-serve was only possible because Rails let a small team move at the speed the business needed.

But the bigger shift is that we're agent-native now.

I don't mean that as a buzzword. Our development workflow is built around AI. Claude Code understands our Rails codebase because Rails conventions are predictable and well-documented across millions of open-source projects. I describe a feature in plain English, and the AI generates code that fits our architecture. Conventional Rails code that follows the same structure as every other file in the project.

This changes what a small team can do. We're building things we wouldn't have attempted before because the cost was too high. The gap between what I imagined Micepad could be and what we could actually build has closed. That's what the rewrite gave us.

The real reason I'm writing this

For most of Micepad's life, we were a sales-led company running on legacy code. Surviving instead of building. The company nearly died during COVID. The codebase was drowning in tech debt. I couldn't hire the developers I needed.

The rewrite turned Micepad into the company I always wanted to build. Agent-native, self-serve, and fast enough to keep up with where event technology is going.

That's only possible because we bet on Rails.