DEV Community: WhatShipped

What I learned building a solo product

WhatShipped — Tue, 07 Apr 2026 06:00:00 +0000

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.

Semantic versioning explained - and why most projects get it wrong

WhatShipped — Mon, 06 Apr 2026 06:00:00 +0000

"v2.0 is out!"

Does that mean you should upgrade immediately? Will it break your integration? What actually changed?

Semantic versioning (SemVer) was designed to answer these questions through the version number itself. Most projects use the number format without following the meaning — which defeats the whole point.

The spec in 30 seconds

SemVer is three numbers: MAJOR.MINOR.PATCH

2.4.1
│ │ └── PATCH: backward-compatible bug fixes
│ └──── MINOR: new features, backward compatible
└────── MAJOR: breaking changes

If every project followed this consistently, the version number alone would tell you whether an upgrade is safe. That's the goal.

What each number means in practice

PATCH (1.0.0 → 1.0.1)
A bug was fixed. Existing behavior is the same or better. Safe to update without reading anything.

MINOR (1.0.0 → 1.1.0)
A new feature was added. Existing code continues to work exactly as before. Update if you want access to the new functionality; skip it if you don't.

MAJOR (1.0.0 → 2.0.0)
Something changed in a way that may break existing code. Read the changelog before upgrading. You may need to update your integration.

When a project follows this consistently, users develop accurate intuition about upgrades: patches are safe, minors are low-risk, majors require attention.

The most common mistake

Bumping MAJOR for anything that feels "big."

A complete internal rewrite that doesn't change the public API is still a MINOR bump. A major visual redesign of a library's output that doesn't change how you call it is still MINOR. A significant new feature set is still MINOR.

MAJOR is specifically for breaking changes — changes that will cause existing code using your package to fail or behave incorrectly without modification.

Your sense of how significant the work was doesn't determine the version. The impact on existing users does.

The 0.x convention

While your major version is 0 (0.y.z), you're sending a signal: this is pre-stable, the API may change at any time.

In 0.x, it's acceptable to make breaking changes in minor version bumps. The convention acknowledges that early-stage projects iterate on their API before committing to stability.

When should you move to 1.0? When you're prepared to maintain backward compatibility and follow the MAJOR/MINOR/PATCH contract. It doesn't mean the software is perfect — it means you're committing to a contract with your users.

SemVer and changelogs are a pair

SemVer answers: how risky is this upgrade?

A changelog answers: what specifically changed?

One without the other is incomplete. The version number gives users a risk signal. The changelog gives them the information to act on it. Together, they enable users to make fast, confident decisions about whether and when to upgrade.

A MAJOR bump with no changelog that explains what broke and how to migrate is as frustrating as a breaking change with no version bump at all.

The decision rule

If you're ever unsure which number to bump, there's a single question that resolves it:

"Does code that currently uses my library/tool still work after this change, without modification?"

Yes, and it's a bug fix → PATCH
Yes, and it's a new feature → MINOR
No → MAJOR

That's the whole decision. The spec is detailed, but the practical rule is this simple.

Making the release worth reading

Once you've decided on the version bump, the changelog is what makes the release useful. A formatted, scannable CHANGELOG.md that groups changes by type (Added, Fixed, Breaking) paired with a clear SemVer bump is the complete picture.

If writing that changelog is the friction that causes you to skip it, WhatShipped generates it from your git history. There's 1 free generation — enough to produce the changelog for your next release without any manual work.

Version numbers are a communication protocol between you and your users. When you use them correctly, you reduce confusion, reduce support overhead, and build trust. It's one of the lowest-effort, highest-signal things a maintainer can do.

How to get your first 100 real users for an open source project

WhatShipped — Sun, 05 Apr 2026 06:00:00 +0000

Building an open source project is the easy part.

Getting people to find it, use it, and keep using it — that's the challenge. And it's one most developers never seriously address until the initial launch momentum fades and the stars stop coming.

Here's what actually moves the needle.

The distribution mistake

The default assumption: publish to GitHub, wait for organic discovery.

The reality: GitHub's search is weak for finding new tools. Trending is unpredictable and short-lived. Unless your project hits a major aggregator or gets shared by someone with a large following, GitHub organic traffic alone won't build a user base.

