Forem: Torrin Leonard

A Time Tracking App Wanted $28,800, So I Replaced It With a Homelab

Torrin Leonard — Wed, 28 Jan 2026 04:18:13 +0000

My parents run a software testing + consulting company called worX4you. They’ve been doing it for 17 years. They’re stable, they’re good at what they do, and their business is not complicated:

Hire good people --> small business clients --> track time --> invoice --> repeat.

For years they used Harvest for time tracking. Simple product, fair price. Everyone moves on with their life.

Then Harvest changed their pricing after an acquisition (reported in 2024 as involving private equity firms Montagu and TA Associates). And the vibe went from “boring SaaS you forget about” to “wait, are you serious?” pretty fast.

We were paying $9.99 USD per seat. Then my parents recieved an email about a pricing change: $17.50 per seat, plus a new “usage” layer where the options were either:

$2,000/month for “unlimited usage”, or
usage-based billing capped at $400/month

As of writing, Harvest has not updated their pricing page to reflect these increases.

Maybe you’re thinking: “Enterprise pricing is always weird.” Sure. But this wasn’t a giant enterprise rolling in cash. This is a small business that just wants to log hours and get on with real work.

So I did what any reasonable person with a mild homelab addiction does:

I spun up Kimai, an open source time tracking alternative, on our home server.

Now everyone can log hours at our own URL, on our own hardware, for the cost of electricity and an internet connection we’re paying for anyway.

And here’s the part I can’t stop thinking about:

I think this kind of pricing is accelerating open source adoption

Not because everyone suddenly became an “open source purist”.

But because at some point, the math becomes insulting enough that people start asking:

“Wait… why are we paying how much… to record hours?”

The pricing breaks the value prop

For context, my parents were on $9.99 USD per seat as a flat fee. Totally reasonable. Then they got a new quote: bump the per-seat price to $17.50, and add a whole new “usage” layer.

Option one was a $2,000/month flat fee for “unlimited usage”. Option two was “usage-based”, calculated from recent months, capped at $400/month. Which, first of all, how do you even charge “usage” for a time tracking app? People are literally typing numbers into boxes.

And the weirdest part: if we took the usage-based option, we’d have to enable credit card billing on all invoices. Translation: route more of the company’s money flow through Harvest’s credit card billing, and potentially hand over +3% of invoice revenue in processing/platform fees.

At that point it stops feeling like “time tracking software” and starts feeling like someone found a new place to stick a toll booth or boom.

If my parents took the “unlimited usage” option, that’s roughly $400/month for seats plus $2,000/month for the unlimited fee.

In total, my parents would have to pay $28,800 a year for a time tracking app.

That’s not “a little increase to help out a time tracking startup”. That’s “congrats, your time tracker is now a mortgage-sized monthly bill.”

Meanwhile, hosting Kimai:

On a homelab: basically free (already paying for power + internet + old PCs and already bought hardware)
On a VPS: still basically free compared to $28,000 A YEAR
- A small VPS on DigitalOcean/Linode/etc is like $6–$20/month
- Call it $120–$240/year, plus a domain

Peanuts. Even accounting for time spent tinkering and setting everything up.

For $28,000 you could hire someone to build a full height rack, set up all the SaaS and IT services you could dream of, and still have enough money left over to buy 16gb of ddr5 for your gaming pc.

Our homelab was basically a one-time hardware purchase. After that, it’s a fixed platform I can keep extending. I can run dozens of Docker containers on it, hosting open source alternatives to the paid stuff we used to subscribe to, all for about the cost of a Netflix subscription each year.

What I actually did

I’m a fullstack dev, I main Ubuntu on a framework 16, and I LOVE homelab stuff. Been building out a full height rack for years. Currently I have three machines: one is a dedicated 70Tb NAS, another has 2 3080 Ti's for llms + docker containers, the other is dedicated to nginx, routing and more docker. This wasn’t heroicly built. It was just modern infra being very accessible now. I spun up the Kimai in an afternoon of tinkering.

At a high level, it’s Kimai running in Docker, with Docker running inside a VM on Proxmox. I put Nginx in front so it’s reachable at a clean URL, used Cloudflare for DNS and proxying, and got HTTPS set up with free SSL through Cloudflare. For backups, I rely on Proxmox ZFS snapshots, because I enjoy sleeping.

