Less depth per module
A dedicated roadmap tool has segmentation and revenue-weighted voting. A dedicated status product checks from several regions and sits on your own domain. One product covering three jobs is never the deepest at any of them.
The workflow
Request, ship, announce. Then it happens again.
Three modules is an implementation detail. What Feedfast actually is, is one loop: users ask for something, you ship it, publishing the release note tells everyone, and the person who asked gets a reply — which is exactly why they ask again.
Six stages
What actually happens, in order
Nothing here is unusual on its own. The difference is that no step needs you to remember to do the next one.
Someone asks
A user posts on your public board, or submits through the widget embedded in your app. No account, no login — a title and a category. If the request already exists they vote on it instead, which is the number you actually needed.You decide, in public
Move it to Planned, In progress, or Declined with a reason. The status is the answer: people stop emailing to ask, and the ones who voted can see where their request sits without you writing to anyone.You ship it
Whatever that takes — this is the part Feedfast has no opinion about. Mark the post Done when it's out.Done pre-fills the release note
One click turns the request into a changelog entry: title carried over, the post linked, and the tag mapped from the category — a bug becomes Fixed, a request becomes New. Or your coding agent does it through the MCP server without you leaving the editor.Publishing is announcing
The entry lands on your public page, in your RSS feed, and in the embedded "What's new" widget with an unread dot — at the same moment, from one action. There is no second step to forget.The person who asked gets told
Their request carries a public reply linking the release. That's the moment that decides whether they ever post again — and whether the next person watching bothers to.
Stages four to six are the whole product
Collecting feedback is easy, and every tool does it. Turning a resolved request into a published release note, and that release note into a reply to the person who asked, is the part that gets dropped first when you’re busy — so it’s the part that has to be one click instead of three tools.
Why it holds
The loop feeds itself
Each turn makes the next one more likely, which is what a compounding system looks like from the inside.
- A reply on a shipped request is the strongest argument that posting is worth it
- Votes tell you which request to ship next, so the queue orders itself
- The widget's unread dot brings people back into the product to read the note
- A public board doubles as a roadmap, so nobody asks you for one separately
- Declining with a reason costs you less than silence and earns more trust
- Incidents and maintenance reuse the same subscriber list, not a second one
The three modules exist because the loop needs all three: the board to collect, the changelog to announce, and uptime for the days the news is bad.
When it isn't for you
The honest caveats
The loop is the trade. Here's what you give up to get it.
Built for small teams
There are no per-person accounts and no custom domains yet. If either is a hard requirement today, this isn’t the right tool — better you find that out on this page than after you’ve moved your board across.
Questions
Common questions
Why does closing the loop matter so much?
Because feedback boards die from silence, not from lack of features. Someone who posts and hears nothing concludes that posting does nothing, and they're right. Someone who gets a reply linking to the release they asked for tells you the next thing too — and everyone reading the board can see that requests here actually go somewhere.
What breaks the loop when you use separate tools?
Every join becomes a manual copy. Marking something done in one tool doesn't write a release note in another, publishing a note doesn't notify the requester, and nothing links the release back to the request. Each step works right up until the week you're busy, which is every week eventually.
Where does uptime fit into a feedback loop?
It's the same promise pointed at bad news instead of good. A status page and a changelog are both you telling users what's happening before they have to ask, and incidents are the case where saying nothing costs the most. It's also the same subscriber list, so nobody has to sign up twice.
Can an AI agent run this loop?
Most of it. The MCP server lets Claude Code, Cursor or any MCP client read the board, resolve a post, publish the entry and schedule maintenance — so the agent that helped you fix something can announce it. It has no access to your code or your deploys, and it asks before anything goes public.
How long does it take to set up?
About five minutes for the parts that matter: create a project, point a monitor at your site, and paste one script tag. The board and the changelog are live on your public hub immediately, and the widget appears wherever you put the attribute.
Start the loop with one request
Free for one project, every module included. Put the board up today and the first request usually arrives before you've finished setting up the rest.