Automatic changelog
Automatic changelog. In plain English.
Connect your GitHub repo. featury reads every PR, works out what actually shipped, and publishes it in language your team and your customers can both read. Nobody writes a line. The code is the source of truth.
Free to start, no card. Connect a repository and the first edition drafts itself.
- Read-only access
- Disconnect any repo, any time
- Files like .env are never read
Public changelog
Generated by Featury
The feed
A changelog that publishes itself
Every merge becomes a plain-English entry. Classified, risk-flagged, published to a public page with RSS. Your team, your customers and your investors read the same thing.
Your public changelog, always current
A public page and RSS feed of everything your product ships. Grouped by delivery, written in plain language, with risk flags where it matters. Stakeholders subscribe instead of asking.
updated with every merge · public page + RSS
"Doesn't look right?" Say so, once
Every entry carries a correction button. Flag a misread and featury re-analyzes the change against the code. The feed you publish is one you vouch for.
"Shipped" comes from the code, not a checkbox
Every other tool calls it done when someone ticks a box, and people forget, move cards, and lie. featury reads the code instead: shipped is what merged. No status theater.
The changelog is only the front page
Behind every entry sits a living map of your product. Read from the source, not a doc someone forgot to update. Ask it anything in plain language, capture ideas on top of it, and follow each one to shipped.
How it works
From your code to your changelog, in three steps
Nothing to instrument, no new process for your engineers. featury works from what's already in Git.
Connect your repository
Install the GitHub App and choose the repos to watch. Access is read-only and scoped to exactly what you pick.
featury reads every PR
Every merge is classified (added, changed, fixed, security), rewritten in plain language, and risk-flagged where it matters. Continuously, in the background.
Your changelog publishes itself
Entries land on your public page and RSS feed the moment code ships. Stakeholders read along, and nobody writes release notes again.
Behind the feed
A living map behind every entry
Each changelog entry is grounded in featury's map of your product (every capability, its status, and where it lives), read from the source and current the moment code lands.
Feature inventory
18 features- User authenticationShipped
- Team billingActive
- Role-based permissionsShipped
- Slack notificationsRecently changed
- Lead importDeprecated risk
Recently shipped
Billing now supports annual plans
billing · 2d ago
Admin users can invite teammates
team · 4d ago
Webhooks retry failed deliveries
reliability · 5d ago
Who it's for
For the people who ask "what shipped?"
Three roles, one answer: the changelog your product publishes itself.
Founder / CEO
Knowing what shipped without asking anyone
"I never know what the team actually shipped this sprint without asking around."
The public feed shows every delivery in plain language. Share it with customers and investors as-is.
Product Manager
Release notes without the writing
"I spend hours every week chasing devs and assembling release notes."
Every merge arrives already classified and written up. You only touch the odd entry, with the correction button.
CTO / Tech Lead
Answers without the interruptions
"Stakeholders stop me in the hallway to ask what changed, and new devs ask how everything works."
Send the link. The changelog (and the living map behind it) answers in your place, citing the code.
The WhatsApp story
From a WhatsApp message to a shipped feature
A bug arrives as a WhatsApp message. It leaves as a line in the changelog. Nobody opened the code.
It starts as a message
A customer or founder describes the bug or idea on WhatsApp. Text, audio, or a photo of the screen.
featury reads it and files it
Audio and screenshots become text, and the request is triaged and checked against your real code, with the questions worth investigating.
It takes shape
The request becomes a plan with a visual prototype you can react to before a line of code is written.
It ships, and tells everyone
The delivery lands on the changelog and the living map, and whoever asked hears back on WhatsApp.
For developers
Built for agents and scripts, too
Everything featury knows about your product is available outside the app: a remote MCP endpoint for coding agents, and a versioned REST API for everything else.
MCP for coding agents
Point Claude Code, Kimi CLI, or any MCP client at your workspace. Your agent can triage requests, read the feature inventory, and ask the codebase, with your permissions.
claude mcp add --transport http featury https://api.featury.app/mcp \
--header "Authorization: Bearer fk_…"REST API for everything else
The same surface over plain HTTP: changes, requests, features, and the ask endpoint. One personal API key, a Bearer header, and JSON back.
curl -H "Authorization: Bearer fk_…" \
"https://api.featury.app/v1/changes?workspace=acme&project=web&limit=5"Security model
Your code stays yours
Connecting your source to a product is a real decision. These aren't promises on a policy page. They're enforced in the architecture.
- read-only
Repositories are cloned read-only. Featury never writes to your code or executes it.
- secrets
Before code goes to an AI provider, text that looks like a secret is removed. It matches common formats, so an unusual one could get through.
- scope
Sensitive files (.env, keys, certificates) are never read.
- access
Role-based access control is enforced on every request.
- untrusted
Repository content is treated as untrusted data, never as instructions.
Your next merge can announce itself
We take on a few teams at a time. Connect your repo and the changelog starts today.