Ruby is where we are deepest
It is the language behind Ruby on Rails, which is our default for custom applications. It is also what we reach for when a client needs a data migration, a reporting job, or glue between two systems that were never meant to meet.
What Ruby is good at
Ruby was designed around how the code reads rather than how the machine prefers it. In practice that means a business rule written in Ruby usually looks like a sentence describing the business rule, which matters a great deal when somebody has to change it in three years.
The community also has an unusually strong testing habit. Test suites are expected rather than negotiated, and that is what makes it safe to upgrade, refactor, or hand a codebase to a new team.
Applications, through Rails
Almost all of our Ruby application work runs on Rails. Portals, internal tools, integrations, and commerce on Spree.
Data migrations
Moving records between systems with the checks, dry runs, and reversibility that keep a migration from becoming a very bad afternoon.
Scripts and scheduled jobs
Report generation, reconciliation between two systems, bulk updates, and the small automations that quietly save someone a weekly afternoon.
Maintaining inherited Ruby
Version upgrades, dependency updates, and adding tests to a codebase that arrived without any.
The honest trade-offs
Strength: changes stay cheap
Readable code plus a real test suite is what keeps year three of an application from costing more than year one. That is the whole argument, and it is a financial one.
Strength: batteries included
Most things a business application needs already exist as a well-maintained library, so you are not paying us to invent authentication or background processing.
Trade-off: raw speed per operation
Ruby is slower than a compiled language at pure computation. For business applications the bottleneck is almost always the database and the network instead, and recent Ruby versions have closed much of the gap. If your workload is genuinely compute-heavy, that is a real reason to choose something else.
Trade-off: it is not the language of data science
Model training, scientific computing, and heavy analysis belong in Python. We will say so rather than bending Ruby around a job it is not built for.
Trade-off: your team may not write it
If you have in-house developers who will own the result, their language wins over our preference. A codebase nobody on staff can read is a liability no matter how elegant it is.
Ruby in production, every sprint
We run the development team for Spectrum Medical Care on a Ruby on Rails stack, with a backlog that moves every two weeks.
Running the development team for a Phoenix healthcare clinic
Questions we get about this
- Why Ruby on Rails as the default?
-
We've shipped Rails applications that are still running a decade later. That history matters when you're making a long-term technology investment. Rails ships fast, scales reasonably for most of what our clients need, and stays maintainable as teams change over time. It's not the right tool for everything. When it isn't, we'll say so.
- Is Ruby too slow for our application?
-
Almost certainly not. Ruby is slower than a compiled language at raw computation, but for business applications the time goes to the database and the network, not the language. Recent Ruby versions have also closed a lot of that gap.
Ruby runs some of the largest sites on the internet. If your workload is genuinely compute-heavy, such as model training or scientific processing, that is a real reason to choose a different tool, and we will say so.
- Can you take over a custom application someone else built?
-
Sometimes. We need read access to the codebase first. Once we've looked at what's there, we can scope what it would take to stabilize it and continue the work. Sometimes the right path is to keep going on what exists. Sometimes it's a rebuild. We'll tell you which, and why, before any work starts.
- Is it hard to hire Ruby on Rails developers?
-
Less than the internet suggests. Rails runs some of the largest sites on the web and has a deep, experienced community, so the people available tend to be senior rather than plentiful.
The more useful point is that Rails conventions make a codebase legible. A competent developer who has never seen your application can find their way around it quickly, which is what actually determines whether you can replace us.
Have a Ruby codebase that needs a home?
Whether it is a Rails application whose developer moved on or a new build you are still scoping, a free consultation will tell you what shape it is in and what it would take to keep it healthy.