Harvest season is over

Late on August 23, 2026, as I was heading to bed, my phone lit up. It was an announcement from Harvest. Fittingly enough, delivered in the middle of the night.

On your next renewal date, September 24, 2026, your account will be transitioned to Harvest Enterprise plan with Unlimited usage billing.

You will be automatically billed $20 844,00 for your new annual plan.

My first reaction was that this couldn't be right. Had Harvest been hacked and I was now being subjected to some menacing scheme?

I got the hacking part wrong.

Harvest was one of the early SaaS success stories, launched in 2006 and built around a relatively simple promise: useful software, predictable pricing and a long-term relationship with its customers. In 2025, Harvest was acquired by Bending Spoons, marking the end of nearly two decades under its original ownership.

Not long after, we decided the costs were unjustifiable and that it was time to move on.

Finding an alternative

Once we had decided to replace Harvest, we already knew we wanted to move to an open source project. At Happiness, the company I own and work for, we work exclusively with open source software for our clients, mainly Drupal, WordPress and Matomo.

A search for open source time tracking projects produced a longer list than I had expected. We chose to focus on Solidtime and Kimai, as they seemed to suit our needs best.

Both covered the basics we were looking for, but Kimai had a few characteristics that made it particularly attractive to us. So we decided to move forward with that option.

First, Kimai is written in PHP and built on Symfony. PHP is the language we work with every day, and Symfony is a framework we already know well.

Self-hosting was another important factor. We can run Kimai on infrastructure we control and decide ourselves when to upgrade it.

Kimai's API also gives us a way to integrate time tracking directly into the tools we already use. We are particularly interested in exposing these capabilities through MCP, allowing our internal tools and AI-assisted workflows to interact with Kimai.

Finally, there was the practical question of getting our existing data out of Harvest and into whatever came next. After years of using Harvest, starting with an empty database wasn't an attractive option. Kimai made it relatively easy to import our exported Harvest data, significantly lowering the cost and risk of making the switch.

None of these things alone decided it. Together, they made Kimai a good fit for both how we work today and how we want to manage an important piece of our infrastructure in the future.

Our first plugin

Once we made the decision, we immediately ran into a gap: Harvest had an integrated scheduling tool called Forecast, and we needed an equivalent.

We looked at standalone alternatives such as OpenProject and LibrePlan. Both are capable projects, but frankly, they were total overkill for what we needed. We just wanted to schedule team members across projects, look at the coming weeks, and compare planned hours against actual logged time (preferably inside the same dashboard we already use for clients and hours).

So we decided to build our own planning plugin, PlannerBundle.

Even though I know Symfony well, writing core business logic for an unfamiliar codebase required a bit of a leap. Framework knowledge only gets you so far when you're navigating another app's internal conventions.

PlannerBundle became our trial by fire with Kimai. We didn't try to clone every single feature in Forecast right away. Instead, we built only the scheduling tools our team actually uses day-to-day. Since it's a isolated plugin, core Kimai updates won't break our custom features, and we can iterate as our workflow evolves.

Why open source

For us, open source isn't just about dodging subscription fees. It's about control.

We happily paid for Harvest for years and built real company workflows around it. But we had zero say in what happened to the product. When ownership changed, the ground shifted under our feet overnight.

Open source doesn't magically fix everything. Maintainers can drop projects, and open-source companies get acquired, too. The difference? The code doesn't vanish. If a project goes sideways, we can keep running our existing version, patch it ourselves, or fork it if necessary.

When a tool sits at the center of your invoicing, reporting, and historical data for years, it stops being "just an app". It becomes critical infrastructure. Replacing it isn't impossible, but it definitely hurts.

Having full access to our code, our data, and our tech roadmap feels a hell of a lot safer than gambling on the next SaaS acquisition.