About RailsCTO

Who built this

RailsCTO was started by Matt Sears, a Seattle-based engineer and entrepreneur with over twenty years of experience building software, leading teams, and shipping products.

Matt is currently:

• CTO at Baxtel, a research and analytics platform for the data center industry
• CEO of StaticPop, an AI strategy and engineering firm that helps companies modernize legacy systems, ship AI-powered features, and scale with confidence through fractional CTO engagements
• A mentor and long-time open source contributor on GitHub

He has been writing Ruby on Rails since 2006, and has spent most of his career in the role of founding engineer, CTO, or technical co-founder. RailsCTO is the distillation of those years into a set of defaults he would hand to any new Rails engineer joining one of his teams, whether that engineer is a human or an AI agent.

Why this project exists

When AI coding assistants like Claude Code started landing in real Rails codebases, the pattern was always the same. The code ran. The tests mostly passed. But the details were wrong in ways that accumulate quickly:

• Controllers drifted away from RESTful conventions
• ERB templates picked up inline styles and ad-hoc formatting
• New code slipped past RuboCop because nobody remembered to run it
• Security scanners only ran in CI, not during development
• Git history turned into a stream of wip and fix stuff commits

Every one of these problems has a well-understood solution. The issue is not knowing what good Rails looks like. The issue is making sure the agent applies it on every file, every time, without being reminded.

RailsCTO closes that gap. It encodes the opinions a senior Rails CTO would set on day one, then uses Claude Code's skill system to enforce them automatically whenever the agent touches a file. No prompting. No reminders. No hoping the agent remembers.

The philosophy

A few principles guide how the plugin is built:

1. Opinions over flexibility. There are a thousand ways to configure a Rails project. RailsCTO picks one good way and commits to it, so you can stop making the same small decisions over and over.
2. Automatic over manual. If a quality check can run without being asked, it should. Skills route themselves based on what files change.
3. Senior defaults. The toolchain assumes you want the same standards a careful senior engineer would hold the code to, not the bare minimum that makes CI green.
4. Human-readable everything. Commits, pull requests, and documentation are written so a non-technical stakeholder can understand what changed and why.

Get involved

RailsCTO is open source and welcomes contributions. The plugin lives at mattsears/rails-cto and the companion gem at mattsears/rails-cto-gem. Issues, pull requests, and ideas are all welcome.

If you want to reach Matt directly, the best place is through mattsears.com.