I’ve been rethinking the product I’m building, and I’d like honest feedback from solo builders.
The original idea was simple:
Turn GitHub commits into AI-written tech blog posts.
At first, that sounded useful. I like writing about what I build, but like a lot of developers, I
stop blogging the moment real work gets busy.
So I thought:
maybe AI can help bridge that gap.
But the more I worked on it, the more something felt off.
If commit messages are partially AI-written, and PR descriptions are partially AI-written, and then
an AI turns that into a blog post, you can end up with polished text that sounds good but feels
increasingly disconnected from the actual work.
That seems dangerous.
What I actually found useful was something else:
being able to look back and recover what I worked on that week.
Not “publish a perfect post.”
More like:
- What did I actually build?
- What changed?
- What was the reasoning?
- What did I miss?
- What should I revisit next week?
So now I’m considering a narrower product:
A weekly build log copilot for indie hackers / solo developers.
The idea would be:
- read recent GitHub commits and PRs
- reconstruct the past 7 days of work
- summarize key changes and decisions
- give AI feedback on missing context, unclear reasoning, or possible risks
Private by default.
Public devlogs can come later, maybe.
Before I build more, I want to validate whether this is even a real problem for other people.
A few questions for solo builders here:
- How do you currently keep track of what you worked on each week?
- When you need to remember “what happened this week?”, what do you go back to?
- Are commit messages / PRs enough to recover the actual context?
- Is private reflection more valuable than public writing for you?
- Would you actually use a tool like this, or is manually prompting ChatGPT/Claude already good enough?
If you’re building solo and have 5 minutes to share your workflow, I’d really appreciate it.
Brutal honesty is welcome.
I’m trying to figure out whether this should exist at all.
Top comments (3)
I created an index in Algolia, which started as a DEV challenge project but it's free so I kept it there. I don't capture the build information itself though, I capture the decisions I'm making about the build. Since AI does most of the work anyway, I don't much care about the implementation details that would show up in a PR. What I do care about is why I picked X over Y or why I didn't finish that one feature 6 weeks ago. Algolia makes it searchable and there's a chat implementation that I have wired with OpenAI. github.com/anchildress1/system-notes. The website is at anchildress1.dev.
I wrote a small MCP for the decision capture process, which works in ChatGPT or Claude, just to make life easier. github.com/anchildress1/supascribe...
It's really serious overkill for what it is, but it works and makes my life easier. I'll have a chat with Claude (or multiple ones) and then tell it to capture all key decisions that were made about the project. Those go to Supabase -> Algolia and then everything is searchable on the website with a few monthly clicks.
The pivot you're describing—from AI-generated blog posts to a weekly build log recovery tool—feels like it's less about changing the product and more about discovering who it's actually for. The original idea made sense for a certain kind of developer: someone who wants to build an audience, who sees blogging as part of their growth strategy, who's willing to trade some authenticity for consistency. The revised idea is for someone who just wants to remember what they did and why, for themselves, with no audience in mind.
I think you're onto something with the "private by default" framing, but I'd push it further. The value might not even be the summary itself—it's the gap detection. You mentioned AI feedback on missing context and unclear reasoning. That's the part that feels genuinely different from just running
git log --since="last week". A summary of what you did is mildly useful. A list of commits where your commit message says "fix stuff" and the AI says "you might want to revisit this—it's unclear what was broken or how you fixed it" is actually actionable. It's not just recovery. It's a lightweight accountability layer for your future self.The question I'd add to your list is whether people want this to run automatically or on demand. Automatic means it catches things you forgot to flag. On demand means you only engage when you're already in reflection mode. The people who need this most might be the ones least likely to remember to run it. Curious if you've tested either cadence yet, or if you're still in the "talking to people before building" phase that most of us skip and then regret.
Interesting pivot. I did something similar with SwiftCopy started broad (AI copywriting for everyone), now focusing on specific use cases. The "build log recovery" angle is smart because it's a forcing function: you actually have to ship to have something to log. What's the format looking like structured template or free-form?