Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
Founders weighing tech stacks for 2025 are revisiting Ruby on Rails, with many arguing it remains one of the fastest ways to ship a web product thanks to its batteries‑included approach, strong conventions, and mature ecosystem. Critics point to hiring challenges, long‑term maintainability issues from “magic” metaprogramming, and concerns about community leadership, and instead favor stacks like Next.js/TypeScript, Django, Laravel, Go, or Elixir depending on the domain. The prevailing view is that Rails is still an excellent fit for small teams validating ideas quickly—especially for classic SaaS-style web apps—so long as you account for talent availability and future scaling needs.
Overall sentiment on Rails for 2025 startups
- Many would still choose Rails, especially for early-stage, small teams or solo founders.
- Others prefer Next.js/TypeScript, Django, Laravel, Go, or .NET, often driven by existing skills or hiring concerns.
- Several argue the tech stack rarely determines startup success; familiarity and speed of execution matter more.
Speed, productivity, and “boring tech”
- Strong consensus that Rails is extremely productive: “batteries included” (auth, jobs, mailing, admin-ish features, Hotwire, etc.) lets teams focus on business logic.
- Compared to Go or bare Node/Express, Rails reduces boilerplate (migrations, job queues, scaffolding) and is said to accelerate MVPs dramatically, especially combined with LLM-based code assistants.
- Some group Rails with other “boring, battle-tested” stacks (Django, Laravel, Symfony) that are favored for reliability over novelty.
Maintainability, “magic,” and long-term cost
- Critics point to heavy metaprogramming and “magic” (e.g., invisible bindings, callbacks, DSLs) that can make debugging and refactoring difficult, especially when developers over-optimize for DRY.
- Some report legacy Rails apps full of hard-to-diagnose bugs or stuck on old versions.
- Others counter that vanilla Rails upgrades are manageable; problems usually come from poor architecture or 3rd‑party libraries, not the framework itself. Community norms have shifted away from clever metaprogramming toward clearer code.
Performance and scaling
- Rails is acknowledged as slower than Go/Rust and similar to or slightly faster than Python, but many argue most web apps are I/O-bound and can scale Rails with hardware and database tuning.
- Examples of long-lived, high-traffic Rails monoliths suggest practical scalability; performance issues are said to concentrate at the database layer.
- Some still prefer Go/Rust/Elixir for infrastructure, extreme performance, or concurrency-heavy workloads.
Ecosystem, hiring, and community
- Rails benefits from a mature ecosystem (gems, Rack, job systems, deployment tools like Kamal) and good documentation.
- Several commenters say hiring experienced Ruby/Rails developers is now harder than for Node/Python/PHP, and worry this may worsen.
- Others downplay this, saying good generalists can learn Rails quickly.
Governance, leadership, and politics
- A visible minority is wary of the framework’s de facto leader and sponsoring company, citing controversial public views and centralized influence (e.g., decisions about TypeScript support).
- Some see this as a meaningful reason not to adopt Rails; others either ignore it or consider the community and broader maintainer set sufficient to mitigate individual influence.
When not to choose Rails
- Advised against when:
- You already have deep expertise in another suitable stack.
- You need tight integration with Python-heavy ML stacks.
- You expect very high performance/infra demands better served by Go/Rust/Elixir.
- Hiring in your region for Ruby is clearly difficult.