Inky writes your changelog.
Inky is the communications writer. Every Friday he collects the week's shipped work, drafts the changelog entry in your voice with the version bumped, and holds it for you. You read it, edit it, publish it. Dated, on a stable URL, and on a feed your customers can subscribe to. The one piece of writing that proves the product is alive, and the one founders skip first.
What Inky does.
Most solo founders don't write a changelog. The reasons are reasonable: it feels like marketing busywork, the audience is unclear, and the time between shipping and writing always loses to the next thing. The result is that customers can't tell whether the product is being maintained, prospects can't tell whether the company is alive, and the founder loses the artifacts that prove either.
Inky writes it. Through the week your shipped work accumulates in a ship log — merged pull requests and deploys arrive there through your connected GitHub and Vercel, and you can add entries by hand. On Friday afternoon Inky reads everything in there that hasn't been published yet, groups it, drafts the entry, and picks the version bump. Then it waits for you. Publishing is always your click, and not because a switch is set that way: there is no auto-publish path built at all, so there is nothing to leave off and nothing to turn on by accident.
Inky doesn't write marketing puffery. He writes what changed and why it matters. "Lou now classifies expired_card and lost_or_stolen_card separately" is an Inky entry; "We're thrilled to announce powerful new recovery capabilities" is not. The voice is small-town newspaper editor, not Silicon Valley brand.
The voice calibrates as you edit. When your edits pull the same direction three times, that lesson starts informing the next draft as a suggestion, and separately arrives in your queue as a candidate rule. Approve it and it's promoted to a pinned rule carrying real weight; reject it and it's dropped. Worth stating plainly, because it's the opposite of what you'd assume: your edits begin shaping drafts before you rule on them, and what the approval buys is whether the lesson becomes binding.
What Inky does not do, despite what this page used to say: he doesn't write the lifecycle emails that go to your customers, your newsletter, or your social posts. None of those are built. Drafting the changelog is the whole job today.
What sets it off, what it reads, what it writes.
- Triggers
- Friday 3pm (the default cadence; every-ship and monthly are the alternatives)
- Manual /run from the founder
- Inputs
- Unpublished ship-log entries for the period
- Merged pull requests and deploys, via your GitHub and Vercel connections
- Ship-log entries you wrote by hand
- Your published changelog history, for continuity
- Founder voice samples and the rules you've pinned
- Outputs
- Drafted changelog entry (title + 2-4 paragraph body)
- A proposed version bump
- RSS feed entry
- Audit trail entry
The playbook in plain English.
Collection. Through the week, shipped work lands in your ship log: merged pull requests and deploys arrive from your connected GitHub and Vercel, and you can write entries by hand for the work that doesn't show up as a commit. Inky reads the log rather than your git history directly, which is what lets a hand-written entry sit alongside a merged PR and read the same way.
Drafting. On Friday afternoon Inky takes everything unpublished, groups it into what a customer would recognize as one change, and drafts a title plus a two-to-four paragraph body that says what changed and why it matters. He proposes the version bump. He also checks whether a draft is already pending, so a week you didn't publish doesn't become two competing entries.
Publishing. The draft waits for you, always, because no path exists that would let it do anything else. That's a stronger guarantee than a default: a learned voice rule that drifted somewhere sycophantic cannot reach your customers, because there is no unattended publish to carry it there. You read, edit, publish. Your edits are what teach the voice.
The published entry is dated, carries a stable URL, and appears on an RSS feed your customers can subscribe to.
What isn't here. There's no newsletter, no social drafting, and nothing that writes to your customers at a lifecycle moment — not configured off, not built. If you came to this page expecting the full external voice, the honest version is that the changelog is the part that works today.
The guardrails are yours.
- Turn Inky off — the per-agent switch is real and enforced. A disabled agent refuses at dispatch.
- What Inky may touch — the permissions on the installation are read on every run. Publishing is not among the things he can do unattended.
- Voice strength (designed, not yet wired) — how hard your corpus and pinned rules pull against Inky's base style.
- Breaking-changes section (designed, not yet wired) — whether a breaking-changes section appears.
- Link to the source PR (designed, not yet wired) — inline links to the diff, for products with developer customers.
- Version floor (designed, not yet wired) — the smallest bump Inky will propose.
- Excluded categories (designed, not yet wired) — the kinds of work that never make the changelog.
Nothing here yet.
We're pre-launch, so there is nothing to put here. Customer quotes go up as design partners come online and consent to being named.
Inky on communication.
Inky is the lead agent on the Communication area, and today that area is the changelog: the week's shipped work, drafted in your voice, published by you. Newsletter, social, and mail to your customers at a lifecycle moment are the rest of the area on paper, and none of them are built. Frankie writes the replies that go to one customer; Inky writes the one thing that goes to all of them.
Read the communication pillar →Common questions about Inky.
How often does Inky draft?
Weekly, Friday afternoon, over whatever shipped that week. The schedule is fixed — there's no cadence setting behind it today. He also doesn't manufacture entries: a week with fewer than two unpublished items in the ship log produces nothing at all, and the audit log shows what he considered. One small thing shipped on its own waits for company.
How does Inky learn my voice?
From your samples first — past changelog entries, blog posts, emails you've written — and then from your edits. Three edits pulling the same direction produce a lesson, which starts informing drafts right away and arrives in your queue as a candidate rule. Approving it makes the rule binding; rejecting it drops it. The influence starts before your decision, not after.
What feed formats does the changelog support?
RSS. Customers can subscribe and aggregators can index it. Atom and JSON Feed aren't served, and neither is per-entry structured data for search engines — an entry is discoverable as a page, not as a marked-up article.
Can I host the changelog on my own domain?
Not yet. Today the changelog is served on your PorchOps subdomain. Custom domains are designed and the database is ready for them, but there's no way to configure one and nothing that would route the request if you did.
Does Inky write to my customers between changelog entries?
No, and not in a turned-off way. There's no newsletter drafting, no social drafting, and no welcome, win-back or trial email to the people who pay you. The changelog is Inky's whole job today. It's the surface we built first because it's the one whose absence your customers actually notice.
Will Inky write up everything that shipped?
No. You can exclude whole categories of work — docs and refactors are the usual ones — and those never reach a draft. He works from your ship log rather than raw commits, so the filtering happens on what a change was, not on how its commit message was worded.
Closing
Inky writes the changelog I always intended to. — A cofounder
PorchOps puts a crew of AI coworkers on your back office: recovering failed payments, sorting support, keeping the books. Everything they write waits for your approval.