Why Rails Developers Love Miru (And How to Contribute)

If you write Rails, Miru is your kind of codebase. Not because we’re doing anything exotic. Because we’re not.

Rails 8. React 18 with TypeScript. PostgreSQL. Sidekiq for background jobs, Solid Queue where it fits, Devise for auth, Stripe for payments. No microservices. No GraphQL layer. No event-sourcing architecture that requires a PhD to debug. Just a well-structured monolith that does one thing properly: track time and send invoices.

That’s the point. Miru is a real production application, MIT-licensed, that you can read top to bottom in an afternoon. If you’re learning Rails, it’s a better teacher than most tutorials because it handles the things tutorials skip: multi-tenancy, PDF generation, Stripe webhooks, timezone handling, role-based access, and a full REST API.

---

The Stack

Here’s what you’re working with:

• Rails 8 with Hotwire where it makes sense, React where interactivity demands it
• React 18 with TypeScript for the frontend SPA experience
• PostgreSQL for everything. No Redis dependency for core features
• Tailwind CSS for styling
• RSpec for backend tests, Jest for frontend
• Docker for local development (or native if you prefer)

The architecture is boring on purpose. Boring means you can clone the repo at 9 AM and have a working dev environment by 9:30.

---

Setting Up Your Dev Environment

git clone https://github.com/saeloun/miru-web.git
cd miru-web
cp .env.example .env
docker-compose up

That’s the Docker path. If you prefer native:

bundle install
yarn install
rails db:setup
bin/dev

The README.md has the full details, but the point is: it works on the first try. We test this regularly. If the setup breaks, we treat it as a P0 bug because contributor experience matters more than most features.

---

Where to Start Contributing

We label issues. The labels mean something.

good first issue means exactly what it says. These are scoped, explained, and usually include hints about which files to touch. If you’ve never contributed to an open source project before, start here. We review these PRs fast because we know you’re waiting.

help wanted is for experienced contributors. These are real features or refactors that need someone with Rails chops. Multi-step work, sometimes spanning models and controllers and views.

bug is always open season. If you find a bug and fix it, we’ll merge it. Bug fixes get the fastest reviews.

---

What We Look For in PRs

Keep it simple. Seriously.

• One thing per PR. Don’t fix a bug, refactor a service, and add a feature in the same PR. We can’t review that.
• Tests. Backend changes need RSpec coverage. Frontend changes need Jest. If you’re fixing a bug, write the test that would have caught it.
• No magic. If your solution requires a comment explaining why it works, it’s probably too clever. We’d rather have ten readable lines than three clever ones.
• Follow the patterns. Look at how existing controllers, services, and components are structured. Match the style. Consistency matters more than personal preference.

We review PRs within a couple of days, usually faster. If we request changes, it’s not personal. We just want the codebase to stay approachable for the next contributor.

---

Why This Matters

Open source time tracking shouldn’t be a side project. It should be production-grade software that companies actually run their billing on. That’s what Miru is. Every contribution makes it better for the 500+ teams already using it.

If you write Rails, you already know most of this codebase. Clone it. Pick an issue. Ship a PR. We’ll be watching for it.

GitHub: saeloun/miru-web