You have to go to where developers already are. Actively, not once.

The channels that work for early traction

Not all distribution channels are equal for dev tools. Based on what consistently works for early-stage OSS projects:

Hacker News "Show HN" — High signal audience, genuinely interested in new tools. A well-written Show HN post for the right project can drive thousands of visits. The key: lead with the problem, not the solution. "Show HN: I built X" is weaker than "Show HN: I kept forgetting to write changelogs, so I automated it."

Relevant subreddits — r/programming, r/webdev, and language-specific communities (r/rust, r/python, etc.) have large audiences who actively look for new tools. Share something useful, not just a link.

dev.to and Hashnode — Both platforms index well on Google and have active developer audiences. A post that genuinely solves a problem can generate inbound traffic for years. Write about the problem your tool solves, not the tool itself.

Direct outreach — More on this below, but targeted personal outreach to people who'd genuinely benefit is one of the highest-ROI activities for early adoption.

Discord and Slack communities — Framework-specific communities, language communities, and dev tool communities all have people actively looking for solutions to specific problems.

Pick two channels. Work them consistently. Spreading thin across five channels is less effective than doing two well.

Direct outreach done right

Direct outreach has a bad reputation because most of it is done badly.

The difference between spam and a welcome message:

Spam: "Hey, I built a tool for developers, check it out: [link]"

Welcome: "I noticed your project doesn't have a CHANGELOG — I built something that generates one from your git history automatically. Might save you 20 minutes per release."

The welcome version is specific, relevant, and makes a clear case for why this particular person would benefit. It's not a broadcast. It's a targeted observation.

For this to work at scale, you need a way to find people who match the profile. For WhatShipped, I built a script that queries the GitHub API for repos with moderate star counts, recent activity, and no CHANGELOG file — then the outreach is relevant by construction.

Content compounds. Outreach doesn't.

Cold outreach produces results proportional to effort. When you stop sending, it stops working.

Content is different. A good dev.to article that ranks for "how to write a changelog" will generate inbound traffic in two years without any additional effort from you. A good X thread that gets shared can drive hundreds of profile visits in a day.

The formula: write about the problem, not the product. Developers search for problems ("how to automate changelogs") and discover products in the process. If your content answers the problem, the product discovery is natural.

The star count trap

Stars feel meaningful. They're mostly vanity.

A repository with 800 stars and no activity in six months has fewer real users than a 60-star project that ships weekly and responds to issues within a day.

Stars measure a moment of interest. Active users, download counts, and issue volume measure real adoption. Track what matters.

The asset nobody builds early enough

An email list.

100 people who explicitly asked to hear from you when you ship something new are worth more than 1,000 GitHub stars. You own that list. It doesn't depend on an algorithm. You can reach them directly.

Put a simple opt-in in your README: "Get notified of new releases → [link]". A mailing list of 100 engaged users is a real distribution channel for every release you ship.

And when you do email them, have something worth sending. A well-formatted changelog — what's new, what's fixed, what changed — is the most credible thing you can include. If generating that changelog is the friction point, WhatShipped automates it from your git history. One free generation to try it.

The compounding loop

The projects that grow consistently tend to have the same loop running:

Ship something real
Communicate it clearly (changelog, release post)
Share it where the audience is
Respond to the people who show up
Repeat

None of these steps is complicated. The compounding comes from doing all of them consistently, not from any single one being exceptional.

Start with the next release.

How to maintain an open source project without burning out

WhatShipped — Sat, 04 Apr 2026 06:00:00 +0000

Maintaining an open source project is one of the most underrated skills in software development.

It's not about writing the best code. It's about keeping something alive, useful, and sustainable over time — often with limited energy and an inbox that never stops growing.

This is what actually works.

The #1 mistake new maintainers make

Saying yes to everything.

Every feature request, every PR, every issue gets a response, a kind explanation, an attempt at accommodation. It feels like good stewardship. In practice, it attracts more of the same, and it's unsustainable within months.

Scope is a feature. Saying no — clearly and respectfully — is one of the most important skills a maintainer can develop. A project with a clear purpose and explicit boundaries is easier to maintain, easier to contribute to, and more trustworthy to users.

A triage system that scales

