What this is
The stack DHH spent 2024 evangelising and that 37signals shipped HEY and Basecamp’s newer apps on. No React. No JSON API. No SPA. Just server-rendered HTML, Hotwire for interactivity, SQLite for everything (data, jobs, cache, cable). The simplest way to ship a real product in 2026, and arguably the fastest in dev loop and runtime.
SEO advantage
Because every page is server-rendered HTML with content present on first paint, this stack has the best possible SEO posture. Google indexes the actual content, not a hydrated shell. No SSR/CSR juggling. No ‘render the route to an empty <div id="app"> and pray the bot waits for JavaScript’ fragility. A real win for marketing pages and content-heavy apps.
When to pick this stack
- You want the smallest possible team-and-tooling footprint.
- The product is mostly forms-and-pages with a sprinkle of real-time updates (the 95% of products that aren’t Figma or Linear).
- SEO matters and you don’t want to fight a JS framework over it.
What we’d swap
- SQLite → Postgres: only if you’ll eventually need cross-region replication, partitioning, or features SQLite genuinely lacks (full-text isn’t one of them, SQLite’s FTS5 is excellent).
- Add React via Vite: only when a single page genuinely needs SPA UX. See Rails + React + Vite.
Common gotchas
- SQLite likes a single writer. The Rails 8 SQLite adapter handles WAL mode and concurrent reads, but if you’re doing serious write throughput (>100/s sustained), benchmark first.
- Backup strategy matters: litestream streaming the SQLite file to S3 is the canonical setup.