What I learned building a side product
Jul 5, 2026 · 4 min read
I should say this up front: everything here is what I learned from my own experience. The same experiences might lead someone else to different conclusions.
When you build a product to solve a problem you ran into yourself, and you want it to make other people's lives easier too, a community that supports it starts forming around you on its own. And sharing the development process in public undeniably helps you find your first customers.
My biggest motivation while building Cloock was actually to get better at managing my own time, and to be able to look back and analyze it. For that, I designed a clock visual I believed was unique. You could also plan your day on a timeline, the kind we all know from video editing tools. It made you feel like the film director of your own day.
Setting boundaries early
But building side projects as someone with a full-time job has its downsides. Side projects give you the chance to experiment in different areas, run into different technical problems and work out their solutions, so they end up feeding your actual job and your knowledge too. But the moment you start treating a side project as a business, responsibilities pile on top of it that start limiting your freedom. The promises you make to your users, having to become more open to their feedback, making sure paying customers are genuinely satisfied with what they bought, and so on.
This responsibility to your users, and the sheer amount of things that need doing, eats into the attention and focus you give your main job, even when you never meant it to. That's why, while building Cloock, I cut back the time I was giving it even though it had 50 paying closed-beta users, and opened it up to everyone with a local-first version. Because my priority is always my full-time job. And my full-time job lets me build things that touch far more people than I could ever reach on my own, which makes it a much more satisfying place for me. So if you work full-time, it might be worth drawing your boundaries before you start building a product, and deciding how far you're willing to go.
The new feature trap
Another trap in the development process was focusing on adding new features instead of perfecting the core ones: making the product more stable, more secure, more performant. A new feature always looks more tempting and easier, by the very nature of being new: you already know the problems of your existing features all too well, but you haven't met the new one's problems yet. So you'll want to escape the difficulty and tedium of improving what exists through the fun and ease of building something new. The biggest lesson I took from building Cloock was to focus on the core feature and not spend energy on anything new until it's perfect.
Trust, not data
Another thing is caring about your users' privacy as a solo developer. Data genuinely matters for big companies and big projects; but if you're indie, I believe intuition and empathy usually work better. Analytics tools, the services that motivate you with growing numbers and let you watch how users behave, do give you important clues about your product and how people interact with it, but they damage the organic bond between you and the people who use and support what you built. Because once you start looking at the numbers, charts begin driving your decisions instead of your intuition; and to a user who knows they're being watched, you turn from a companion into an observer. So even if it's all anonymized, I think prioritizing your users' privacy in your small side projects, and actually guaranteeing it, goes a long way in strengthening the bond between you and them.
I try to remember what I feel and what worries me when I'm using someone else's product, and to build mine in a way that moves away from those worries. For a solo developer, no data can be worth more than the natural trust between you and your own audience.
Cloock is open source now
The real reason I wrote this post is to announce that I've now shared Cloock as fully open source. Keeping the code closed on a product I can't give more time to, but that still works and that some people still use, feels wrong against the open-source culture I've learned so much from and contributed to. So I've open-sourced Cloock under the MIT license; anyone who wants to can take it and, with whatever modifications they like, build their own perfect, personal time-planning tool.
If you're a Cloock user and you're reading this: thank you for all your contributions and support. Having you as part of this product-building experience taught me a lot. I hope that, in some way, the product I made and the lessons I took from it gave something back to you.
Thanks.
