This is the first article in a 5-part series about creating, testing, and publishing Ruby gems. I’ll walk you through my real experience building Calendlyr, an API wrapper for Calendly that’s been running in production for 5 years.
The perception that holds us back
Think about the gems you use every day. Devise. Sidekiq. Stripe. Rails itself.
They’re massive. Complex. Years of development, hundreds of contributors. And when you think about “creating a gem”, your brain goes straight there. That scale. That complexity.
And of course, you tell yourself: “Why would I build a gem?”
It’s a mental trap. We associate “gem” with “huge, sophisticated project” because those are the ones we use daily. But reality is very different.
My “aha” moment
I’ve always been quite curious about what happens under the hood. I like cracking open gems, reading other people’s code, understanding how the magic works. Sometimes out of curiosity, sometimes because I’m debugging and have no choice.
But the moment that changed my perspective was much simpler than you’d expect.
I was watching a tutorial. Someone was building a gem live that separated even and odd numbers. That’s it. Literally that. A function that takes an array and returns two: evens on one side, odds on the other.
And they turned it into a gem.
Coming from tools like Devise and Stripe, it blew my mind. You can build a gem for something that basic? Seriously?
The answer is yes. And that changes everything.
What is a gem, really?
A gem is packaged Ruby code. Nothing more. Nothing less.
It doesn’t need to be a framework. It doesn’t need thousands of lines. It doesn’t need to solve a problem nobody has solved before. It’s simply a way to distribute Ruby code so that others (or yourself) can reuse it.
That’s it.
Types of gems out there
To remove even more of the mystery, let’s look at the most common types:
Engines and frameworks — The “big ones”. Devise, Sidekiq, RailsAdmin. They add complete functionality to your application. They have generators, migrations, views. They’re impressive, but they’re the exception, not the rule.
API wrappers — They wrap a REST API in Ruby objects so you don’t have to deal with HTTP directly. Stripe-ruby, Octokit, or my own Calendlyr. They’re simpler than they look.
Utilities — Tools you use in development. Pry, Byebug, Rubocop. They solve a specific problem and they do it well.
CLI tools — Gems that run from the terminal. Rails itself starts with a command. Bundler is a gem.
Small libraries — The even/odd gem from that tutorial. One function, one utility, something that makes your life easier. They’re the best way in.
Most gems out there aren’t Devise. They’re small utilities that someone needed, packaged, and shared.
What the hell would I build a gem for
This was exactly my question. And the answer I found is brutally simple:
Whatever you want.
Got a helper you keep copying from project to project? Gem. Need to integrate an external API and there’s no wrapper? Gem. Want to extract business logic you keep repeating? Gem. Want to learn how the Ruby ecosystem works from the inside? Gem.
In my case, I needed to integrate Calendly into a project. I could have written the HTTP calls directly in my code. But I saw Chris Oliver (creator of GoRails and Pay) working live on a fork of a gem called Vultr, and I thought: “I can do the same with Calendly.”
I was lucky to have my CTO (markets) as a sparring partner for technical decisions. Someone to bounce ideas off, who encouraged me to keep going with the project. If you have someone like that on your team, rely on them. It makes a huge difference.
That’s how Calendlyr was born. An API wrapper with zero external dependencies that’s been running for 5 years. It’s not Devise. It doesn’t try to be. And that’s perfectly fine.
The barrier isn’t technical
If you know how to write a Ruby class, you know enough to create a gem.
The barrier is psychological. It’s believing that “gem” means “complex project”. It’s thinking you need to be an expert. It’s the fear of publishing something and having nobody use it.
Let me tell you a secret: I published Calendlyr, shared it on blogs and Rails community chats, and practically nothing happened. A few GitHub stars, a couple of followers, no memorable interactions.
And you know what? It doesn’t matter. The gem exists, it works, and I learned a ton building it.
You don’t need anyone’s permission to create a gem. You don’t need it to be perfect. You don’t need thousands of downloads. You need to start.
In the next article, we’ll pop the hood and look at the anatomy of a gem. What files it contains, how it’s structured, and why bundle gem name is the best starting point. See you there.