ShipLog Turns SaaS Feedback Into a Shipping Loop

A feature request arrives in a direct message, another appears in a support thread, and a third gets added to a Notion page. Months later, a founder is trying to decide what to build next from a collection of half-maintained notes. The problem is not a lack of ideas. It is the lack of a reliable way to collect, sort, and close the loop with the people who made them.

ShipLog is built around that narrower problem. It combines a public feedback board, a changelog, an embeddable widget, and programmatic access through an API and MCP server. The intended user is a solo SaaS founder who wants customer signals in one place without adopting a large product management system.

A public place for requests

The centre of ShipLog is a shareable feedback board. Users can submit ideas and vote on existing requests, while the founder assigns categories and tracks statuses such as planned, in progress, or shipped. That changes the unit of work from a private note to a visible request with some evidence behind it.

This does not decide what a founder should build. Votes are still an imperfect measure of importance, and a public board can collect requests that do not fit the product's direction. It does, however, make the decision process less dependent on memory. A founder can see which requests are attracting attention and give users a place to check whether an idea is being considered.

The board can also be placed inside the product through a widget. The landing page describes this as a script based installation with no dependencies, Shadow DOM isolation, theme customisation, and a What's New badge. In practical terms, that gives a small product an in-app feedback entry point instead of sending every user to a separate page. The tradeoff is that installing it still requires access to the application and enough control to add the script.

Changelog closes the loop

Collecting votes only solves half of the communication problem. Users also need to know when a requested change has shipped. ShipLog includes a public changelog with Markdown support, category badges for changes such as new, improved, and fixed, and an RSS feed for subscribers.

That makes the workflow fairly direct: a user submits or votes on a request, the founder changes its status during development, and the completed work becomes a changelog entry. The board can show progress while the changelog provides a readable record of what has actually been released.

This is useful for a founder who currently announces releases inconsistently or expects users to notice changes on their own. It is less useful if the product needs a sophisticated announcement system. The supplied description specifically says ShipLog does not include email notifications to voters. An RSS feed is helpful for subscribers, but it is not a substitute for directly notifying everyone who supported a request.

The unusual part is agent access

ShipLog also exposes its feedback data and publishing actions to coding agents. Its remote MCP server is available on every plan, and the service provides tools for summarising feedback, searching requests, triaging them, and writing changelog entries. The REST API offers another route for integrations.

The proposed workflow is clear. A founder asks an MCP client what users are requesting most, receives a summary of the board, then asks the agent to update a request or create a changelog entry after shipping it. That could remove some context switching for developers who already work through an AI coding environment.

There is an important boundary here. The agent can work with the information in ShipLog, but it cannot make the underlying product judgment for the founder. It also introduces the usual need to handle project API keys carefully. The service is therefore best understood as a structured feedback source for an agent, not an autonomous product manager.

Where ShipLog fits, and where it does not

ShipLog is a free plan with a paid upgrade. The free option includes the main product areas, while the developer describes a limit on the number of feedback items it can hold. The paid option expands that capacity and includes the widget, API, and MCP access as part of the same product rather than splitting those capabilities across feature tiers.

The missing pieces matter more than the pricing structure for some teams. ShipLog does not provide email notifications to voters, SSO, or audit logs. Those omissions make it a poor fit for organisations that need formal access controls, compliance history, or built-in campaign-style communication. It also runs on the web and through its API, so a founder looking for a native desktop workflow will not find one here.

For solo SaaS founders tracking requests across direct messages, memory, and a document, ShipLog is a focused feedback board and changelog tool with a useful agent interface. It is not a full customer support system or an enterprise feedback programme. Choose it if your main need is to collect public signals, show what is being built, and publish what shipped. Avoid it if voter notifications, identity management, or auditability are requirements rather than nice additions.