Every release followed the same routine.
Finish the feature.
Merge the pull request.
Deploy.
Then spend another thirty minutes writing release notes that already existed somewhere inside commit messages, issue trackers, and pull requests.
After doing this for a few months, I started wondering why I was manually rewriting information that my application already knew.
So I built a tiny tool.
Not because release notes are difficult to write.
Because repetitive work usually deserves automation.
The Idea
Instead of treating release notes as a document written after development, I wanted them to become another build artifact.
The application already knew:
which features were completed; which issues were fixed; which version was being released.
Why not expose that information through a simple API?
app.MapGet("/api/releases", () => { return Results.Ok(new[] { new Release( "Dashboard Filters", "Added", "Users can now save custom filters."),
new Release(
"CSV Export",
"Improved",
"Reduced export time by 40%.")
});
});
public record Release( string Feature, string Status, string Description);
Nothing complicated.
Just structured data.
Generating Markdown
The next step was surprisingly small.
var builder = new StringBuilder();
builder.AppendLine("# Release Notes"); builder.AppendLine();
foreach (var item in releases) { builder.AppendLine($"## {item.Feature}"); builder.AppendLine($"- {item.Status}"); builder.AppendLine(item.Description); builder.AppendLine(); }
await File.WriteAllTextAsync( "ReleaseNotes.md", builder.ToString());
Now every deployment generated fresh release notes automatically.
No copy-paste.
No forgotten changes.
No outdated documentation.
One Unexpected Benefit
The biggest improvement wasn't documentation.
It was communication.
Product managers could review changes much earlier.
QA no longer needed to ask what had changed.
Everyone looked at the same generated document.
That reduced a surprising amount of back-and-forth.
Adding Visual Context
Sometimes text still wasn't enough.
For features with major UI changes, I preferred showing a quick visual draft before recording a polished walkthrough.
During one internal experiment, I generated several rough concepts with Kling 3.0 AI Video Generator before creating the final demonstration.
The generated clips weren't production assets.
They simply helped us decide which explanation was the clearest.
Things I Would Change
If I started again today, I would also generate:
changelog summaries; OpenAPI documentation; architecture diagrams; migration notes; release announcements.
Everything should come from the same source of truth.
Final Thoughts
This project saved only a few minutes per release.
But those minutes were always the same repetitive minutes.
Automating repetitive work doesn't just save time.
It removes one more task that developers have to remember after every deployment.
Sometimes the best automation isn't the one that looks impressive.
It's the one that quietly disappears into your workflow and keeps doing its job.