The feeling of being overwhelmed by issues usually isn't about volume — it's about the issues being unstructured. Triage doesn't resolve things, but it makes the workload feel finite and actionable.

A minimal label system:

bug — broken behavior, should be fixed
enhancement — potential addition, depends on scope
wontfix — explicitly out of scope, close with a brief explanation
good first issue — low-stakes change, great for new contributors
needs-repro — can't investigate until a reproduction is provided
question — support request, not a bug or feature

Apply labels on first touch. Even if nothing gets resolved immediately, every issue now has a clear status. The backlog stops feeling infinite.

Your README is doing more work than you think

A significant portion of maintainer overhead comes from questions that a good README would answer. Installation issues, usage questions, "is this still maintained?" pings — most of these can be eliminated with a clear, up-to-date README.

The sections worth prioritizing:

One-sentence description of what it does
Quick install / quick start
Explicit statement of project status (active, maintenance-only, archived)
Link to CONTRIBUTING.md

A CONTRIBUTING.md that explains what kinds of PRs you'll accept — and what's out of scope — filters contributors before they spend time on something you won't merge. It's not unwelcoming. It's respectful of their time.

Release often, even for small changes

A project that releases every six weeks looks more alive than one that releases every six months — even if the total code change is equivalent.

Frequent small releases signal: someone is here, paying attention, and shipping. That signal matters to users deciding whether to adopt or continue using your project.

The friction that prevents frequent releases is usually not writing code — it's writing release notes. The fix is maintaining your changelog incrementally, adding entries as you merge changes rather than reconstructing history at release time.

Protecting yourself from burnout

Maintainer burnout is well-documented and genuinely common. The pattern: a project gains traction, issues multiply, the maintainer tries to keep up, eventually disappears, and the project either forks or slowly dies.

Some practices that help:

Set response windows. Only triage issues on certain days. Off-hours expectations compound into exhaustion.

Find trusted collaborators early. One or two people with merge access distributes the load and reduces the single point of failure.

Archive rather than abandon. If you need to step away, archiving the project is a clean, honest signal to users. It's better than a repo that looks active but hasn't had a real response in two years.

Separate identity from the project. Your work is valuable. The maintenance burden of a popular project does not scale with how much you care. Boundaries aren't failures.

The mindset that separates projects that last

The open source projects that survive long-term tend to share one trait: the maintainer treats it like a product, not a hobby.

That means intentional scope decisions, regular releases, clear documentation, and honest communication about what the project is and isn't. Not because it's required, but because it makes the whole thing sustainable.

A changelog is the cheapest version of this signal — it shows users that someone is in charge and paying attention. If you want to generate one from your existing git history, WhatShipped can do it in about a minute. There's 1 free generation to try it.

Maintaining a project well is hard. It's also one of the most compounding skills you can build — because the habits that make a project sustainable tend to make everything around it better too.

AI dev tools — what's actually useful and what's just hype

WhatShipped — Fri, 03 Apr 2026 06:00:00 +0000

There are more AI-powered developer tools launching every week than most people can track. Some of them are genuinely useful. Some are autocomplete with a GPT badge and a $20/month price tag.

This post is about how to tell the difference — and where AI actually earns its place in a development workflow.

The hype vs the reality

The marketing version: "AI writes your code for you."

The actual experience: AI writes a draft of code that you still need to read, evaluate, test, debug, and maintain. If you can't assess the quality of what it generates, you're not going faster — you're accumulating invisible technical debt.

This isn't an argument against AI tools. It's an argument for using them with accurate expectations.

Where AI is genuinely useful in dev workflows

After using these tools seriously for the past couple of years, the pattern that holds up is this: AI is good at translation and drafting. It's not good at understanding and deciding.

Concrete examples where AI earns its place:

Boilerplate — repetitive, predictable code (CRUD endpoints, form validation, test stubs)
Explanation — "what does this unfamiliar code do?" is a great AI prompt
Translation — turning intent ("I want to paginate this query") into a working starting point
Summarization — condensing logs, diffs, commit history into human-readable language
First drafts of tests — the structure is usually right, the edge cases need your judgment

The common thread: you know what good looks like, and AI handles the mechanical part of getting there.

