I built GitPulse while broke — an AI tool that turns Git commits into changelogs. Honest feedback welcome.
I've been unemployed for a while now. Not the kind of thing most founders casually mention, but it's the honest context for why I built this.
I've always believed you can build something real from zero — no funding, no connections, just skills and time. This was my chance to test that belief.
The problem I picked wasn't discovered through market research. It came from my own frustration: writing changelogs has always felt like unpaid overtime. You finish the actual work, then you have to sit down and explain what you did — in plain language, for users who don't care about your commit history.
Before AI, I'd spend 30 minutes on it before every release. After AI, I'd paste commits into ChatGPT manually, every single time. Neither felt right.
So I built GitPulse.
How it works:
- Connect: Your GitHub repo via OAuth
- Webhook: Add a webhook URL to your repo settings (one-time, 2 minutes)
- Automate: Every git push → AI reads your commits → draft changelog created
- Publish: You review it, publish it, done (Public URL + embed widget included)
Stack & Hosting Hacks:
- FastAPI, HTMX, PostgreSQL (Supabase), AI fallback chain across DeepSeek/Groq/OpenAI, and Polar.sh for payments.
- Hosted on Render's free tier. Since Render puts the app to sleep after 15 minutes of inactivity, I set up a free cron-job.org trigger to ping the site every 14 minutes. This eliminates the cold-start delay so users always experience a fast, fully loaded page instantly.
Pricing: Free (3/month) → $7/month → $19/month
I know tools like this exist. I'm not claiming to have invented the category. I just wanted to build something genuinely useful, keep it simple, and find out if a solo developer can get even a handful of paying customers with zero marketing budget.
That's the experiment.
If you've dealt with the changelog problem before — or if you try it and it breaks — I'd genuinely love to know your thoughts!
Honestly, this is the kind of project I love seeing here.
Building something useful while going through a tough financial situation takes a different level of persistence. And the idea itself actually solves a real developer pain point — most changelogs are either ignored or manually written at the last minute.
I also like that you focused on a very specific workflow instead of trying to build another generic “AI for developers” tool.
Keep shipping. Projects built with this level of necessity and consistency usually end up finding their audience.
Thank you so much for the kind words and encouragement. It really means a lot, especially right now.
Going through a tough financial stretch while building forces you to be hyper-focused. You don't have the luxury to waste time on over-engineered features or vanity metrics, so you focus strictly on solving a single, painful problem as simply as possible.
Hearing that the specific workflow resonates with other developers is the best validation I could ask for. I'm definitely going to keep shipping and refining GitPulse. Thanks for the boost of motivation!
The strongest part here is that you are solving the post-ship admin nobody wants to touch.
Developers already finished the real work, then changelogs ask them to translate commits into something users can understand. That is a painful moment because it happens exactly when people want to move on to the next release.
GitPulse is clear, but it may keep the product feeling like a commit-to-changelog utility. The broader value sounds more like release communication: turn development activity into clean user-facing updates without making the developer do extra writing.
If that is where it goes, Xevoa .com would give the product a wider dev-workflow frame. It could still start with changelogs, but the brand would not be stuck only to Git commits if you later add release notes, product updates, embeds, team workflows, or customer-facing release feeds.
The simple version is already useful. The bigger opportunity is owning the workflow between “code shipped” and “users understand what changed.”
Thanks for the killer feedback!
You're spot on—limiting the scope to just Git commits could bottleneck the brand later on. Right now, I'm keeping it hyper-focused as a utility just to validate the core pain point on a zero budget.
But I love the concept of 'release communication' and owning that bridge between code shipped and user understanding. Definitely keeping this broader vision in mind as I gather more data. Appreciate the insights!
That makes sense.
Validating the narrow pain first is the right move. If the changelog utility proves people actually want this after every release, the broader “release communication” layer becomes much easier to justify later.
I’d just keep watching one thing closely: whether users describe the value as “Git changelogs” or “helping users understand what changed.” The second one is where the bigger product lives.