A product conversation that goes full circle. Feedback, public roadmaps and release updates for founders who want to build with their users, from the first request to the email that says it shipped.
- Next.js
- TypeScript
- Firebase
- AI
01The challenge
Feedback is only half the job.
A request arrives in a message. Someone copies it into a backlog. A feature eventually ships, but the person who asked never hears about it. The work is done; the conversation is still unfinished.
Shiplist connects those moments for indie founders and small SaaS teams. A public board captures ideas, a workspace helps make sense of them, and a roadmap makes the next steps visible. Delivery feeds back into a changelog and a notification to the people waiting.
The product challenge is continuity: keeping the original need visible as it moves through different screens, different statuses and different levels of detail. Each surface serves a different task, while the request remains the thread that holds them together.
Listen
A public place to ask, vote and see whether someone else has already raised the same need.
Decide
A working view for the founder, with demand, status and prioritisation visible together.
Deliver
A release that travels back to the people behind the request, through the changelog and an optional email.
02Public feedback
An open door to better ideas.
The public board is the first point of contact. A prominent input invites a new idea, while search and sorting let visitors check what already exists. Votes sit beside the request they belong to, so support is visible without opening a separate detail page.
Participation does not require an account. Email is a separate, optional step for people who want to hear when a request ships. That distinction matters: expressing a need and subscribing to an update are two different decisions.
Status labels and recently shipped work give the board context. It is a place to see what the product is doing with feedback, as well as somewhere to leave it.
A small first step.
The request field and voting controls are available where the ideas already live. Visitors can contribute without first learning the founder's planning workflow.
Progress in plain sight.
Planned and shipped labels make the team's response legible. The same navigation connects feedback with the roadmap and release history.
03From feedback to focus
Turn noise into a next step.
On the other side of the board, the founder needs a working queue. Requests can overlap, popular ideas can be expensive, and new submissions may need review before they become public. The dashboard brings these decisions into one list.
Vote counts express demand. Status filters separate review from delivery. Pinned items stay visible, while AI priority badges add another signal alongside the original request. Duplicate detection supports merging related ideas instead of splitting the same conversation across several entries.
The hierarchy keeps the request title at the centre. Votes, tags, comments and priority surround it as supporting context, helping the person reviewing the queue compare items without losing the language users actually used.
Feedback / 00:09
Let demand become a decision.
Vote on an idea, pin it, then promote it to the roadmap. Recorded in the original Shiplist admin UI with local demo data.
Keep the signal.
Votes remain attached to a clear request. Merging duplicates brings related demand back together.
Make review explicit.
Pending review is a visible state, giving the founder a place to moderate submissions before publication.
Support judgement.
AI contributes prioritisation signals. The founder still chooses what belongs on the roadmap.
04Planning in public
A plan people can follow.
A request and a delivery commitment are different things. Promoting an idea to the roadmap makes that change explicit, connecting the feedback to a piece of planned work.
The internal kanban gives the founder a practical way to manage that work. Planned, in progress and shipped columns make status spatial. Priority, progress and comments stay close to each card, while a reminder above the board explains what happens when an item ships.
The public roadmap carries the same progression into a simpler view. Visitors can understand what is coming, what is being built and what has landed, without needing access to the administration workspace.
Roadmap / 00:11
Move the work forward.
Drag a card from Planned to In progress, add a vote and move it to Shipped. Recorded in the original Shiplist admin UI with local demo data.
05Closing the loop
Shipping is a reply.
Moving a linked roadmap item to Shipped starts the return journey. Shiplist creates a changelog announcement, updates the original idea and notifies the people who asked to hear back. The release becomes part of the feedback conversation.
The two outputs have different jobs. The changelog is a public record that anyone can browse. The email is personal and specific: it names the requested feature, acknowledges the interest behind it and points to the release.
The message also explains why it arrived and includes an unsubscribe link. That context is part of the experience. A useful notification should connect the request to its answer without making the recipient wonder how they ended up on a mailing list.
06The interface
One language. Two surfaces.
The interface combines quiet surfaces with a clear action colour. Blue identifies the next action; status labels add meaning without relying on colour alone. Rounded cards organise dense information, while borders and spacing separate controls from the requests they act on.
Light and dark themes preserve the same hierarchy. The layout, controls and information stay in place as the surface changes. A founder can scan the same queue in either mode without relearning it.
This consistency also connects the private workspace to the public product. Feedback, roadmap and changelog feel like parts of one service, even when the density and available actions change to suit their audience.
Hierarchy before decoration.
Titles carry the request. Small badges, secondary text and consistent spacing hold the supporting information.
Colour with a job.
Blue highlights actions; labelled status colours distinguish progress. Neutral surfaces give both enough room to be recognised at a glance.
Familiar across views.
Repeated navigation and card patterns connect collection, planning and communication without making every screen equally dense.
07Design meets engineering
The connection is the product.
The engineering follows the user journey. Ideas, roadmap items and announcements are linked records, allowing a change in delivery status to carry meaning across the service. The interface is built with Next.js and TypeScript, with Firebase supporting authentication and stored product data.
The release pipeline brings the connected experience together: it creates the announcement, updates the linked idea and sends through Resend to opted-in subscribers. It checks notification records and unsubscribe state before choosing recipients.
These connections support the product promise. A founder should not have to maintain a separate list of people to contact after a release, or manually reconcile the public board with the changelog. The handoff is part of shipping the work.
- 01Idea
- 02Roadmap
- 03Shipped
- 04Changelog
- 05Reply
Connected records.
The original idea stays linked to the roadmap item and the release announcement, preserving context across the journey.
Permission to notify.
Optional email subscriptions and an unsubscribe path keep release communication tied to a specific user request.
Bring it into the workflow.
Embeddable boards and Slack notifications let feedback reach teams and users in places they already work.
08The outcome
Built to keep listening.
Shiplist is live, with a public feedback board, roadmap and changelog of its own. The product uses the same loop it offers to other founders: collect a need, make the next step visible, then show what shipped.
The result is a connected product experience spanning public participation, founder decisions and release communication. The case study shows that workflow using the product's demonstration screens, rather than treating sample votes or requests as adoption metrics.
The useful outcome is the continuity between these moments. People can see where their request went, founders have a place to decide what happens next, and delivery becomes an answer that can lead to the next conversation.