Where AI fails (and people don't say it enough)

Deep codebase knowledge — AI has no idea how your specific system is wired together
Architectural decisions — AI can propose patterns, but can't weigh long-term consequences for your context
Security-sensitive code — generated code often looks correct and isn't. Don't skip review here.
Tasks where "probably right" isn't enough — financial logic, data migrations, auth flows

The failure mode isn't dramatic. It's subtle: code that works in tests, passes review, and causes a production incident six months later because the AI pattern didn't account for your specific edge case.

The right mental model

The best AI dev tools reduce friction on tasks you already understand, freeing your attention for the parts that require actual judgment.

Not: "AI will do this for me."

But: "AI will handle the mechanical part so I can focus on the interesting part."

When a tool is designed around this — augmenting capability rather than replacing judgment — it's usually worth using. When it's designed to skip understanding entirely, it's usually not.

A concrete example: generating changelogs

I built WhatShipped to generate changelogs from git history. It's a small but illustrative case.

The AI doesn't decide what matters. You do. It reads the diff, groups commits by type, and translates technical messages into user-facing language. You get a structured draft in about a minute.

You still review. You still edit. But the blank-page problem — staring at 40 commits trying to figure out what actually changed for users — is gone.

That's the pattern: AI eliminates the mechanical friction, human judgment handles the rest.

The question to ask about any AI dev tool

Before paying for or building around an AI tool, ask:

"Does this make me faster at things I understand, or does it let me skip understanding things?"

If it's the former, it's probably worth it. If it's the latter, the speed is an illusion — and the debt will surface eventually.

The best AI dev tools don't make you a better developer by doing the work for you. They make you a more effective one by removing the parts of the work that don't require you.

That's a meaningful distinction. Worth keeping in mind as the space gets more crowded.

The changelog format that actually works (and why most devs get it wrong)

WhatShipped — Thu, 02 Apr 2026 06:00:00 +0000

There's a 10-year-old document at keepachangelog.com that answers most questions about how to write release notes. Most developers have never read it.

This post is the gist — plus the practical habits that make it stick.

The core principle

A changelog is for humans, not machines.

Your git log is a machine-readable (and developer-readable) record of every change. Your changelog is something different: it's for the person deciding whether to upgrade a dependency, update a package, or trust that a bug they hit last month is finally fixed.

Different audiences. Different documents. Don't conflate them.

The format

The Keep a Changelog format has become a de facto standard for good reason — it's simple, scannable, and answers the key question ("should I upgrade?") in under 10 seconds.

## [1.4.0] - 2025-03-28

### Added
- Dark mode support across all views

### Fixed
- Login failing silently on Safari 16
- Session not persisting after password reset

### Deprecated
- Legacy XML export endpoint (will be removed in v2.0)

### Breaking
- `init()` now requires a config object instead of positional args

The sections:

Added — new features your users can use
Fixed — bugs that are now resolved
Changed — behavior changes that don't break existing usage
Breaking — changes that will break existing integrations
Deprecated — things that still work but are going away
Removed — things that are already gone
Security — always call these out explicitly, even for minor patches

You won't need all of them every release. Pick what applies. Skip the rest.

The mistake most devs make

Writing changelog entries that describe what you did, not what changed for the user.

❌ Refactored auth module to use new token architecture

✅ Fixed: sessions no longer expire unexpectedly after 30 minutes

Both describe the same change. Only one is useful to someone reading your changelog.

This is the hardest mental shift, and it's worth internalizing: every entry should be written from the user's perspective. What did they experience before? What do they experience now?

The Unreleased section

One of the most underused features of this format:

## [Unreleased]

### Added
- Real-time notifications (in progress)

### Fixed
- Avatar not loading in dark mode

Keep this section at the top of your CHANGELOG.md. Add entries to it as you merge pull requests or commit changes. When you cut a release, rename it to the version number and date.

This way your changelog is always in sync with your work, and writing it never feels like a big catch-up task.

When to write the entry

The answer most developers resist: at the same time you write the commit.

Not after the release. Not during the release prep. During the commit, while the context is fresh.

It takes 30 seconds. The alternative is staring at git log a week later trying to reconstruct what you actually changed for the user.

Tools that help

If your history is already messy — commits like fix, wip, final, ok this time — or if you just want to reduce the manual work, AI tools can generate a changelog draft from your git history.

I built WhatShipped specifically for this: connect your GitHub, GitLab, or Bitbucket repo and get a formatted changelog in about a minute. There's 1 free generation to try it without signing up for anything.

The bottom line

A changelog isn't paperwork. It's the cheapest trust signal a maintained project can send.

Users who can see what changed between versions are more likely to upgrade. They open fewer "is this fixed?" issues. They recommend your project to others.

The format is simple. The habit is what takes work. Start with the next release.

Write commit messages your future self will thank you for

WhatShipped — Wed, 01 Apr 2026 06:00:00 +0000

You know the feeling. You open git log three weeks after a sprint and see:

fix
wip
ok
asdf
finally
please work

You have no idea what you were doing. Your changelog is going to be a nightmare. Your coworker's PR review is going to take twice as long.

This is the commit message problem — and the fix is simpler than you think.

Why commit messages matter more than you think

A commit message isn't just a label. It's a unit of communication that travels:

Into your git log and git blame
Into PR descriptions and code reviews
Into your changelog and release notes
Into your team's understanding of why something exists

When commit messages are bad, everything downstream gets harder. When they're good, a lot of things become almost automatic.

The format that works

The simplest improvement you can make is adopting a consistent structure:

<type>: <what changed, in plain English>

Where type is one of:

feat — new feature
fix — bug fix
docs — documentation only
refactor — no behavior change, just restructuring
chore — maintenance, dependency updates
breaking — something that changes existing API or behavior

Real examples:

feat: add CSV export to dashboard
fix: prevent session expiring early on mobile browsers
refactor: extract auth logic into useAuth hook
chore: upgrade eslint to fix security warning
breaking: rename config.apiKey to config.key

These are searchable, parseable, and readable six months later.

The three questions to ask before committing

Before you type the message, ask yourself:

What does this change for the user? Not for you — for them.
Would a teammate understand this without context?
Could this become a changelog line as-is?

If the answer to all three is yes, you have a good commit message. If not, rewrite until it is.

Conventional Commits is worth the 10 minutes

Conventional Commits is a lightweight spec built around the format above. The benefit of adopting a standard (rather than your own variation) is tooling.

Semantic versioning tools can bump your version automatically. Changelog generators can group and format entries. CI pipelines can validate messages before merge.

The spec is simple enough to internalize in one reading. The compounding benefit is significant.

The compound effect

Good commits → readable git log → fast PR reviews → easier changelogs → better release notes → users who understand what changed between versions.

It all starts at the commit message. The earlier in a project you adopt this, the more you get back.

What to do if your history is already a mess

Don't backfill. It's not worth the time.

Just start with the next commit. One good message today is worth more than a weekend of rewriting old ones.

If you need to generate a changelog from a messy history right now — for a release that's going out this week — tools can help. WhatShipped reads your git history and uses AI to produce a readable changelog even when the commits are rough. There's 1 free generation to try it.

The habit

The goal isn't perfection. It's consistency.

Pick the format. Apply it to the next commit. Then the next. After a week it's automatic, and your future self — and your users — will notice.

Why your open source project needs a changelog (and why you keep skipping it)

WhatShipped — Tue, 31 Mar 2026 12:37:17 +0000

You pushed the fix. You tagged the release. You moved on.

Somewhere, a user is opening an issue asking if the bug you fixed three weeks ago is "still being looked at." Another one stopped updating your package because they can't tell what changed and don't want surprises in production.

This is the changelog problem — and it's not about discipline.

The real cost of no changelog

Most developers know they should write changelogs. The intention is there. The execution isn't.

The cost is invisible until it compounds:

Support issues about things you already fixed
Users stuck on old versions because updating feels risky
Contributors who can't tell what's in scope
Your project looking abandoned even when it isn't

A changelog doesn't just document history. It communicates trust. It tells users: someone is in charge here, and they're paying attention.

Why devs skip it

It's not laziness. It's timing and friction.

By the time a release is ready, you've been heads-down for hours or days. Writing a changelog means context-switching back into "communicator mode" at exactly the moment your brain wants to move on.

Add a messy git history — commits like fix, wip, typo, ok now, actually ok now — and the task feels impossible. Where do you even start?

The format that works

Stop thinking of a changelog as documentation. Think of it as a three-question summary:

What did users gain? → Added
What did you fix? → Fixed
What changed that might break things? → Breaking / Changed

A good changelog entry looks like this:

## [1.4.0] — 2025-03-28

### Added
- Export to CSV from the dashboard

### Fixed
- Session expiring too early on mobile browsers

### Breaking
- `config.apiKey` renamed to `config.key`

That's 6 lines. It takes 5 minutes. It answers every question a user might have about upgrading.

The "messy commits" problem

Clean commit history helps, but it's not required. The changelog documents user-facing changes, not your internal process.

A practical approach:

Open your last 20–30 commits
Filter by what a user would actually notice
Group into Added / Fixed / Changed
Write one plain-English line per item

You're translating from developer time to user time. The commit message is for you. The changelog entry is for them.

Make it automatic

If you want to reduce the friction to near zero, tools can help. I built WhatShipped specifically for this: connect your GitHub, GitLab, or Bitbucket repo, and it reads your git history to generate a formatted changelog using AI.

It handles the messy commits. You review and ship.

There's 1 free generation when you sign up — enough to see if it works for your project before committing to anything.

Start with the next release

You don't need to backfill everything. Pick the next release and write five lines before you tag it.

That's the habit. Once it's there, users notice. Issues go down. Trust goes up.

Your code deserves to be understood. A changelog is how that happens.

How to integrate WhatShipped into your project

WhatShipped — Mon, 30 Mar 2026 12:18:06 +0000

You shipped something. Your users have no idea what changed.

WhatShipped turns your git history into a readable changelog — but the real question is: how do you actually get that changelog into your product?

Here's every way you can do it today, and what's coming.

The simplest path: Markdown export

Every changelog you generate on WhatShipped can be exported as a .md file.

Drop it in your repo, your docs folder, your Notion workspace — wherever your users look for updates.

/your-project
  ├── CHANGELOG.md   ← just paste it here
  ├── src/
  └── ...

Zero friction. Works with any stack, any deployment, any workflow. If you just want something out the door, this is your path.

One step up: the WhatShipped API

Generate your changelog programmatically. Hit the API, get structured output, render it however you want.

Your design system, your components, your branding. WhatShipped handles the content — you own the presentation.

A minimal example:

const res = await fetch('https://whatshipped.dev/api/v1/release-notes/generate', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
     "provider": "github",
     "repoFullName": "owner/repo-name",
     "fromRef": "v1.0.0",
     "toRef": "v1.1.0",
     "versionTag": "v1.1.0",
     "productName": "My App",
     "tone": "professional"
  }),
});