Now my parents’ team can log time like they always did, except we control the instance, we control the data, and we control the cost. And Kimai is… fine. It’s not some VC-designed conversion funnel. It’s a time tracker. That’s the point: simple, does the job, set it up once and forget about it. What we thought we could rely on Harvest for.

The private equity playbook (and why it backfires)

I’m not claiming I know what’s happening inside Harvest. I’m not on the board. I’m not reading internal memos.

But I have seen this pattern enough times to recognize the shape of it:

Buy a stable “boring SaaS” with predictable customers
Increase prices hard (especially on teams that can’t easily churn)
Add vague fees that are hard to justify (“platform”, “usage”, “success”, etc.)
Squeeze revenue now, worry about retention later
If customers leave… that’s a next-quarter problem

A pretty common term people use for the worst version of this is asset stripping, extracting value (cash, fees, whatever) and leaving the company weaker on the other side. I theorize a version of this is happening over at Harvest right now. In extreme scinarios, the company dies as a result. The recent Hudson's Bay bankruptcy is a good example of this process. A 356 year old company, one that shaped the fabric of Canadian nationhood, obliterated in 2 years of private equity management.

And here’s the funny part:

This strategy creates the exact conditions where open source wins

When pricing is fair, convenience wins.
When pricing gets weird, control wins.

We've seen this play out before with movie streaming vs piracy. The 2020s have seen a surge in consumer streaming costs and a surge in content piracy.

Open source doesn’t need to be perfect. It just needs to be:

good enough
cheaper enough
stable enough
easy enough to host and use

And in 2026, that last part is way easier than it used to be.

The “Blender effect”: once open source is good, it’s hard to compete

Blender is the example I keep coming back to. Blender didn’t win because it had the best pricing page. It won because it became genuinely good, widely supported, and community-driven. It’s also basically impossible to undercut because “free + open source” is undefeated. ~$100/month for cinema 4d and octane engine? No thanks.

Any proprietary 3D tool competing with Blender has to justify why you should pay… when the free option is legit industry-grade.

Time tracking isn’t 3D modeling, obviously. But the pattern rhymes:

If enough people get burned by “stable SaaS --> acquisition --> pricing explosion”, they start looking for exits.

Open source is that exit.

I think we’re entering a new software cycle

I think we’re going to see more of:

Small stable SaaS exists for years (slow growth, reliable)
It gets acquired (VC/PE/etc.)
Prices go up, fees appear, support gets “optimized”
Customers churn, especially the technical ones
Open source alternatives get an influx of users + contributors
The market resets around tools people can actually control

And the difference now vs. 10-15 years ago is huge:

You don’t need a rack in a closet and a CCNA to self-host something.

I do own a rack, but it's in my parents baseement... far better than a closet I'd argue. but my point remains!

You can run a ton of open source SaaS tooling on:

a Mac mini
a Raspberry Pi
a $10/month VPS
an old pc repurposed as a home server

Open source adoption isn’t just ideology anymore. It’s logistics. And logistics that small businesses will take seriously when it's destroying their bottom line.

The optimistic takeaway

Do I like watching solid products get enshittified? Not really.

But I do like the unintended side effect:

When companies squeeze users for short-term gains, they’re basically funding the ecosystem that replaces them.

People won’t just roll over and take it. We didn’t.

We replaced Harvest with Kimai in an afternoon and moved on with our lives. Literally saving us $28,000 A YEAR.

And if enough teams do that, the “boring SaaS” category starts to look a lot like:

open tools
self-hostable defaults
paid hosting as a choice (not a hostage situation)

Which is… honestly kind of great imo.

Checkout my guide to setting up Kimai here. If you wanna read more, checkout my other posts here or visit my home page.

The problem with React and MUI

Torrin Leonard — Tue, 10 Jun 2025 03:08:47 +0000

For the past year I've been working on a project that started as an internal tool at my job as a web dev at Equator Studios, the project has made me realize that there is a big problem with the way modern js libraries like Material UI are built for developers.

Using Material UI is fairly burdensome for many reasons, the package size, it's reliance on react and the performance issues that introduces with the virtual dom, a quite horribly disorganized theme system, and the general resistance to customization one faces when trying to tweak anything about any component.

