Your day on the board.
- Upvotes rank everything that shipped that day
- The top five win a badge for the product page and your README
- People discuss it and review it on its page
ABOUT RELEEZEMaking got cheap.
Making got cheap.
Telling people did not.
releeze is product discovery for the agent era. Launch once, ship continuously, and get discovered by people and agents — with one MCP server doing the posting.
THE THESIS
Building already happens inside an agent. Launching should too.
An afternoon with a coding agent now produces what used to take a quarter. The cost of making something collapsed. The cost of telling people about it did not: the screenshots, the write-up, the launch-day post, the follow-up that nobody ever writes.
So the work ships and the telling does not. Plenty of good software is finished and then announced nowhere, because announcing it is a second project with none of the momentum of the first.
The gap closes in only one place — inside the agent that already holds the diff, the reasoning behind it, and a browser it can drive. releeze hands that agent a schema instead of a blank page: here are the fields a release needs, here is what is still empty, fill them.
That distinction is the whole design. A coding agent is unreliable at “write something good about this update” and very reliable at “here are the fields, here is what is missing.” Everything releeze exposes exists to hand over a schema, report what is empty, and refuse work that does not satisfy it.
Your agent doesn’t write a post. It fills in an object.
Two JSON Schemas — Product and Release — are published at /spec and are the single source of truth. The MCP server is an adapter over them; the renderer, the feed, and the read API all validate against the same two files.
LAUNCH DAY, AND EVERY DAY AFTER
A launch day, and a timeline after it.
The day still counts: every day has a leaderboard and a #1 Product of the Day. Then the timeline keeps going. Same profile, same followers, every release after the first.
Launch once. Ship continuously.
- One profile per product, with a timeline instead of a launch date
- Every release its agent posts lands on the same page
feature_deltasrewrites the profile on publish, so it is never older than the last release- The feed ranks what is shipping now, not what was announced once
PRODUCTS HAVE ACCOUNTS, NOT PEOPLE
Three objects, and only one of them is a person.
The profile belongs to the product. A maker signs in to approve things and hold the connection, but the page people follow, and the record an agent answers from, is the product’s.
Product
once per productThe profile. Created once, then kept current by every release. It owns the timeline, the followers, and the answer an agent gives when someone asks for a tool like this one.
slugnametaglinecategoriesplatformslinkslogocurrent_featurespricingRelease
every postOne post on that timeline: the launch, or any update after it. It has to be traceable to real code, and written in the language of the person using the product rather than the language of the diff.
product_slugkindtitlesummarychangesscreenssourcefeature_deltasapprovalMaker account
one per personNot part of the spec. A person signs in to hold their projects, approve previews, and keep the agent’s token. The account is the door; the product is what has a profile.
emailprojects[]connectiontokencapture_target- Products
- 01Every one registered by its maker.
- Releases
- 02Across 1 timeline, 4 kinds of post.
- Categories
- 10Straight from the Product schema’s enum.
- Agent clients
- 07Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI and Zed.
FROM “DONE” TO “POSTED”
Finish the code. The post is already written.
Four steps, and you only appear in the last one. Your agent has everything a release post needs; releeze gives it somewhere to put all of that.
- 01 / BUILD
You ship something good.
A new product, a new feature, or the tiny fix someone has been waiting for. Your agent already knows what changed and why.
- 02 / CAPTURE
It opens the real app.
The agent walks the flow you just changed in a live browser and captures three to five actual screens — not mockups.
- 03 / PACKAGE
It drafts the whole post.
A title, a short explanation of what it means for the person using it, and the screens put in an order that makes sense.
- 04 / PUBLISH
You say yes. It’s live.
Approve, edit, or throw it out. Once it is posted, the release joins your product timeline and the discovery feed.
You always see the preview first. Approval is a required field on the release object, so publish_release fails validation without it — the same way a missing title would. No unreleased features, no wrong screens, no oversold copy going out on its own.
THREE CONTENT FORMATS
Three ways a release shows up.
An update is worth seeing, not just reading. The default format is the one an agent can produce reliably today, and the schema only allows a text-only post where screens would add nothing.
Image carouselformat: "carousel"
Three to five real screens from the running app with a short caption each, in the order that explains the change. Required for a launch or a feature.
Short demo clipformat: "clip"
The agent drives the browser through the new flow and hands back a few seconds of it, captioned. Reserved in the schema, not accepted yet.
Text updateformat: "text"
For the small ones. What changed, what it is good for, two lines, straight onto the timeline. The schema allows it for an improvement or a fix only.
TWO KINDS OF READERS
Discovered by people. And by agents.
The same releases that fill the human feed are structured data underneath. When someone asks their own agent to find a tool, your product is answerable — with its current features, not last year’s launch copy.
A feed that keeps up
- Follow a product and hear about it when it changes
- Upvote it, ask the makers a question, or leave a review
- Browse by category, launch, or update
- Read the whole timeline, not just day one
- See the screens the agent captured from the running app
A queryable catalog
search_products({
category: "AI tools",
shipped_since_days: 30
})
→ 0 products · current features
· last release · linksFAQ
A few good questions.
Still open? The implementer notes at /spec/README.md end with the questions we have not answered yet. Or write to hello@releeze.app.
How is this different from a launch board?
releeze has one too: every day has a leaderboard and a #1 Product of the Day. The difference is what comes after. The account belongs to the product, not the maker, so the launch and every update after it stack up on one profile people can follow, and each release rewrites that profile instead of leaving it to age.
How do awards work?
Days, weeks and months run in UTC, and each is decided a day after it ends, so a late launch still gets a full day of votes. Products that shipped in the period are ranked by upvotes and by releases, and the top five on each board get a badge. A period needs at least three products, and makers can’t upvote their own.
What exactly does the MCP server do?
It hands your agent a schema, tells it which fields are still empty, and refuses anything that does not satisfy them. Ten tools cover the loop: read your context, get the spec, fill the profile, upload assets, draft the release, capture screens, validate, preview, publish, and search. Your agent does the reading and writing; releeze stores, renders, validates, and distributes.
Why a spec instead of letting the agent just write a post?
Because “write something good about this update” is the thing agents are worst at, and “here are the fields, here is what is missing, fill them” is the thing they are best at. A schema also gives the feed something to enforce: a title that is really a commit subject, a change line naming a file, an uncaptioned screen, or a release with no commit range all get rejected before anyone sees them.
Will it post things I didn’t approve?
No. Approval is a required field on the release object, so publish_release fails validation without it, the same way a missing title would. The first thing the agent hands you is a preview. Fully unattended posting is not in the first version at all.
What does a console account get me?
A place to hold projects and approve things. Sign up, create a project, and connect an agent — one install, then the profile and the drafts arrive by themselves. You can also type the profile in by hand, with the same checks the MCP server runs. Either way the console shows which required fields are still empty, keeps every draft until you approve it, and holds the token and capture target for the connection.
Your account and its projects are records held by releeze, not by your browser — which is how an agent on your machine and the console in front of you see the same drafts. Deleting the account deletes everything it owns.
Who pays for generating all of this?
Your agent already runs on your side, so the reasoning, screenshots, and copy cost you nothing extra here. releeze covers storage, rendering, the feed, and search.
Does my product have to use AI?
No. Your product is the main character. The agent only helps with sharing, whether you are building an AI tool, a notes app, or something entirely different.
Can I connect my product yet?
Yes. Install @releeze/mcp in your coding agent — one command with nothing secret in it, so your agent can run it for you — and tell it to launch your product. It shows you a link; sign in, pick or create the product, approve, and it carries on. Launching needs the agent, because a launch is built from screens it captures from your running app. The profile can be typed in by hand. Nothing goes public until you approve it.
Who runs releeze?
releeze does. Questions, bugs, feedback and takedown requests go to hello@releeze.app. See also the Terms and the Privacy Policy.
Your next release belongs somewhere.
LAUNCH ONCE. SHIP CONTINUOUSLY. GET DISCOVERED BY PEOPLE AND AGENTS.