Why Rails Developers Love Miru (And How to Contribute)

Why Rails Developers Love Miru (And How to Contribute) is simple: if a model hurts customers, we do not copy it.

Miru is built on Rails 8 and React 18. Here’s why the stack matters, how to set up your dev environment, and where to start contributing. We write from operating experience, not trend-chasing.

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

Hard Stop

If you agree, build this way. If you disagree, test the opposite and measure the real cost.

Start with Miru or read the docs.

Vipul A M

Co-founder at Saeloun. Building Miru. Rails contributor. Shipping from Pune, India.