Every SaaS project I've started begins the same way: wire up Devise, figure out JWT, build Stripe service objects, set up i18n, configure Docker, write CI, sort out deployment. That's two or three days of work that produces zero product value.
So I built tarik — a GitHub Template that ships all of it wired together and ready to extend.
What's in the box
Rails 8 in API mode, Next.js 16 App Router, Devise + devise-jwt with Authorization: Bearer tokens (no cookies — any HTTP client works), Stripe integrated through service objects, English and Japanese i18n from the first commit, Docker Compose for local Postgres and Redis, GitHub Actions CI, and Railway deployment config.
There's also a demo mode. Set DEMO_MODE=true, seed the database, and you can explore the full subscription flow without touching Stripe at all.
Why service objects for payments
The stripe gem directly — not the pay abstraction. All Stripe logic lives under app/services/payments/:
app/services/
├── payment_service.rb # facade
└── payments/
├── charge_service.rb
├── subscription_service.rb
└── webhook_service.rb
Nothing in controllers or models. This makes the code easy to test, easy to reason about, and — when the time comes — easy to swap out. Which brings me to the next thing.
The PAY.JP angle
tarik ships a full migration guide for moving from Stripe to PAY.JP. PAY.JP is widely used in Japan's Ruby bootcamp and startup ecosystem, and the service object pattern means the swap
is contained: no controller or model changes needed for the core migration. The guide covers all nine steps with ready-to-apply code.
The AI agent angle
This is the part I'm most interested in. tarik ships an AGENTS.md that documents the architecture, conventions, and hard rules in a format designed for AI coding agents. When you hand a codebase to Claude, GPT, or any other agent, it re-derives the same decisions every time — Devise vs Rodauth, where business logic lives, how auth flows. Every token spent on that is a token not spent on your product.
With tarik, the decisions are already made and documented. Your agent — and you — start at product, not at scaffolding.
Getting started
Click Use this template on the tarik repo, then:
git clone https://github.com/your-username/your-project
cd your-project
bin/setup
bin/dev
bin/setup handles dependencies, .env creation, Docker services, and database setup.
It's idempotent — safe to run more than once.
Frontend at localhost:3000, API at localhost:3001.
---
Would love feedback from anyone who's built something similar or has opinions on the architecture choices —
especially the JWT-in-localStorage vs HttpOnly-cookie tradeoff, which I've documented in docs/auth.md along with instructions for switching if you need SSR-protected pages.
