Every product team eventually wants a place for customers to send feature requests and vote on them. The usual options are a spreadsheet nobody looks at, a pricey SaaS tool, or an engineering ticket that never gets prioritized. So I ran a small experiment: I connected my assistant to a Server4Agent server and asked it to build a feedback board from scratch.
This is a build-in-public walkthrough of what the agent produced, how it got there, and where the private-to-public flow made the whole thing feel safe to ship.
What I asked for
The prompt was deliberately plain, the way a non-engineer would describe it:
> Build me a customer feedback board. People should be able to submit ideas, upvote existing ones, and see a status like planned, in progress, or shipped. Give me a private link first so I can check it before customers see it.
No stack, no schema, no wireframe. The point was to see whether an agent could turn an outcome into a running app without me making a dozen technical decisions.
What the agent built
Within a single session, the agent returned a URL to a working board. Opening it, I found:
- A submission form with a title, a description, and light validation so empty ideas could not be posted.
- A list of ideas sorted by vote count, each with an upvote button.
- A status label on every idea: under review, planned, in progress, or shipped.
- A simple filter to show only ideas in a given status.
- An admin view where I could change a status or hide spam.
It was not a toy. It was a small, real web app with persistent data, running at a stable URL.
The build, step by step
Watching the workspace, the sequence was roughly this:
- The agent created a private project inside my server and gave it a stable URL.
- It scaffolded a small web app and a data layer to hold submissions and votes.
- It wrote the submission form, the voting logic, and the status workflow.
- It ran the app in the workspace and checked that submissions persisted.
- It handed me the private URL and a short summary of what it had built.
The part that stood out was step four. The agent did not just generate code and hope. It ran the app in its own persistent workspace, submitted a test idea, and confirmed the vote count updated before telling me it was done.
Reviewing it in private
Because the project was private by default, I was the only one who could reach the URL. That let me poke at it honestly.
I found two things I did not like: the empty state said nothing when there were no ideas yet, and the upvote button let me vote for the same idea repeatedly. I described both in plain language. The agent revised the same project — added a friendly empty state and limited votes to one per idea per browser — and the URL never changed. This is exactly the review loop that private-by-default makes possible: iterate in private until it is genuinely ready.
Going from private to public
Once the board felt right, going live was a single decision. I set the project's visibility to public, and the same URL I had been testing started serving customers. No new link to send around, no separate deploy step, no re-check to make sure the live version matched the one I approved.
That is the whole pitch in one action: the thing I reviewed is the thing that shipped. A URL is the artifact that makes agent-built software real, and here it went from private draft to public tool without changing underneath me.
What I would change
It was not perfect, and pretending otherwise would miss the point of a build-in-public post:
- The design was clean but generic. Matching it to a brand took another round of plain-language requests.
- I would want email notifications when a new idea comes in, which the agent could add but I did not ask for in the first pass.
- Moderation was basic. For a high-traffic board I would want rate limiting and spam controls, which is a reasonable next iteration.
None of these were blockers. They were the normal backlog of a v1, and the difference is that this v1 was live and usable the same afternoon.
Why this matters
A feedback board is a small thing. But it is exactly the kind of small thing that never gets built because it is too minor for the engineering roadmap and too specific for an off-the-shelf tool. That is the gap agents fill: the internal and customer-facing tools teams should not spend sprints on can now be described, reviewed, and shipped in an afternoon.
The board is one example. The same loop builds a changelog, an intake form, a status page, or a small dashboard. If you want a starting point, the template gallery and the showcase have more.
FAQ
How long did the whole thing take?
A single working session for the first version, plus a short second round to fix the empty state and the voting bug. Both happened in the same project without changing the URL.
Did I have to choose a tech stack?
No. The prompt described the outcome, and the agent made the technical choices. I only weighed in on what the app should do, not how it was built.
Was the board public while I was testing?
No. It stayed private by default, so only I could reach the URL until I explicitly set it public.
Could an engineer take this over later?
Yes. The project is a persistent workspace with real files and logs, so an engineer can open it, read the code, and extend it without rebuilding from scratch.
Related reading
- I asked Server4Agent to build a Stripe webhook debugger
- Turning a CSV cleanup task into a reusable web app
- Why every AI agent should be able to return a URL
- Browse templates