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.

Boilerplate, starter kit, template: the same thing

These three names describe the same idea, and which one people use mostly depends on where they came from. "Boilerplate" is the established term in the Rails world. "Starter kit" travelled over from the JavaScript ecosystem. "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 it

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 flipping. 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 and editable prompt templates.
• Onboarding, notifications, referrals, support inbox, SEO, JSON API.

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 it is for

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.