const { changelog } = await res.json();

You get back structured content you can render anywhere — a /changelog route, a modal, a sidebar widget. Whatever fits your product.

A pattern I like for Next.js projects

Here's a concrete integration that works well:

Call the WhatShipped API at build time
Store the response as a static JSON file
Render a /changelog route from it

// scripts/fetch-changelog.js
import fs from 'fs';

const res = await fetch('https://whatshipped.dev/api/v1/release-notes/generate', { ... });
const data = await res.json();

fs.writeFileSync('./public/changelog.json', JSON.stringify(data));

// app/changelog/page.jsx
import changelog from '@/public/changelog.json';

export default function ChangelogPage() {
  return (
    <main>
      {changelog.entries.map(entry => (
        <article key={entry.version}>
          <h2>{entry.version}</h2>
          <p>{entry.date}</p>
          <ul>
            {entry.changes.map((change, i) => (
              <li key={i}>{change}</li>
            ))}
          </ul>
        </article>
      ))}
    </main>
  );
}

Your changelog is always in sync with your latest release. No manual work, no copy-pasting.

Coming next: webhooks

The goal is full automation — push to main, changelog gets generated and delivered wherever you need it.

The planned webhook flow looks like this:

git push → WhatShipped webhook → your endpoint
                                      ↓
                          update your changelog page
                          post to Slack
                          update your docs site
                          ...

