# A vanilla Rails stack is all you need 

![A vanilla Rails stack is all you need ](https://autodiscover.victorkeenan.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NiwicHVyIjoiYmxvYl9pZCJ9fQ==--72b4e506f6e50fe4583c14db8887784b416dfcda/vanilla-rails-stack-is-all-you-need.jpg)

## A Simple Rails Stack Goes a Long Way

Modern web development often feels like an arms race: more layers, more tools, more abstractions. But if you’re starting a new Rails app today, there’s a strong argument for doing the opposite.

Keep it simple. Stay close to the defaults. Let Rails do its job.

### The Case for Staying Close to Rails

There’s a persistent idea that Rails alone isn’t enough—that “serious” applications eventually require extra architectural layers, frontend frameworks, or a constellation of dependencies.

But in practice, a well-used, mostly vanilla Rails stack can take you surprisingly far. The framework already includes solutions for routing, persistence, background jobs, realtime updates, and rendering. Adding more should be a deliberate decision, not a reflex.

The more you add, the more you carry:
- More dependencies to upgrade
- More concepts for the team to learn
- More moving parts to debug
- More long-term maintenance risk

New tools always make their benefits obvious. Their costs tend to show up later.

### Default to Less

When starting out, treat every new dependency as something to justify—not assume.

- Keep your Gemfile as close to the default as possible  
- Avoid pulling in frontend frameworks unless you truly need them  
- Resist introducing service layers, command objects, or complex patterns by default  

Rails already gives you a cohesive, integrated system. Splitting it apart prematurely often adds indirection without real benefit.

### You Probably Don’t Need a Heavy Frontend

It’s tempting to reach for React, Vue, or a full SPA architecture. But for many applications, that’s solving problems you don’t yet have.

Server-rendered HTML is:
- Fast enough
- Easier to reason about
- Simpler to deploy
- More maintainable over time

Modern Rails tools like Hotwire let you build dynamic interfaces without abandoning the server-centric model. That means less JavaScript, fewer build steps, and a tighter feedback loop.

### Embrace the Server Again

Rendering on the server isn’t a step backward—it’s a simplification.

Templates, helpers, and partials give you everything needed to build rich interfaces. They’re also approachable: designers and developers can collaborate directly in the same layer without bridging entirely separate systems.

You don’t need a JSON API just to render your own UI. Skip the extra hop unless it’s genuinely required.

## Avoid the Build Step When You Can

A growing number of modern stacks rely heavily on bundling, compiling, and transforming assets. But that complexity is optional.

Instead:
- Use import maps for JavaScript
- Lean on modern browser capabilities
- Serve assets directly over HTTP/2

Shipping many small files is no longer a problem. Complexity in your toolchain often is.

### Rethink Infrastructure Add-ons

It’s easy to assume you need a fleet of supporting services from day one.

But Rails increasingly provides built-in alternatives:

- Database-backed caching instead of external stores  
- Built-in job processing instead of separate queues  
- Native realtime features without extra infrastructure  

Each external system you avoid is one less thing to operate, monitor, and scale.

### Optimize for Longevity

A simpler stack has a powerful advantage: it ages well.

When you stay close to Rails conventions:
- New developers onboard faster  
- Old knowledge remains relevant  
- Upgrades are smoother  
- The system stays understandable  

Contrast that with stacks built from many independent pieces—each evolving on its own timeline.

### Complexity Should Be Earned

None of this means “never add anything.” It means: don’t add it too early.

If a problem truly demands a new tool, you’ll know:
- You’ve hit real limitations
- The tradeoffs are clear
- The added complexity pays for itself

Until then, optimize for clarity and momentum.

### A Simple Rule of Thumb

Start with Rails. Stay close to it as long as possible.

If your stack feels almost boring—minimal dependencies, server-rendered views, straightforward models—that’s not a weakness.

That’s a sign you’re letting the framework do what it was designed to do: help you build and ship software with less friction.

And most of the time, that’s more than enough.