I shipped WhatShipped in about a week.
Not because I'm exceptionally fast. Because I've spent years making the mistake of optimizing for building instead of for shipping — and I finally stopped.
This is what actually changed.
The old pattern
The cycle I used to run:
- Have an idea
- Build the full version in my head
- Start building
- Keep building until it felt "ready"
- Launch
- Silence
- Lose motivation, move on
The problem wasn't the execution. It was the framing. I was treating "done" as a quality threshold I set internally. By the time I shipped, I'd answered every question except the one that mattered: do people actually want this?
WhatShipped started from a real frustration
I'd been building Geentoo — an Italian platform for co-founders — for months. Great commit history? No. It was full of fix, wip, ok this works, ok this actually works.
When I wanted to communicate what had changed to users, I had nothing coherent to show. I wanted a tool that could look at a messy git history and generate a readable, structured changelog automatically.
It didn't exist in the form I wanted. So I built it.
That's the only origin story that produces something worth shipping: solve a problem you've personally experienced. Everything else is speculation.
What I cut to ship in a week
The list of things I explicitly chose not to build for v1:
- OAuth for every platform on day one (started with GitHub only)
- Custom domain support per user
- Team and collaboration features
- A usage analytics dashboard
- A polished UI
- Public changelog hosting pages
- Webhook integrations
None of those were necessary to answer the core question: does connecting a repo and generating a changelog from AI actually solve the problem?
Everything else is iteration. You can't iterate on something you haven't shipped.
The hardest part of building solo
The hardest part isn't the code.
It's the absence of external structure. No product manager deciding priorities. No standup creating accountability. No teammate pushing back on scope creep.
When you're working alone, you can build features forever. There's always something that seems worth adding before launch. The constraint has to come from inside.
The question I use to cut scope: "Is this needed to test whether the core thing works?" If the answer is no, it goes on a list for later. Not in the backlog. On a separate list, so it stops pulling at my attention.
The metric that keeps me honest
Not star count. Not signup volume. Not revenue (not yet).
The question I ask every week: "Did I have a real conversation with a user this week?"
If the answer is no, nothing else matters. Everything is speculation until it's confirmed by someone who isn't me using the product to solve their problem.
This sounds obvious. It's surprisingly easy to spend a week shipping improvements based on assumptions and feel productive.
What's next
The product works. The next phase is distribution — specifically, reaching the people who need it most: open source maintainers with active projects and no changelog.
That means direct outreach, content, and building in public about what's actually working versus what isn't.
If you maintain an open source project without a changelog, I'd genuinely like to hear what the friction point is for you. Feel free to comment or reach out.
And if you want to generate a changelog from your existing git history — messy commits and all — there's 1 free generation at whatshipped.dev.
Top comments (0)