No human in the loop. The changelog becomes a side effect of shipping, not a task on your to-do list.

If this would unblock your workflow, let me know — real demand shapes the roadmap.

Try it

👉 whatshipped.dev — 1 free generation on signup, no credit card required.

Connect your GitHub repo, point it at a date range or set of commits, and you'll have a changelog in under a minute.

What integration would unblock you the most? Drop a comment — I read everything and it directly influences what I build next.

I built a SaaS for 2 years and never wrote a single changelog. So I automated it.

WhatShipped — Sun, 29 Mar 2026 08:54:41 +0000

Let me be upfront about something embarrassing.

I've been running Geentoo — a platform for connecting project ideas with co-founders and collaborators — for almost two years. Real users, real features shipped, real bugs fixed.

And I have never written a changelog. Not once.
Not a release note. Not a "what's new" email. Not even a pinned post saying "hey, here's what changed this month." Nothing.

Why though?

It's not that I don't care about communicating with users. I do.
The problem is my git history. Here's a completely honest sample of what it looks like:

fix
wip
test
ok now it works
PLEASE work
final
final2
ok this is the real final
asdfgh

Sound familiar?
Every time I thought "I should write a changelog", I'd open the git log, stare at 300+ commits that looked like the above, and immediately feel exhausted. Then I'd close the terminal and go work on something else.
The gap between raw git history and readable release notes is enormous. You have to:

