What 3 years of dogfooding taught me about building a developer tool
One thing I’ve learned from building a product for myself is that feature creep does not always feel like feature creep.
Every new feature can solve a real problem, which makes it easy to justify adding it. The harder question is whether all those useful features still form one coherent product.
I’ve been writing code for more than 15 years, and throughout that time I created small tools to make my own workflow easier. About three years ago, I started building Arezgit. It was originally a visual Git client, but I gradually integrated tools I was already using separately: database management, test-data generation, API requests, a Pomodoro timer, a task board, and more.
My answer to the scope problem, at least for now, has been to keep Git and the commit workflow as the clear center of the product.
The latest update focuses heavily on that. It can scan files for passwords, API keys, and other secrets locally and without AI, remove code comments in bulk, and optionally review code and generate commit messages using your own Gemini or OpenAI API key. The source code is never sent to Arezgit’s servers.
Most features are free, including visual Git for both public and private repositories. There are paid features, but around 90% of the system is free.
For transparency, I have used AI during development for things such as translations and some front-end work. I am mainly a back-end developer, although I also wrote much of the front end myself. Everything AI-assisted was reviewed several times, and I rewrote anything I did not fully understand or agree with.
This is the biggest project I’ve built, and I’m still improving it constantly.
I would be interested in hearing how other builders think about this: can a product remain coherent while bringing several adjacent tools together, as long as one workflow stays clearly at the center? Or would you split these tools into separate products?
Any honest feedback would help a lot.