From Consulting Agency to Product Company: The Miru Origin Story

Saeloun started as a Ruby on Rails consulting shop in Pune, India. Four developers. A handful of US-based clients. The typical arrangement: we build your software, you pay us by the hour, everyone’s happy.

Except for the billing part. The billing part was never happy.

---

The Spreadsheet Era

For the first year, we tracked time in Google Sheets. One sheet per project. Columns for date, developer, hours, and description. It worked the way a bicycle works for crossing a continent — technically possible, absolutely miserable.

The problems were predictable. People forgot to log. The sheets had conflicting formats. Generating an invoice meant manually tallying rows, copying numbers into a Google Doc template, and emailing a PDF. Every month, I spent an entire day just doing billing. A full day of a founder’s time, every month, doing data entry.

That’s not a business. That’s a punishment.

---

The Tool Carousel

So we tried the tools. All of them.

Harvest was first. Good product. Clean design. But at $10.80 per person per month, a 20-person team is paying $2,592 a year to track time. For a bootstrapped consulting shop in India, that’s a real number. And the invoicing was fine but not great. You still ended up in another tool for half the workflow.

Toggl came next. Great timer, minimal invoicing. We ended up using Toggl for tracking and something else for invoicing, which meant reconciling two systems. Reconciliation is where hours go to die.

Freshbooks had decent invoicing but felt bloated. Too many features we didn’t need, not enough focus on the ones we did. We were paying for an accounting suite when all we wanted was “track time, send invoice, get paid.”

We tried three others I won’t name because they’ve since been acquired or shut down, which is sort of the point. Tools disappear. Data gets trapped. APIs get deprecated. If your time data lives in someone else’s SaaS product, it lives at their mercy.

---

The “Let’s Just Build It” Moment

One Friday afternoon — and it’s always a Friday afternoon — I was reconciling a month of time entries across two tools and a spreadsheet. A $4,200 discrepancy between what we’d tracked and what we’d invoiced. Four thousand two hundred dollars we’d either overcharged or undercharged. We never figured out which.

I closed the laptop and told the team: “We’re building our own.”

The initial reaction was what you’d expect. We’re a consulting company. We have client work. We don’t have time to build a product. All valid objections. All wrong.

We started the next Monday. Two developers, part-time, between client projects. Rails backend because that’s what we know best. React frontend because our team was already deep in it. PostgreSQL because it’s boring and reliable. The first version had three features: time tracking, invoicing, and a client list. That’s it.

It took four months to get something we’d use ourselves. It took another two months before we’d show it to anyone outside the company.

---

Going Open Source

Making Miru open source wasn’t altruism. It was strategy.

We were a small team in India building a product in a crowded market. We had no marketing budget, no sales team, no brand recognition outside the Rails community. What we did have was a good product and the confidence that other consulting shops had the same problem we did.

Open source let us compete on merit instead of marketing spend. People could read the code. Run it on their own servers. Trust that the tool they were investing in wouldn’t disappear behind an acquisition or a pivot. MIT license, no asterisks.

The bet paid off. Within six months, we had contributions from developers in twelve countries. Bug reports that caught things we’d missed. Feature requests that shaped the roadmap. A community that gave Miru credibility no ad campaign could buy.

---

The Product Company Question

People ask me: “Is Saeloun a consulting company or a product company?”

The honest answer is both. The consulting work funds the product development. The product attracts developers who become consulting leads. They feed each other.

I know the startup playbook says you should pick one. Raise money, go all-in on product, grow at all costs. But I’ve watched that playbook kill good software. You take VC money, you answer to a board. You answer to a board, you optimize for growth metrics. You optimize for growth metrics, you add enterprise features nobody asked for, raise prices, and alienate the small teams who loved you first.

We don’t have a board. We don’t have investors. We have clients who pay us for consulting and customers who pay $1 per person for Miru. Both groups keep the lights on. Neither group gets to tell us what to build.

---

Where We Are Now

Miru 3.0 just shipped. Full expense management, a CLI, six report types, dark mode, API access, rebuilt payments. Every feature was born from a real problem we had running our own consulting business.

Our team is still in Pune. We still do consulting. We still track our own time in Miru every single day. When something is annoying, we fix it the same week. When a customer reports a bug, the developer who fixes it is the same person who uses the feature at 9 AM every morning.

That’s the advantage of building a product you need. You never run out of motivation to make it better. You never wonder if a feature matters. You just open the tool, do your work, and notice what’s broken.

If you’re running a small agency and you’ve got that Friday afternoon spreadsheet reconciliation feeling, you know exactly what I’m talking about.

Read the Miru 3.0 launch announcement to see everything we shipped.

Give Miru a try. app.miru.so or self-host from GitHub. Either way, you’ll never go back to the spreadsheet.