Since the launch, the site has collected some nice articles and is now #1 in Google for "why ruby" — so I guess it's doing its job. But I loved the quotes idea from the official site. They immediately answer the main question. Vladimir Dementyev suggested letting everyone share why they love Ruby. So I stole the whole idea and put it right on the first screen 🤷‍♂️

Now, on your profile, you can write a couple of sentences, and with a little help of AI it becomes a beautiful testimonial on the home page. Go try it!

Along the way, I fixed a bunch of bugs and added features some people asked for, like hiding repositories or the "Open to Work" badge. The design got a refresh too.

The community section got popular

Many of us have great open source projects, and the community page has become a nice place to see what each of us is working on and to support each other by voting on GitHub. People liked the ratings, the ability to discover contributions, to see what we give back to the community.

This part of the site started to feel like it needed its own space. A site centered on Ruby developers. A place to showcase your work.

Now it has a new home: rubycommunity.org.

Same app, same database. Sign in on one site and you're signed in on the other. But now there's a clear separation: whyruby.info for advocacy content and testimonials, rubycommunity.org for the community itself.

It now features an interactive map of Ruby developers around the world, and daily star trends showing which projects are popular right now.

More than 70 developers have already joined. I could have just scraped GitHub and added everyone myself, but that felt wrong. People should decide if they want to appear on the site. So please share this in your networks and invite your Ruby friends.

Ideas for the future

Conference talk stats, dedicated project pages with collected blog posts about them, linking users to their companies' contributions, and so on. The project is open source and built for the community to own. PRs and ideas are welcome.

A personal note

I've spent almost 20 years writing Ruby. Built all kinds of products and this past year went deep into practical AI integration.

I'm looking for work. If you're hiring or know someone who is, I'd love to chat.

Thanks for reading!
yurisidorov.com | WhyRuby.info | RubyCommunity.org

This is how I think about it now. Opinions, not rules.

What I Started With

I needed a template for my personal projects. I considered Bullet Train, especially given I was a contributor there, but it was too heavy for my use case. I usually run 3-5 apps on the same 2GB server. Other templates are either not free or don't match how I like to build things. So I made my own.

The baseline: edge Rails from main branch — upgrades are atomic and automated with Dependabot, which helps avoid painful version migrations. SQLite for everything — database plus the Solid Trifecta (Cache, Queue, Cable). Faster than Postgres, production-ready, no Redis. Devise for authentication. ULID primary keys. Avo for admin. Hotwire instead of React or Vue. Tailwind for styling.

This foundation was solid. But 2025 changed some assumptions.

AI-Native by Default

The last six months brought massive progress in AI-assisted development. That progress pushed me to finally upgrade the template.

Agents are users now

Simple rule: if a human can do it through UI, an agent should be able to do it through an API.

This isn't hypothetical anymore. Internal automation scripts need programmatic access. AI assistants need to interact with your app. Integration tools expect standard protocols.

My implementation uses MCP (Model Context Protocol) as the transport. Every feature gets a model, a controller, and an MCP tool. The development rule: "Every new feature MUST have MCP parity."

Your app becomes automatable from day one. Retrofitting this later is painful.

RubyLLM integration

I built in RubyLLM with OpenAI and Anthropic support. Chat interface with message history. Cost tracking per conversation.

AI isn't an add-on anymore. If your app will eventually need AI features — and most will — build with that assumption from the start.

The chat system is central to any AI-enabled app. You need it for internal use: auto-generating summaries, processing content, running background AI tasks. The user-facing ChatGPT-style UI is a bonus that can be disabled if you don't need it.

LLM settings

The template includes configuration for Claude Code to work well with the codebase. Style guides for Ruby, testing, migrations, views, Stimulus, Tailwind, i18n — they load automatically and keep the AI aligned with project conventions. Specialized agents for Rails-specific tasks: code-reviewer, debugger, ui-designer. Slash commands like /review-code, /commit-push-pr, /favicon for quick access to common workflows.

This structure makes AI assistance consistent. The AI reads the same conventions every time, follows the same patterns, catches the same issues.

TDD matters more now

Tests first, implementation second. Minitest + fixtures. No RSpec, no FactoryBot.

This matters more than ever with AI-assisted development. TDD gives the AI structure. Tests define what "correct" means before the AI writes anything. Without that constraint, LLMs produce plausible-looking code that drifts from what you actually need. With tests, the AI has a target to hit and immediate feedback when it misses.