Filter out the noise (CI runs, version bumps, merge commits, "fix" x47)
Group related changes into something coherent
Rewrite everything in plain language your users actually understand
Do this for every release, forever

Nobody has time for that. So I just never did it.

Building the thing I needed

A few months ago I decided to stop feeling guilty about it and just automate it.

The idea was simple: connect to a git repo, pick two refs (a tag, a branch, a SHA — anything), fetch the commits in between, and use an LLM to generate structured release notes from them.

Simple in theory. A few interesting problems in practice.

The filtering problem

The first thing I learned: you can't just dump raw commits into an LLM and expect good output.
A typical commit range for a real project contains a lot of noise:

Merge commits (Merge branch 'feature/x' into main)
Version bumps (chore: bump version to 2.3.1)
CI/CD commits (ci: update pipeline config)
Dependency updates (update lockfile)
And of course, the legendary fix, wip, test

If you feed all of that to an LLM, you get bloated, incoherent output. Garbage in, garbage out.

So WhatShipped has a filtering layer that runs before the model ever sees anything. Noise commits are stripped out. Where available, PR titles are preferred over raw commit messages — they tend to be much more descriptive and intentional.

What reaches the LLM is a clean, curated list of meaningful changes.

The scale problem

Another real issue: large commit ranges.

If you're generating release notes covering 6 months of work, you might have 500+ commits even after filtering. That's too much to process in a single LLM call reliably.

WhatShipped chunks the commits and processes them in parallel, then merges the outputs into a single coherent document. This makes it reliable on large ranges without sacrificing speed.

The provider problem

I didn't want to be locked into one LLM provider, and I suspected users wouldn't either.

WhatShipped supports both Claude (Anthropic) and OpenAI. You choose which one generates your notes. Same filtering pipeline, same output format — just different models under the hood.

Dogfooding it immediately

The first thing I did when the tool was working was run Geentoo's commit history through it.

Two years of wip and fix and ok this is the real final — turned into structured, readable release notes with sections for new features, bug fixes, and performance improvements.

It worked. Actually worked, on a real messy project, not a clean toy repo.

That was the moment I felt confident enough to call it a product.

The business model

I didn't want to build another subscription SaaS that charges $20/month for something you might use twice.

WhatShipped runs on credits. 1 credit = 1 generation. You buy what you need, when you need it.

New accounts get 1 free credit on signup — no card required. Try it on real repos and see if it's useful before spending anything.

What it looks like today

Connects to GitHub, GitLab and Bitbucket
Pick any two git refs as your range
Outputs clean Markdown — ready to paste into your changelog, README, or release page
Works on messy real-world histories, not just clean conventional commits

You can try it at whatshipped.dev.

What I'm looking for

I'm at the very beginning of this. The product is live, the core flow works, and I'm now focused on getting real users and real feedback.

If you've ever skipped writing a changelog because your git history was too messy — I'd genuinely love for you to try it and tell me what you think. What's missing, what's confusing, what would make it actually useful for your workflow.

Every piece of feedback right now is worth more than any feature I could build.

Thanks for reading 🙏