Ruby on Rails is our default, and we will tell you why
When a client needs a custom application rather than a website, we build it in Rails. One framework, one team covering front and back, and a codebase the next developer can read without a tour.
Why Rails, specifically
Rails makes a lot of decisions for you. Where files live, how database records are modelled, how requests are routed, how tests are organized. That sounds like a constraint and it is actually the point. A developer who has never seen your application can find things in it on the first afternoon.
For a client with no in-house engineering team, that convention is a financial argument. It is what makes it possible to hand your codebase to someone else, including someone who is not us.
The second reason is operational. Rails 8 ships background jobs, caching, and websockets that run on your existing database, so a small application does not need a separate queue service and a cache server on the hosting bill from day one. Fewer moving parts is fewer things that page someone at midnight.
The third is staffing. With Hotwire we build interactive screens without standing up a separate JavaScript application in front of an API, so one team covers the whole thing instead of two teams negotiating across a contract.
When Rails is the right call, and when it is not
Good fit: a real application with real rules
Users, permissions, workflows, records other systems depend on, and logic that has to be right. This is what Rails is for.
Good fit: a small team maintaining it for years
The conventions and the testing culture mean a two-person team can hold a substantial codebase without it turning into folklore.
Not a fit: a content website
If the thing is pages, posts, and a contact form, building it in Rails means you have written a content management system nobody asked for. WordPress or a builder platform will serve you better and cost less.
Not a fit: an ordinary store
Shopify handles payments, tax, fraud, and compliance for a monthly fee. Rebuilding that in Rails is a large bill for a worse outcome unless you have a rule Shopify genuinely will not allow.
Not a fit: your team works in something else
If you have in-house developers who will own this and they write Python or .NET, building in Rails hands them a language they cannot maintain. We will say so even when it costs us the work.
Rails in a live engagement
We run the development team for Spectrum Medical Care, a Phoenix clinic, working two-week sprints against a shared backlog.
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 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.
- 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.
- How long does a typical application take to build?
-
A focused application, a simple intake system or directory, usually takes six to eight weeks from kickoff to launch. A mid-size application, a member portal with several integrations, typically runs three to four months. Larger or more complex builds stretch further. The wide range is honest: what drives it is how many edge cases your workflow has and how many integrations are involved. The requirements document from Discovery will give you a tighter estimate for your specific situation.
- What if Discovery tells us we shouldn't build?
-
Then we'll say so. The goal of Discovery is to find the right answer, not to sell you a build. If there's a tool that already does what you need, we'll name it. If the economics don't work for custom development at your scale, we'll tell you that too. A $3,500 Discovery engagement that saves you from a $50,000 build that wasn't the right fit is a good outcome. We'd rather that than the alternative.
Have something that should probably be an application?
Describe the spreadsheet, the process, or the system that is holding you back. A free consultation is enough for us to tell you whether it needs a build, an off the shelf tool, or a change to how the work flows.
Sometimes the answer is that you should not build anything.