The production-ready Ruby on Rails boilerplate

LaunchKit is a Ruby on Rails boilerplate: a Rails 8 application that already contains the parts every product needs before it can charge anybody, so the first thing you write is the thing you are actually building.

This page is the index of how each of those parts works here, why it was built that way, and what you would have to decide for yourself if you started from rails new.

Rails boilerplate, starter kit, template: the same thing

Searching for a Ruby on Rails boilerplate, a Rails boilerplate, a Ruby on Rails starter kit or a Rails starter kit turns up the same handful of products, because the four phrases name one thing. Which one you type mostly depends on where you came from: "boilerplate" is the established term in the Rails world, "starter kit" travelled over from the JavaScript ecosystem, and "template" usually means something thinner, closer to a scaffold than to a working application.

The distinction that actually matters is not the word. It is whether the thing you are handed is a running application with tests, or a folder of files you still have to assemble. A boilerplate you cannot deploy on the first afternoon is a tutorial with extra steps.

What is in the boilerplate, feature by feature

Each of these has its own page, and each one explains the framework primitive it leans on as well as the decision made here.

• Authentication. Rails 8's own generator, not Devise. Sessions are database rows, so revoking one is a DELETE rather than a token blacklist.
• Social sign-in. OmniAuth across ten providers behind a single registry, including the account linking rules that decide whether a returning user gets their account or a duplicate.
• Stripe billing. Checkout, subscriptions, one-time payments, coupons, and webhooks whose signatures are actually verified.
• Billing portal. Stripe's own, so card updates and invoices are not yours to build.
• Feature flags. Every optional module can be switched off from the admin, and a disabled one answers 404 rather than rendering half of itself.
• Admin console. Users, revenue, content, settings, and a setup wizard that writes credentials.
• AI layer. Streamed completions over Turbo Streams with no Redis, editable prompt templates, and two fallbacks for the two different ways a provider call ends early.
• Onboarding. A multistep flow where each step is a form object and the order lives in a committed file, so composing it produces a diff rather than runtime state.
• Notifications. In-app and real-time over Turbo Streams, carried by Solid Cable on Postgres, with the unread badge live on every page of the signed-in shell.
• JSON API. ActionController::API inside the same application, stateless, bearer token only, and the whole namespace answers 404 when the module is switched off.
• Referrals, support inbox, SEO.

Why not just rails new

Because rails new is not the part that takes the time. Rails gives you the framework in seconds. What it does not give you is the fifty decisions that sit between a new application and one that can take money from a stranger on the internet.

Confirmation emails and what an unconfirmed user may do. A password reset link that dies once used. Stripe webhooks that survive a retry and a replay. An admin that does not become a security hole. A feature you can turn off without deploying. Each is a small decision. Together they are the weeks between starting and shipping, and none of them is the thing you are actually trying to build.

Who this boilerplate is for, and what it assumes

Someone who has already built this once and does not want to build it again. The pages below are written for that person: they assume you know Rails, and they spend their time on the decisions rather than on the syntax.

If you have never wired Stripe webhooks or an OAuth callback before, they work as a guide to doing it yourself. That is deliberate. A boilerplate whose author cannot explain what is inside it is not worth buying.