
February 2, 2026
Inspired by Onur Ozer’s talk at RubyConf Thailand (Jan 2026)
There’s a specific kind of talk that quietly stays with you long after the conference ends. Not because it introduced a new framework, or a clever optimization, but because it articulated something many of us feel while building products with Ruby on Rails — especially outside big teams and big budgets.
Onur Ozer’s “Breaking Rules to Ship Products: A Beginner’s Rails Journey”, presented at RubyConf Thailand 2026, is one of those talks.
This article isn’t a recap of slides. It’s a reflection on why this story matters, and what it tells us about building products with Rails today.
Starting without a technical background
Onur doesn’t come from a traditional engineering background. His career spans marketing agencies, startups, and large corporations like American Express and Mastercard. When he decided to “build a SaaS,” the question wasn’t how to scale Rails to millions, but something far more fundamental:
How hard could this be?
That framing is important. Many Rails stories assume a baseline of deep technical experience. This one starts from curiosity, not mastery — which makes the lessons far more relatable.
The beginner questions we all forget
Early in the journey, the questions are simple but disorienting:
- Ruby vs Rails — what’s the difference, really?
- What is a background job, and when do I need one?
- What should I test?
- Why does everyone talk about service objects?
These aren’t theoretical questions. They’re the questions that decide whether someone keeps going or quietly abandons a project.
Rails has answers to all of them — but not always in a way that’s obvious to beginners.
When “The Rails Way” becomes a constraint
One of the most interesting tensions in the talk is the relationship with The Rails Way.
Tutorials, books, and blog posts are invaluable when you’re learning. But they also create an invisible pressure: to do things correctly, idiomatically, and future-proofedly — even when you don’t yet have a future to protect.
Examples from the talk include:
- Elaborate associations that model every possible interaction
- Overuse of abstractions like service objects
- Strong opinions about database design (STI, enums, schemas)
None of these are wrong. But building too much too early is.
Rails conventions are powerful — but they’re not neutral. They come with cognitive and maintenance costs that beginners feel first.
“Bad ideas” that turned out to be fine
A recurring theme in the talk is breaking rules that are often presented as absolutes:
- “STI is bad” → sometimes it’s perfectly adequate
- “Marketing sites must be separate” → a Rails app can serve both
- “Self-hosting is the way” → it can also be a massive distraction

What matters isn’t whether these choices are architecturally pure — it’s whether they help you ship.
Rails is flexible enough to allow these shortcuts. The danger isn’t using them; it’s refusing to reconsider them later.
Shipping changes everything
The most important slide in the deck isn’t about Rails at all. It’s a screenshot of a payment:
$29.00 succeeded
That moment reframes the entire project.
Once someone pays:
- your code stops being an experiment
- your abstractions gain real weight
- your priorities change
The product isn’t “done,” but it’s real. And reality is the fastest teacher.
Marketing, SEO, and the long slog
Shipping doesn’t end the journey — it begins a slower, quieter phase:
- keyword research
- content creation
- talking to users
- incremental SEO gains
There’s no spike. No overnight success. Just gradual, compounding progress.
This part of the story is especially valuable for developers. Rails makes it easy to build. It doesn’t magically make people care. That requires persistence, not polish.
Vitamins vs painkillers
One of the sharper insights from the talk is the distinction between:
- Vitamins — features that feel good to build
- Painkillers — features users actually need
Rails makes vitamins dangerously attractive. It’s easy to add features, refactor endlessly, and chase elegance. Shipping forces a harder question:
Does this solve a real problem for someone today?
Code as liability
Another subtle but important idea: code is liability.
Every line written today is something you’ll have to understand, maintain, or delete later. Rails’ productivity can hide this cost — until it doesn’t.
Building less isn’t laziness. It’s respect for future you.
Why this talk matters to the Ruby community
This talk lands at an interesting moment for Rails.
Rails is mature. Stable. Boring — in the best sense. That makes it ideal for people who want to ship products, not just systems.
Onur’s journey reminds us that:
- Rails is still a fantastic choice for solo builders
- perfection is not a prerequisite for success
- shipping is the only real curriculum
These aren’t new ideas. But they’re easy to forget.
Final thought
The advice that frames the talk also frames this article:
- Build as little as possible
- Commit for the long term
- Talk to customers
Rails doesn’t demand that you follow every rule perfectly. It asks that you keep moving.
And sometimes, breaking the rules is exactly how you get there.
Talk: “Breaking Rules to Ship Products: A Beginner’s Rails Journey” — RubyConf Thailand 2026
