How to Build a SaaS with Rails 8 in 2026

Rails 8 is the best version of Rails ever released for building SaaS products. Here's the complete, no-fluff guide to going from zero to a production-ready SaaS in 2026.

This isn't a tutorial that ends at "hello world." We'll cover architecture decisions, the tech stack, authentication, payments, deployment, and the mistakes that cost founders months. Whether you're building your first SaaS or your fifth, this guide gives you the playbook.

Why Rails 8 for SaaS in 2026

Every year, someone declares Rails dead. Every year, more SaaS products launch on Rails than any other full-stack framework. Here's why Rails 8 is particularly well-suited for SaaS:

• The Solid Trifecta — Solid Queue, Solid Cache, and Solid Cable replace Redis for background jobs, caching, and WebSockets. That's one fewer service to manage, monitor, and pay for.
• SQLite is production-ready — For most SaaS products under 10,000 users, SQLite with Rails 8's multi-database support is simpler, faster, and cheaper than PostgreSQL. No database server. No connection pooling headaches. Just files on disk.
• Hotwire is mature — Turbo and Stimulus give you SPA-like interactivity without writing React. Fewer dependencies, less JavaScript, faster page loads.
• Built-in authentication — Rails 8 ships with has_secure_password and session-based auth generators. No more Devise for simple use cases.
• Kamal 2 for deployment — Zero-downtime deploys to any $5/month VPS. No Heroku. No vendor lock-in.
• AI agents love Rails — Convention over configuration means Cursor, Claude Code, and Codex understand your codebase instantly. No framework-specific patterns to explain.

The modern Rails SaaS stack

Here's what a production Rails 8 SaaS stack looks like in 2026. No over-engineering. No premature optimization.

Notice what's not in this stack: React, PostgreSQL, Redis, Kubernetes, microservices. You don't need them. Not at launch. Probably not for the first two years.

Building your SaaS: step by step

Step 1: Set up your project

Start with a fresh Rails 8 app. Skip the frameworks you don't need:

rails new my_saas \
  --database=sqlite3 \
  --css=tailwind \
  --skip-jbuilder \
  --skip-action-mailbox

This gives you a clean foundation with Tailwind CSS, SQLite, and Propshaft (the modern asset pipeline). No JavaScript bundler needed—importmaps handle ES modules natively.

Or, skip the boilerplate entirely: A SaaS starter kit like Omaship gives you authentication, payments, CI/CD, deployment config, and production infrastructure out of the box. You're building features on day one instead of configuring webpack.

Step 2: Authentication

Rails 8 finally ships with built-in authentication. Generate it:

bin/rails generate authentication

This creates a User model with has_secure_password, a Session model, login/logout controllers, and password reset flows. It's simple, secure, and you own every line of code.

For most SaaS apps, this is enough. Add OAuth later if customers demand it. Don't add Google Login on day one because "everyone does it"—track whether anyone actually asks for it.

Step 3: Your core domain

This is where you build what makes your SaaS unique. A few principles:

• Start with one model. Your SaaS probably has one core object—a Project, a Campaign, an Invoice, a Report. Build that first. Add related models as you discover them.
• Use Rails conventions. RESTful resources, standard CRUD controllers, model validations. The more conventional your code, the easier it is for AI agents (and future developers) to understand.
• Skip the service layer. Don't create app/services/ on day one. Put logic in models. Extract services when a model gets too complex—not before.
• Turbo Frames for interactivity. Need inline editing, live search, or dynamic forms? Turbo Frames let you update parts of a page without writing JavaScript.

# Generate your core resource
bin/rails generate scaffold Project name:string description:text user:references status:integer
bin/rails db:migrate

That's a working CRUD interface with forms, validations, and views in under a minute. Rails' scaffolding isn't production-ready, but it's the fastest way to get something real on screen.

Step 4: Multi-tenancy (keep it simple)

Most SaaS apps need some form of data isolation between customers. Don't reach for a multi-tenancy gem on day one. Start simple:

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_action :set_current_user

  private
    def set_current_user
      Current.user = User.find_by(id: session[:user_id])
    end
end

# app/controllers/projects_controller.rb
class ProjectsController < ApplicationController
  def index
    @projects = Current.user.projects
  end
end

Scoping queries to the current user is multi-tenancy for 90% of SaaS apps. You don't need the acts_as_tenant gem or separate schemas until you have teams, organizations, or enterprise customers.

Step 5: Payments

You have two main options in 2026:

• Stripe — The standard. Full control over billing. You handle tax compliance (or use Stripe Tax). Best for US/global SaaS.
• Lemon Squeezy / Paddle — Merchant of Record. They handle VAT, sales tax, and invoicing. You get a simpler integration but less control. Best for solo founders who don't want tax headaches.

Either way, the pattern is the same: use webhooks, not client-side callbacks, to track payment status.

# app/controllers/webhooks_controller.rb
class WebhooksController < ApplicationController
  skip_before_action :verify_authenticity_token

  def stripe
    event = Stripe::Webhook.construct_event(
      request.body.read,
      request.env["HTTP_STRIPE_SIGNATURE"],
      Rails.application.credentials.stripe[:webhook_secret]
    )

    case event.type
    when "checkout.session.completed"
      # Activate subscription
    when "customer.subscription.deleted"
      # Deactivate subscription
    end

    head :ok
  end
