Back

Shutting down TillWhen

3 Years...

TillWhen came into existence as an alternative to Toggl. It didn't try to compete with Toggl but just had to have the bare minimum features to be called a Time Tracker/Logger.

It was a project where I experimented with designs I thought would look good, typography that would look nice, and in some cases also built internal libraries and tools.

Overall, the project had a good run. It had quite a few active users when it started, and that number probably dropped over the years. But I got to experience development as an Indie dev, and I can't lie, it felt great.

Why shut it down?

It's mostly because of my inability to focus on the project, and the future reaper might not be able to support the project both mentally and financially.

You see, I plan to move into freelancing instead of a day job, and that's going to lead to a big change in my lifestyle since I can't expect the same income as soon as I start doing it.

TillWhen is cheap to host. It costs $140 per year, taking into account the Transactional Email Service and hosting costs. I've avoided all other costs by using my personal domain names, avoiding any file upload-based features, and overall keeping the app very small to be able to run on a simple $10 Digital Ocean instance. There were no ads because I don't like them, so I'm not interested in users seeing them either.

Overall, the decision is based on where I'll be in the next few months. I would prefer that users transition to other platforms slowly instead of me abruptly shutting it down one day (I shut down Taco in a day, and that wasn't nice).

The other issue is that TillWhen can't go through the dogfooding process, so issues are slow to get resolved and often overlooked since I don't even know they exist. I'm not a fan of time tracking, so I never use it, and the feedback loop is the only way to improve it. As mentioned, that's very slow for a product that doesn't really provide much value other than being simpler.

The last issue is my failure to maintain it properly. I can also blame it on the tech since upgrading that tech is another hassle right now, but it still is my fault for not writing it well enough to be able to refactor it properly. The codebase is a mess with all the experiments, my dumbness, and things I didn't understand about the stack when I started working with it. Now that I do understand them, the entire application would be better off rewritten than spending time refactoring it. I've tried to do it a couple of times, but then every other project that I use and provides me value ends up taking precedence. You can say I'm being selfish and not thinking about users, and you may be right, but they also deserve to use a product that's at least going to be maintained.

Does this affect other services like Goblin and CRI?

Not exactly. Goblin is something I use on a weekly basis for setting up my own tooling and other Go binaries that I often use. It's something I can maintain, so the chances of it shutting down anytime soon are quite low! And CRI is a self-maintained app and doesn't need me to mess with it unless the auto-population starts breaking, which is simple to fix. It's also small enough to be able to run on Vercel for free, so there's not that much work for me in it. So no, this doesn't affect both those services.

Why not make it a paid app?

I'm not sure how to make good productivity tools. I'm not a super organized or productive person, and these tools just cause friction in my workflow. So it's hard for me to keep building on a tool that I have no interest in and that will further impact the users. It's not just about the money, or I would've done that.

Hopefully, some of it makes sense. But well, it was a nice learning experience, helped me grow as a developer, and specifically as an indie developer.