Product Development
What Building Cycletrack Taught Me About Owning a Product
From a small family need to a privacy-first web and Android app, the hardest decisions were often not about code.
Most of my professional work starts with a brief, a business requirement or an existing system. Cycletrack started differently: with a problem close to home and the thought that perhaps I could build something more useful myself.
The original idea was simple. I wanted a menstrual cycle tracker that was easy to understand, respectful of personal information, free from advertising, and practical for more than one person in a family. What began as a personal project eventually became a web app, a Progressive Web App and an Android release.
Building it has reminded me that developing a product is not the same as finishing a development task. When you own the product, you also own the decisions that come before the code — and the responsibilities that remain long after it is deployed.
A real problem is a better starting point than a long feature list
As developers, we can be tempted to start with technology. Which framework? Which architecture? Which new capability could we add?
For Cycletrack, the more useful questions were simpler. Could someone open the app and understand what to do? Could it work across devices? Could the same account support different profiles? Could it remain free and free of ads without making the experience feel unfinished?
Those questions shaped the product more than any individual library or framework. I built it with Laravel and web technologies I knew, then developed the installable and Android experiences around the same underlying idea: a focused tool that stays out of the user's way.
That is one of the strongest lessons I take from the project. A smaller set of features, chosen for a clear reason, can be more useful than an impressive list of things nobody asked for.
Privacy changes the way you make product decisions
Cycle tracking involves sensitive personal information. That makes privacy more than a paragraph on a legal page. It influences what the app asks for, what it stores, how it explains its behaviour and what choices people have over their records.
I did not want advertising or unnecessary profiling to become part of the product's business model. That decision sets boundaries, and boundaries are useful. They force me to ask whether a new feature makes the product genuinely better, rather than simply creating another reason to collect data or keep someone engaged.
It also means accepting that trust must be earned through clear behaviour and continued maintenance, not just through a promise on the homepage.
When you build a product around trust, the small decisions become some of the most important ones.
Offline support is easy to appreciate — until a device changes
One of Cycletrack's goals was to remain practical without a constant internet connection. As a Progressive Web App, it can keep useful information on a device, which is convenient in everyday use.
But real life introduces another set of questions. What happens when someone changes phones? Clears browser storage? Wants an additional device? Or simply wants to keep a personal copy of their records?
These are not the kinds of details that make an exciting feature announcement, but they matter enormously to someone who relies on an app over time.
Feedback helped push export, import and backup options higher on the priority list. Cycletrack now supports CSV exports for cycle and day-log records, backups that can be imported on another device, and optional synchronisation with the server. Each option solves a slightly different problem, but they share one purpose: making personal records easier to keep and move.
From a development perspective, this is a lesson in thinking beyond the happy path. A feature is not truly finished just because it works on the device where it was first created.
Releasing an app is the beginning of a different kind of work
Cycletrack started as a web product and became available on Google Play in February 2026. That was an important milestone, but it also reinforced something I have learned on larger projects: being able to ship is only one part of building a dependable product.
After launch, the questions keep coming. Is the interface understandable? Does an update preserve what people already know? Can users recover their data? Are instructions clear enough? Does the product still feel simple as new capabilities are added?
Owning a product means moving between development, design, testing, communication, support and long-term planning. Sometimes the most valuable improvement is not a new screen. It is clearer wording, a better recovery option or a frustrating step removed from an existing flow.
A product also needs to be understood
Another unexpected part of the journey has been writing educational content around the app. Tracking dates and symptoms is useful, but understanding the information behind those records can be useful too.
That is why Cycletrack has grown beyond a tracker into a small collection of educational articles. The aim is not to provide medical advice, but to explain topics in accessible language and help people ask better questions when they need professional guidance.
For me, this connects product development with another part of my work: content, usability, search and communication. Building the technology is important. Helping people discover it, understand it and use it with confidence matters just as much.
What I would keep if I started again
If I began the project again today, I would still start with the same principle: solve one real problem before trying to solve ten imagined ones.
I would still treat data ownership and privacy as product decisions, rather than features to add at the end. I would still make time for the less visible work — testing recovery scenarios, improving explanations and listening when people tell me that something is confusing.
And I would still choose to build something small enough to care for properly.
Cycletrack is an independent project, and there is more I want to improve. But it has already given me something valuable: a closer understanding of what it means to take responsibility for an entire product, not just the part of it that involves writing code.
That has made me a better product builder — and it is one of the reasons I still enjoy this work after more than two decades.
If you would like to see the product itself, take a look at my Cycletrack case study. For the user-facing story of its first year online, I also wrote a separate update on Cycletrack.app, focused on the people and feedback helping the app grow.