end

Don't build billing from scratch. A SaaS starter kit with payment integration already wired up saves you days of webhook handling, edge cases, and testing.

Step 6: Background jobs

Every SaaS needs background processing: sending emails, processing uploads, syncing data, running reports. Rails 8 makes this trivial with Solid Queue:

# app/jobs/onboarding_email_job.rb
class OnboardingEmailJob < ApplicationJob
  queue_as :default

  def perform(user)
    UserMailer.welcome(user).deliver_now
  end
end

# Call it anywhere
OnboardingEmailJob.perform_later(user)

No Redis to install. No Sidekiq license to buy. Solid Queue stores jobs in your database and processes them reliably. For most SaaS products, it's all you'll ever need.

Step 7: Testing

Don't skip tests. Especially if you're building with AI coding agents. Tests are your safety net when Claude Code refactors your codebase at 2 AM.

# test/models/project_test.rb
class ProjectTest < ActiveSupport::TestCase
  test "requires a name" do
    project = Project.new(name: nil)
    assert_not project.valid?
    assert_includes project.errors[:name], "can't be blank"
  end

  test "belongs to a user" do
    project = projects(:one)
    assert_instance_of User, project.user
  end
end

# test/controllers/projects_controller_test.rb
class ProjectsControllerTest < ActionDispatch::IntegrationTest
  test "index only shows current user projects" do
    sign_in users(:alice)
    get projects_url
    assert_response :success
    assert_select ".project", count: 2 # Alice has 2 projects
  end
end

Rails' built-in test framework (Minitest) is fast, simple, and requires zero configuration. Write model tests, controller tests, and a few system tests for critical flows (signup, login, payment).

Step 8: Deployment

This is where most founders get stuck. You have a working app locally—now what?

In 2026, the best option for most Rails SaaS apps is Kamal 2 + a $5/month VPS:

1. Get a VPS from Hetzner ($4.50/month) or DigitalOcean ($6/month)
2. Point your domain's DNS to the server
3. Configure Kamal (it ships with Rails 8)
4. Run kamal setup

That's it. Kamal handles Docker builds, zero-downtime deploys, SSL certificates (via Let's Encrypt), and rolling restarts. Subsequent deploys are just kamal deploy.

For a deeper dive, read our guide: How to Deploy a Rails 8 SaaS to Production in 2026.

Or automate everything: Omaship provisions your entire infrastructure—GitHub repo, CI/CD pipeline, secrets, deployment config, and your first deploy—with a single command. You go from git init to production in 30 seconds.

Building with AI coding agents

In 2026, the question isn't whether to use AI coding agents—it's how to use them effectively. Rails is uniquely suited for AI-assisted development because of its conventions:

• Predictable file structure — Models in app/models/, controllers in app/controllers/, views in app/views/. AI agents navigate your codebase without custom context.
• AGENTS.md — Add a project context file that tells AI agents your conventions, architectural decisions, and what to avoid. Symlink CLAUDE.md to it for tool compatibility. This multiplies their effectiveness.
• Tests as guardrails — AI agents can refactor aggressively when they can run tests to verify nothing broke.
• RESTful by default — AI agents understand REST intuitively. Custom routing patterns confuse them.

Read more: AI-Agent Optimized Rails

The 7 mistakes that kill Rails SaaS projects

1. Over-engineering from day one. You don't need microservices, GraphQL, or event sourcing for your MVP. Ship the simplest thing that works. Refactor when you have customers complaining about real problems.
2. Choosing the wrong payment provider. If you're a solo founder in the EU, use a Merchant of Record (Lemon Squeezy, Paddle). VAT compliance will eat your weekends otherwise.
3. Ignoring deployment until launch day. Deploy on day one. Even if there's nothing to see. Getting your CI/CD pipeline working early saves panic later.
4. Building features nobody asked for. Launch with one feature that solves one problem. Add features only when paying customers request them.
5. Not writing tests. "I'll add tests later" means never. Write tests as you build. When you want to sell your SaaS, buyers look at test coverage during due diligence.
6. Using React/Next.js for the frontend. Hotwire gives you 95% of the interactivity with 10% of the complexity. You don't need a separate frontend if you're building a standard SaaS (dashboards, forms, tables, notifications).
7. Not thinking about exit value. Clean code, good documentation, and automated deployment can add 2x to your exit multiple. Build like you're going to sell—even if you don't plan to.

Realistic timeline: zero to launch

A SaaS starter kit compresses weeks 1–3 into days. That's not cheating—it's leverage. The same leverage that makes founders choose Shopify over building an e-commerce platform from scratch.

Start building today

The best time to start your SaaS was last year. The second best time is today. Rails 8 gives you everything you need: a proven framework, a modern stack, and an ecosystem of tools that make solo founders dangerously productive.

You have two options:

1. Do it yourself. Follow this guide. Set up Rails 8, Tailwind, Kamal. Configure CI/CD. Wire up payments. It'll take 2–3 weeks of foundation work before you write a line of product code.
2. Start with a foundation. Use a SaaS starter kit that handles auth, payments, deployment, and CI/CD. Write product code on day one.

Either way—ship something. The Rails ecosystem has never been better for building SaaS. And in 2026, with AI coding agents at your side, a solo founder can build what used to take a team of five.