Hello, FeedLog

This is our hello world post: a short answer to why FeedLog exists and who gets the most from it. If our homepage line resonates (“from issue chaos to changelogs users love”), this is the story behind it. For a full walkthrough from a messy GitHub issue to a changelog entry, open See the transformation in action on our homepage.

Why we built it

Most teams don’t fail at shipping. They fail at closing the loop: turning what actually merged into something customers and users can find, without another evening of manual release notes or copying tickets into a second system.

We kept seeing the same pattern: engineering lives in GitHub issues and PRs, while “public updates” live in a changelog tool, doc, or CMS someone has to babysit. That seam creates duplicate work, stale pages, and the same “what changed?” questions in email and support.

FeedLog is our attempt to keep intake, feedback, and publish where the work already happens in the repo, so user-facing comms isn’t the task that always slips. Rough work stays in issues; when you’re ready, you ship the words with @feedlog publish (Full command list). Nothing user-facing goes live until you approve it, so raw technical titles don’t have to hit end users by accident.

Who it’s best for

FeedLog is aimed at small product teams (about 2 to 15 people) who ship on GitHub and want feedback and a public changelog without maintaining a separate marketer-first CMS or retyping work into Notion or Confluence.

You’re a great fit if:

• Developers own the loop: you’d rather publish from an issue than log into another dashboard to “compose” an update.
• You want less context switching: plan and ship in GitHub, not in a second tool that goes out of sync with reality.
• You care about trust and clarity: users get clear release notes in one place, with fewer confused pings and a steadier sense that the product is moving.

We’re GitHub-native today (OAuth, issues, workflow). If your team doesn’t live in GitHub, we’re probably not the right tool yet, and we’d rather say that upfront than waste your time.

Less context switching, more shipping

Our homepage puts it plainly: the same “what changed?” questions and copy-paste into a second tool drain time you wanted for shipping. FeedLog is built around less context switching, more shipping:

• No extra CMS to manage for every release. Drafts tie back to the issue you already have open.
• Stay in GitHub for the loop that matters: when the draft looks right, @feedlog publish (Full command list), not another tab to hunt down.
• Setup in under five minutes is the bar we hold ourselves to, because a tool you don’t adopt doesn’t help anyone.

That’s the same wedge we care about in positioning: feedback and changelog in one product for small teams, with GitHub as the source of truth, so you’re not fighting adoption from engineers who hate “one more app.”

User updates and feedback, not two separate chores

User updates shouldn’t be a parallel track that only happens when someone remembers. When issues turn into draft posts you review, the changelog becomes a natural extension of how you already ship, not a weekend cleanup task.

Feedback that stays tied to issues keeps signal close to where you fix things. Users get a real changelog they can rely on; your team spends less energy re-explaining releases in scattered threads.

We’re biased toward human-in-the-loop: automation helps with drafting and tone, but you decide when something is ready for users. That’s how we square “move fast” with “don’t embarrass us with a cryptic issue title on the marketing site.”

If this sounds like your team, we’d love you to try FeedLog: free to start, same story you’ll see on the homepage. When you’re ready, we’re here for the harsh feedback that makes the product better, and you can see how we use FeedLog ourselves in Do what you preach on that page. For setup, pricing, and how drafts compare to public posts, open Frequently asked questions.