You’ve settled on Ruby on Rails for your store, or you’re close to it, and the search results for “rails ecommerce” are mostly GitHub starter repos and gem directories, plus a few roundups that compare Solidus against Spree as though picking one finishes the job. Picking a framework is the easy part. The harder question is who will own and patch that codebase three years from now, and underneath it sits an earlier one: whether a Rails build was the right call at all next to running the store on Shopify. This piece walks through the three options you actually have (an open-source Rails commerce framework, a fully custom Rails store, or Shopify) and how to tell which one fits your business.

Solidus and Spree are both maintained open-source commerce engines for Rails, and Solidus started life as a fork of Spree, created to give stores a more stable foundation to build on. Either one hands you a working data model on day one, with products, carts, and orders already defined and a checkout flow that already handles the dull parts. That’s a real head start, because writing that layer yourself takes a long time and most of it is work no customer notices when it goes right.

The roundups mostly stop there, which is a shame, because that’s where the tradeoff begins. Adopting Solidus or Spree means adopting someone else’s Rails application, with its own models, its own conventions, and its own tree of gem dependencies, and then building your store inside it. Every Rails upgrade you do now waits on the framework supporting the new version, and every gem the framework depends on is one more thing that can hold you back. Licensing deserves a look as well: Monterail’s comparison flags that Spree’s multi-store features carry an AGPL license, so read those terms carefully before you plan several storefronts on it.

Every commerce framework assumes a shape for how a store sells. A product has a price, a customer adds it to a cart, the cart becomes an order, and the order ships. Plenty of businesses fit that shape closely enough that they never notice it. The ones that don’t usually find out in the same few places: pricing that depends on who’s buying or when, limited stock that has to be allocated across customers, or a checkout that has to do something the standard flow never anticipated.

On a hosted platform, hitting that wall means hunting for an app or a workaround. With a Rails framework you have a better option, at least at first, because you can open the framework’s code and change it. The cost shows up later. Every change you make to the framework’s models or checkout is a change you carry through every framework release after that, so each upgrade turns into a merge between their new version and your modifications, on top of your own business logic. After a few years of that you’re maintaining the framework’s code as well as your own, and most of the time it saved you at launch has gone into upgrades.

A custom build drops the inherited layer entirely. The storefront, cart, and checkout are application code written for this business from the first commit, so there’s no framework model to fight and no gem tree you didn’t choose. When a pricing rule changes, you change the code that implements that rule, and nothing upstream has an opinion about it.

You give up the head start a framework would have given you, though, and the upgrades and patching become yours to handle. We handle that side the same way we handle any Rails application in production. There’s a Rails backend with a real data layer in PostgreSQL and Redis, continuous integration and a staging environment before anything reaches customers, a stated automated test coverage standard, and major Rails and Ruby upgrades delivered with zero downtime. We’ve kept Rails applications running in production for more than ten years, across ecommerce, automotive, publishing, and SaaS, and our Ruby on Rails page goes into that practice in more detail, including the coverage standard itself.

Wine Spies is the clearest example we have. It’s a wine retailer whose storefront, cart, and checkout run on Ruby on Rails, with React on the front end, a React Native app, PostgreSQL and Redis underneath, an RSpec suite, and deployment on Render. The part that matters most for this question is The Locker, which the case study describes as a first-in-industry capability.

A feature nobody else in the industry had is, almost by definition, one that no standard commerce order model was designed around. Because the store is application code we can change, building The Locker meant writing what the business needed, and nobody had to negotiate with someone else’s checkout to get it. The length of that partnership and what it did for the business are on the Wine Spies case study.

For a lot of stores, Rails is the wrong answer. If you sell a standard catalog at ordinary prices, there’s no allocation or membership mechanic at the center of the business, and launching this quarter matters more to you than owning the stack, Shopify is the right call. A Rails build of any kind, framework or custom, would be overbuilding, since you’d be paying to own and maintain software that a hosted platform already runs well.

Shopify itself started as a Rails application, so choosing it over a Rails build is a smaller break than it sounds. What you’re really deciding is whether your business needs to own the code or whether renting a very good version of it is enough. Our post on website ecommerce development makes the fuller platform-versus-custom argument, including where the platform ceiling usually shows up, so if you’re still at that stage, start there.

Three questions, asked in order, sort most stores into one of the three options.

1. Does your pricing, allocation, and checkout logic fit a standard commerce data model? If it does, stop here and use Shopify, because nothing about a Rails build will pay for itself.
2. If it doesn’t, does it fit a Rails commerce framework closely enough that you’d rarely touch the framework’s own code? If so, Solidus or Spree gets you to launch faster than a custom build, and upgrades stay manageable because you’re mostly upgrading their code instead of untangling your changes from it.
3. If your logic fights the framework’s models too, you’re building custom. The real cost of a custom Rails store is owning its upgrade cadence for as long as it runs, so decide who does that before you plan the launch.

Write down your catalog, how checkout works today, and the one rule about how you sell that doesn’t fit a template. That’s usually enough to tell which of the three options you need. If you’re starting fresh, our new products page covers how we approach a new build, and if you already have a Rails commerce codebase, whether it runs on Solidus, Spree, or something written in-house, our existing products page covers how we take one over. Or book an intro call and bring those three things with you.