One good day, then quiet.
- Attention arrives on a single date and leaves with it
- The account belongs to the maker, not to the product
- Day-one copy stays up long after it stops being true
- Every update needs a new post, written by hand
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.
THE FEED IS THE PRODUCT, NOT THE DAY
A launch event, or an activity feed.
A launch board puts the spotlight on day one and then moves on. releeze is built around the release after that one, and the one after that. Same profile, same followers, a timeline that keeps going.
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- Sample products
- 00Illustrative profiles, not real traction.
- Sample releases
- 00Across 0 timelines, 4 kinds of post.
- Categories
- 10Straight from the Product schema’s enum.
- Agent clients
- 02Claude Code and Codex.
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
- 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: "30d"
})
→ 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.
How is this different from a launch board?
A launch board puts the spotlight on day one and then moves on. Here the account belongs to the product, not the maker — so the first release and every update after it stack up on one profile that people can follow, and the profile is rewritten by each release rather than left to age.
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 you can either connect an agent — one install, then the profile and the drafts arrive by themselves — or fill the spec in by hand, field by field, with the same validation 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?
Not for real. This is an interactive preview: the 0 products, their releases, and their screens are illustrative. The spec is written and versioned, the console validates against it with the same checks the server runs, and search_products already answers from the catalogue — but the @releeze/mcp package and live posting are still to come.
Your next release belongs somewhere.
LAUNCH ONCE. SHIP CONTINUOUSLY. GET DISCOVERED BY PEOPLE AND AGENTS.