Hello, FeedLog

odeds — Sun, 26 Apr 2026 07:45:50 +0000

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.

Enhancing Vue Development with the Render Paint Flashing Plugin

odeds — Thu, 22 Jun 2023 17:38:32 +0000

It’s important to note that the Render Paint Flashing Plugin is designed to work exclusively in Vue development mode.

As Vue developers, optimizing performance and minimizing unnecessary re-renders is crucial to building high-quality applications. In this article, we’ll explore the Render Paint Flashing Plugin, a powerful tool that enhances component development in Vue 3 applications. Inspired by the Chrome DevTools Rendering paint flashing panel, this plugin provides a visual indicator for re-rendered components, enabling developers to identify potential performance bottlenecks and optimize their Vue applications.

Visual Indicator: Identifying Areas for Optimization

The key feature of the Render Paint Flashing Plugin is its visual indicator that highlights re-rendered components on the screen. This feature provides developers with an intuitive way to identify areas that require optimization in their Vue applications.

By enabling the Render Paint Flashing Plugin, you can observe which components are being re-rendered during different interactions or state changes. The plugin applies a flashing effect to these components, making them easily distinguishable.

To get started with the Render Paint Flashing Plugin, visit the GitHub repository.