Release notes get a bad reputation because a lot of companies say they fixed ‘bugs’ or improved ‘performance’ in their software. That is a conscious decision and not an ongoing job. There are 4,000 characters available and users get to decide if your bug fixes and performance improvements are noteworthy enough to upload the release notes.
The audience is never your team. It’s the person who noticed something moved, or is about to. Release notes are the least expensive support content you’ll ever publish, and are written for this audience.
A release note is the one chance to inform users about changes they will likely notice; users do find issues on their own. Using the symptom to describe the fix helps users recognize their problem. When users encounter the note “Fixed the crash when importing a CSV over ten megabytes,” they know the issue personally. “Stability improvements” does not inform the reader about the same information.
A model that takes a list of commit messages will always produce polished nonsense, because commit messages describe code and it cannot tell which change a user would care about. You might get ‘improved performance across the app’ which happens to describe a release that finally shipped a feature that fixed the export timeouts.
We use the merged pull requests and / or the sprint board as our starting point and then discard most of it. The task of the author of a user story is to select the twelve changes of ninety that a user would actually see and to provide a description of each change in terms of a symptom rather than a cause. Anything that is visible to the user and was logged internally is brought to the foreground.
Release copy often requires verification by engineering to confirm the fix and product to confirm the frame, and it is important that both are done quickly due to a build waiting. We provide each line with its respective source ticket traceability, so a reviewer can either approve or modify a line without searching for what the line is referring to.
One rate, whatever the format: $10 per 100 words. You are paying for the writer’s time and judgement, so the price scales with the words rather than with a package tier.
| Typical release note | Words | Writing | Fee (1%) | You pay |
|---|---|---|---|---|
| Short | 500 | $50 | $0.50 | $50.50 |
| Standard | 1,000 | $100 | $1 | $101 |
| In-depth | 2,000 | $200 | $2 | $202 |
The writer receives 100% of the writing price. Our 1% fee is added on top of it, and 0.5% is donated to tree planting. Full pricing breakdown.
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
Although orders take three days to deliver, working with a weekly rhythm means placing orders during the code freeze rather than at the release. Writers normally work for these teams and have to condense briefs to an explanation with a link in one single paragraph.
Usually, yes; and I agree with the wording. You should mention it to the security owner first, though, before you publish it. We will draft the version without the obfuscations. The cost of remaining silent while a fix has become something users will hear about from other places is more trust than what will be lost by the disclosure.
Completely. Copyright transfers to you on delivery, with no attribution requirement and no licence back to us. Nothing written for you is resold, repurposed or republished.
Reviews from completed, paid orders in this category.
Our releases happen every fortnight, and our notes have evolved into change logs. To keep things organized, the writer has noted what changed within a card or view and what changed underneath. Each note is a brief summary of the change. The biggest metric I’m interested in post release is the volume of support tickets. It always dips.
Our changelog has little snippets about why the change happened, and that seems to have solved the issue of support receiving the ‘what does this actually do?’ tickets. I honestly never thought that release notes would give us the answer for that.
Our release notes went unread, but they serve the purpose of listing what breaks and what doesn’t when considering whether to upgrade. Two customers actually took the time to send thank yous in the same week, something that had never happened before.
We do not ask you to take the no-AI promise on trust. Each draft is run through these platforms and the reports are attached to your delivery email.
Originality.aiAI detection + plagiarism
GPTZeroAI detection
TurnitinAI detection + similarity
CopyleaksAI detection + plagiarism
Winston AIAI detection
ZeroGPTAI detection
SaplingAI detection
Content at ScaleAI detection
Send the brief, get a human draft back within 3 days. No account, no subscription, no AI.
$10 per 100 words · all of it to the writer · 0.5% to trees