Basically, if you don't want to ride their carefully designed rollercoaster the way they intended, seatbelt, bubble wrap and all, you are simply out of luck or face a heap of challenges and wasted time.

Generally the problems with MUI and most modern JavaScript projects (React is another good example of this) can be distilled: They suffer from expanding complexity creep.

const theme = createTheme({
  ...
  components: {
    MuiButton: {
      styleOverrides: {
        root: {
          borderRadius: '8px',
        },
      },
    },
  },
});

This complexity creep leads to an increase in confusion among new developers both arriving to material ui, or to the js ecosystem at large for the first time.

As someone who's first experience with web development was manually creating html/css/js templates in Django, the React/MUI ecosystem really warped and altered my understanding of web development into a gooie mess. React intro tutorials never teach you about the "dom" or how js is used to physically update html dom elements in a literal .html file.

That concept was never communicated to me, not through code, not through the documentation, not even through third party tutorials on how to use these tools. They hand you the hammer and blabber something about nails while kicking you out the door, and thus I never had an understand of how the elements on the page were actually structured, rendering, updating, or reacting.

This reveals another major issue with MUI and React: the complexity creep abstracts the need for basic understanding of the tools your using; the browser, the dom, css, and JavaScript itself.

How did I wake up you ask? That's simple, I work with a senior developer who insists on building almost everything ourselves. We have our own websocket implementation, our own base64 encoder hard coded into our backend, files and files of complex projection math to render gis data.

This persistent pursuit to create almost everything our selves has two main benefits over using off the shelf solutions: Everything is easily tweakable to our companies needs, and we are able to learn the fundamentals of any problem we tackle, improving our skills as developers.

Remember that theme definition in MUI above? This it in destamatic-ui:

const theme = {
    button: {
        borderRadius: '8px'
    },
};

That's it, a simple object with key button, the css class name, the value of which is a style object converted into inline css in the dom when that class is invoked. dead simple. All that's needed to define a global theme. This can even be duplicated and used in another ThemeContext in the same app.

This approach brings convenience without cluttering the page with ten different parameters and objects you need to declare because it will break if you don't for some reason you can read about in the documentation or on their github issues pages when it breaks.

The themeing system in our ui library destamatic-ui is quite advanced, it has inheritance, so you can reuse styles, variables and functions so you can create reactive themes:

$alpha: (c, amount) => {
    let [r, g, b] = color(c);
    return color.toCSS([r, g, b, parseFloat(amount)]);
},
$color: '#FF0000'
...
<div style={{ background: '$alpha($color, 0.5)'}} />

That's not all though. destamatic-ui is built on two other libraries that have this same no complex nonsense approach: destam, a delta state management library, and destam-dom, a dom manipulation library built on destam's observer reactivity.

Why is destam-dom better and simply faster? destam-dom doesn't use a virtual dom, it doesn't re-render the entire page on an update. It directly modifies the dom, and the specific element of the dom a given component actually needs to update. Which means it doesn't require the entire page to be reloaded whenever there is even the smallest of updates.

Torrin Leonard | Full-Stack Engineer

Full-stack software engineer building AI-powered web apps, custom UI frameworks, and the infrastructure they run on.

torrin.me

I built my personal site torrin.me using our destam stack, my site was originally built with React, React-Three-Fiber, and MUI. I cannot tell you how buttery smooth the loading is now, the theme transitions, the snappy reactivity. Using destam-dom simplified my build pipeline, made deployments 40 seconds.

Working with the destam stack professionally has not only inspired me to build my hobby projects using it but has also deepened my understanding of how websites function. By embracing a more efficient, back-to-basics approach, I've learned to create web applications that are lean, efficient, and snappily reactive. I firmly believe that if more developers adopt this approach to libraries and frameworks, it could lead to a healthier ecosystem for newcomers to learn and create.

If you're tired of the complexity and ready to experience the difference, I encourage you to give the destam stack a try. We've dedicated ourselves to crafting tools that prioritize both developer and user comfort. You can explore the stack and see for yourself:

Join us in creating more efficient and enjoyable web experiences!

This was just a brief introduction to destam, destam-dom, and destamatic-ui. I'll be writing more in depth articles and tutorials about the stack, and some adjacent projects I've been working on using it to show it off. Please let me know what you think!