CommitPosts
AI changelog generator that turns GitHub PRs and commits into publishable release notes.
Tagline
Your code ships. We write the changelog.
Turn GitHub activity into a public changelog fast.
Stop writing release notes by hand.
Fewer support pings after every ship.
The fastest way to turn GitHub activity into a customer-facing changelog.
The product is built around direct GitHub sync, AI generation, and publish-ready output, so speed is the clearest value proposition.
An alternative to manual release notes written by product marketers and founders.
The page explicitly frames the problem as 'Stop writing changelogs by hand' and shows the before/after from raw PR data to a polished entry, which makes automation the replacement for a tedious manual workflow.
A support-deflection and retention tool, not just a changelog page.
The page repeatedly ties changelogs to fewer 'what changed?' tickets, better user awareness, and subscriber notifications, which positions the product as customer communication infrastructure.
Primary user
Founder or product marketer at a GitHub-based SaaS startup shipping weekly releases
ICP #1
Solo founder of an early-stage B2B SaaS with 1-10 employees
Pain
They ship constantly but forget to communicate updates, so prospects, users, and investors see a stale product.
Why this solves
CommitPosts turns existing GitHub activity into a public changelog with almost no process overhead, making the product look active without adding manual writing work.
ICP #2
Support lead at a 20-100 person SaaS company
Pain
The team keeps getting repetitive tickets and Slack questions about new features, bug fixes, and behavior changes after releases.
Why this solves
The public changelog gives support a single shareable source of truth, and subscriber notifications reduce repeat explanations after every deploy.
ICP #3
Product marketer at a devtool or B2B SaaS company
Pain
Release notes are usually assembled by hand from messy PR titles and commit messages, which slows down launches and produces inconsistent messaging.
Why this solves
CommitPosts automates the translation from engineering language to customer language, while still allowing edits before publishing to maintain brand voice.
Strengths
- +The hero message is brutally clear and immediately understandable: it turns code changes into changelogs.
- +The before/after example is strong because it proves the AI output quality with a real GitHub-style PR snippet.
- +The page addresses multiple stakeholders separately: founders, support teams, developers, and users.
Weaknesses
- −It feels too generic in the AI layer; it never explains what makes the output better than a human-written changelog beyond speed.
- −The product sounds like a feature inside a release notes tool, but the landing page does not differentiate hard enough against Headway, Beamer, or AnnounceKit.
- −The public changelog page is shown as a URL pattern, but there is no visual demo of the actual page experience or subscriber flow.
- −The pricing section is functional but not persuasive; it lists limits without framing value or explaining why Solo is worth $9.
- −The 'Team' plan is marked coming soon, which weakens trust for buyers evaluating a serious team workflow.
Fix these
- Add a live interactive demo showing a real GitHub PR being turned into a changelog entry in one click.
- Position more aggressively against manual workflows and release-note tools by naming the exact alternative: 'stop copying PRs into Notion, Slack, or docs.'
- Show the public changelog page UI, email notification example, and subscriber signup flow instead of only describing them.
- Add proof points around time saved, support tickets reduced, or publishing frequency increased to make the value concrete.
- Replace the generic privacy FAQ accordion with a short, trust-building summary of permissions and data handling above the fold.
Drop-in replacement copy
Headline
GitHub PRs to public changelogs
Turn merged code into customer-ready release notes.
Write release notes from GitHub activity
Connect a repo and pull merged PRs, labels, descriptions, and commits. CommitPosts turns the technical mess into a draft customers can actually read.
Edit before anything goes live
The AI draft is a starting point, not a final answer. Clean up tone, trim details, or add context before publishing to your public changelog page.
Keep users informed automatically
Publish once and let subscribers know. Every new changelog entry can trigger email notifications, so updates reach users without extra manual work.
Stop support from repeating itself
A public changelog gives your team one link for every 'what changed?' question. Auto-categorization makes it easy to scan features, fixes, improvements, and breaking changes.
FAQ
Does CommitPosts replace a human writer?
It replaces the blank-page work, not your judgment. The draft comes from GitHub, but you can edit it before publishing so the final note matches your voice.
What GitHub data do you use?
It pulls merged PR titles, descriptions, labels, and branch commits from connected repositories. That gives the model enough context to draft a usable customer-facing entry.
Can I control what gets published?
Yes. Drafts are editable before they go live, and the changelog only publishes when you choose to publish it. You stay in control of wording and timing.
How does this help support?
Instead of answering the same change-related questions in Slack or email, your team can point users to one public page. Subscriber notifications also reduce the chance people miss important updates.
Is this only for startups?
No, but startups feel the pain first. Any GitHub-based SaaS team shipping often can use it, especially if nobody owns release communication full-time.
Most changelogs are written twice. Once by engineering in PRs. Once by someone who has to translate that into customer language. CommitPosts connects to GitHub, pulls merged PRs, and turns them into publishable release notes. Ship it and move on.
Your release notes are already there. In GitHub. In the merged PRs. In the commits. CommitPosts turns that mess into a public changelog page, with editing before publish and email notifications for subscribers. No Notion copy-paste ritual.
I kept seeing the same problem. Teams ship every week, but the changelog is still a sad manual chore at the end of the day. So I built CommitPosts: GitHub in, customer-facing release notes out. The boring stuff should not block shipping.
I wanted a changelog that writes itself. Not 'AI' in the abstract. Just: connect repo, sync merged PRs, draft the update, edit if needed, publish. That’s CommitPosts. If you ship weekly and forget to announce it, this is for you.
Stop copying PRs into Notion. Stop turning commit messages into English at 11pm. Stop forgetting to tell users what changed. CommitPosts reads GitHub and drafts the changelog for you. Better for founders. Better for support. Better for users.
Support hates the same question: "What changed?" "Did you ship a fix?" "Where are the release notes?" CommitPosts gives you a public changelog + subscriber emails, so one link answers it all.
Watch a PR become release notes. Merged PR in GitHub -> AI draft -> quick edit -> publishable changelog entry. That’s the product. If your team already ships in GitHub, there’s no reason to rewrite everything by hand.
This is the whole workflow. 1. Connect GitHub repo 2. Pull merged PRs and commits 3. Auto-categorize updates 4. Edit the draft 5. Publish to a public changelog page 6. Email subscribers automatically Less ceremony. More shipping.
The best feedback is silence. When users can find the changelog, support stops repeating itself. When founders can publish fast, the product looks alive. When release notes take 5 minutes, they actually happen. That’s the point.
Weekly shipping needs weekly proof. If you’re shipping features and bugs fixes every week, your public changelog should not be stale. CommitPosts keeps the page current from the same place your team already works: GitHub.
Angle: manual release notes are wasted founder time
Most startups waste a weird amount of time writing release notes by hand. Engineering writes the work in PRs. Product or marketing rewrites it for customers. Someone pastes it into Notion, docs, or a changelog tool. Then it gets published late, or not at all. I built CommitPosts because I wanted the shortest path from GitHub activity to customer-facing updates. Connect your repo. Pull merged PRs and commits. Turn them into publishable changelog entries. Edit if needed. Publish. If you ship weekly, this is one of those annoying workflows that should not still be manual. It is not strategic. It is translation work. Your code ships. We write the changelog.
Angle: support deflection through a public source of truth
A lot of support pain is really communication pain. Users ask what changed because they could not find it. Teams answer the same questions because the release notes live in too many places. The result is repeat work after every deploy. CommitPosts turns GitHub changes into a public changelog page and sends subscriber emails when new entries go live. That means one place for: - new features - bug fixes - improvements - breaking changes It is not just a nice page for the website. It is a cheaper support loop. If your team keeps getting asked “what changed?”, the answer is usually not “ship more.” It is “publish better.”
Angle: GitHub-native workflow beats generic changelog tools
Most changelog tools assume someone will manually write the update. That is the bottleneck. CommitPosts starts where your team already works: GitHub. Merged PRs, descriptions, labels, and commits become the source material. The AI drafts the customer-facing version. You edit it. Then it goes live on a public page with subscriber notifications. That workflow matters because it matches how modern SaaS teams actually ship. No extra doc ritual. No separate writing process. No need to chase engineers for context every time. If your releases are already in GitHub, the fastest changelog is the one that reads GitHub directly.
No visuals for this kit yet.
Tagline
GitHub PRs to customer-ready changelogs
Description
Connect GitHub, turn merged PRs into publishable release notes, and send updates to subscribers. Edit before publishing, auto-categorize changes, and keep your changelog current without writing it twice.
Maker's first comment
I built CommitPosts because I kept seeing the same annoying gap: teams ship in GitHub, but the customer-facing changelog is still a separate manual job. That usually means someone copies PR titles into Notion, rewrites commit spam into English, and then forgets to publish until the release is already old news. CommitPosts is my attempt to remove that friction. It pulls merged PRs and commits from GitHub, drafts user-facing changelog entries, lets you edit them, and publishes to a public page with subscriber emails. The goal is simple: if you already ship weekly, your updates should keep up without adding another writing process. I’m especially curious whether the output feels genuinely publish-ready for teams that care about tone, and whether the public page experience makes this feel like infrastructure instead of just another AI writing tool.
Pinned maker comment
Would love feedback on three things: the quality of the AI changelog drafts, the public changelog page UX, and whether the positioning is strong enough against manual release note workflows.
Meta
Stop writing release notes by hand.
Hypothesis: founders and product marketers shipping weekly will convert if we promise less manual translation work and a public changelog that stays current from GitHub activity. Connect GitHub. Draft changelog entries from merged PRs. Edit, publish, notify subscribers. Built for SaaS teams that ship often and hate the release-notes chore.
Google Search
GitHub changelog automation
Hypothesis: searchers looking for changelog tools want a GitHub-native workflow, not another blank page to write into. CommitPosts pulls merged PRs and commits, drafts customer-ready release notes, and publishes a public changelog with email notifications. Less writing. Fewer missed updates.
Reddit Promoted
If you ship weekly, this saves time.
Hypothesis: indie SaaS founders and small product teams will click if the message is blunt: the changelog is already in GitHub, and the tool just turns it into something users can read. CommitPosts syncs merged PRs, drafts release notes, and lets you publish after a quick edit.
Subreddits
r/SideProject
Show the before/after: raw GitHub PRs turned into a polished changelog entry in one click.
Rules: No obvious spam, include build story and product details, ask for feedback, engage in comments.
r/indiehackers
Talk about removing the manual release-notes step for founders shipping weekly.
Rules: Share lessons learned, not just a link; be transparent; no drive-by promotion.
r/microsaas
Target solo founders with tiny teams who need a public changelog without hiring writers.
Rules: Keep it practical, show pricing and workflow, avoid low-effort self-promo.
r/EntrepreneurRideAlong
Frame it as a shipping problem and show the product evolving from pain to solution.
Rules: Must be a journey post, not an ad; story-first; community feedback encouraged.
r/SaaS
Position it as support deflection and customer communication infrastructure.
Rules: Higher scrutiny on promotion; lead with the problem and operational impact, not features.
Communities
Post a build log, then reply to every comment with specifics about workflow, pricing, and what changed based on feedback.
Launch with a brutally honest title about manual release notes and be ready to discuss implementation details, tradeoffs, and why GitHub-native matters.
Coordinate maker comments, early upvotes, and direct outreach to existing GitHub-based founders the same morning.
Slack groups for founders and SaaS operators
Join 10-20 relevant founder or product Slack groups, share the demo only after answering release-note and support questions for others.
Cold outreach template
Hey {firstName} — saw {context} and thought of CommitPosts. If you’re still writing release notes by hand, it pulls merged PRs from GitHub and drafts publish-ready changelog entries in minutes. Happy to give you early access if you want to try it on a real repo.
Product Hunt timing
Launch on a Tuesday or Wednesday, 9–11am PT, after warming up 20–30 likely users the day before. That window gives you a full workday for comments, replies, and second-wave traffic without getting buried under weekend noise.
Indie Hackers post ideas
- 01I stopped rewriting GitHub PRs into release notes by hand
- 02Built a GitHub-native changelog tool because support kept asking the same question
- 03From merged PRs to publishable changelog entries: what actually worked
Competitor alternatives
Current tone of voice
Confident, concise, and slightly developer-friendly; for example: 'Your code ships. We write the changelog.' and 'Ship it and move on.'
Your kit is ready. Sign up free to unlock, takes 10 seconds.
7 more X posts · 2 LinkedIn · Product Hunt copy · ad hooks · 100-user playbook · landing critique