He built the feature. Then the software shipped it.

Two separate people in the Dutch accounting community built their own tools for the same problem — bulk time entry.

One built an open-source tool for e-Boekhouden because entering billable hours for multiple employees, one by one, was slow enough to justify writing a solution from scratch.

Another wrote a Python GUI using the Moneybird API because Moneybird had no convenient way to copy or bulk-book time entries across projects.

Both tools worked. Both solved the problem.

And at some point after both were built, the products started shipping similar features themselves.

This pattern comes up regularly in accounting software. A user hits a friction point, the product doesn’t address it, someone builds around it using the API — and then eventually the product catches up. The gap between “the software should do this” and “the software now does this” can be months or years.

In that gap, the options are: do it manually, find a workaround, or build something.

The people who build something learn the API. They understand how the data model works. They end up knowing more about the system than people who just waited for the product to ship it.

That knowledge compounds.

When the software eventually ships the feature, they don’t need to use it the naive way. They know the edge cases, they understand what’s happening behind the interface, and they can evaluate whether the native solution is actually better than what they built.

Building around a limitation is not wasted time.

It’s how you learn the system.