Justin Searls puts it well — there's an odd paradox in the industry right now: developers experienced in TDD are both the most skeptical of AI code generation AND the most successful at building software with coding agents. The skepticism comes from caring about quality. The success comes from having techniques that let agents verify their own work. Tests give the AI a target and immediate feedback. Without them, you're just hoping the output is correct.

Obie Fernandez makes a related point: the process defines the quality of the output; the tool just accelerates whatever process you already follow. If your process is sloppy, AI makes you sloppy faster. If your process includes tests, the AI has guardrails.

Vanilla Rails

37signals open-sourcing Fizzy was a good example of this approach in production — a real SaaS built without extra layers. For the first time, developers can study actual 37signals production code, not just read blog posts about their philosophy.

The approach: fat models, thin controllers. Concerns named as adjectives (Closeable, Publishable) instead of service objects. State as records, not booleans — card.closure instead of card.closed. Database constraints over model validations where possible.

I explicitly avoid service objects, query objects, form objects, Devise, Pundit, Sidekiq, Redis, ViewComponent, GraphQL, React/Vue/npm/yarn.

Fewer patterns means less cognitive load. Rails already provides enough. And there's another reason now: simpler stacks are easier for AI to work with. Martin Alderson's recent research shows Ruby ranks #3 in token efficiency across 19 languages — right after Clojure and Julia. Less boilerplate, fewer tokens, longer context windows, lower costs.

Magic Links Instead of Passwords

The old version used Devise. I removed it.

Passwords have become obsolete for most apps. Users forget them constantly. The recovery flow sends an email anyway. So the password step can be skipped entirely — just send magic links through email.

One less thing for users to manage. One less attack surface. Simpler code.

Worth considering 2FA later for apps that need it, but for my current projects it's not necessary.

Database Decisions

UUIDv7 replaces ULID

I moved from ULID to native UUIDv7. UUIDv7 is the industry standard now — time-ordered, globally unique, and the database generates them directly. No model callbacks needed.

id: { type: :string, default: -> { "uuid7()" } }

ULID was a good idea before UUIDv7 existed. Now there's no reason to use it.

Litestream for replication

Litestream handles automatic SQLite backups to cloud storage. Zero configuration in application code. Backup and replication used to be a real concern with SQLite — Litestream solves that completely.

Frontend Decisions

Hotwire stays

Server-rendered HTML first. JavaScript as sprinkles, not foundation. Progressive enhancement — works without JS.

Tailwind CSS v4

Tailwind v4 brings CSS-first configuration now. No JavaScript config file. And a strict rule: OKLCH colors only. Modern color space, better perception.

Server-centric rendering also has an unexpected benefit: agents don't need to parse JavaScript to understand your app structure. Server-rendered HTML is readable.

Developer Experience

Quality gates

bin/ci runs Rubocop + tests + Brakeman + i18n checks. Pre-commit hooks enforce this automatically. No exceptions — must pass before every commit.

Automation beats hoping for discipline.

Documentation

Comprehensive AGENTS.md that works for humans and AI assistants alike. Moved the template closer to Rails conventions where sensible.

Madmin over Avo

Switched from Avo to Madmin. I love Adrian, but some features I consider basic (sorting, dashboard graphs) require a premium subscription. For my personal projects that barely break even, Madmin fits better. It's lighter, closer to vanilla Rails, and does what I need without extra complexity.

What I'm Working On Next

Currently adding to the template: Stripe for subscriptions and payments, Evil Martians' LaunchKit — a well-researched landing page template designed for developer tools based on their analysis of 100+ devtool sites — and user settings for preferences and notifications.

Also upgrading my existing projects with these changes. First ListenWith.Me — it doesn't have production data to worry about, so it's a good testing ground. Then WhyRuby.info, which will require some tricks: moving from DigitalOcean to Hetzner (5x cheaper) and switching IDs from ULID to UUIDv7 in the same migration.

A modern Rails template should be AI-native. Not "AI-compatible" as an afterthought — native from the start. MCP tools alongside controllers. AGENTS.md alongside README. Tests that work for humans and agents alike.

The rest is vanilla Rails and simplicity. Every choice either removes complexity or adds genuine value.

Curious if this would work for you — or what you'd do differently.