Writing a release note

There is no model deciding how Bundul sounds to customers. A person writes the sentence and a person merges it. This is the house style that person follows.

The one sentence

Every note starts as the Customer summary line on your pull request. Write it for the person paying the bill, not the person who wrote the code.

❌	Added dunning email templates to the collection retry path
❌	Implemented UTILITY_PRICE_CHANGE push notification type
✅	If a payment fails, we now email you straight away with what to do
✅	We tell you when a utility bill goes up, before the money leaves

The test: could a customer read it and know whether it affects them?

Rules

Write from their side of the screen. They have bills, payments and a bank connection. They do not have a One Sub record, a bundle run, or a virtual card provider. Name things by what they see in the app.

Say what changed for them, not what we built. "We rebuilt the reconciliation job" is our news. "Payments that used to fail silently now tell you" is theirs.

Be specific over clever. A date, an amount, a place in the app. Never a pun.

Lead with the benefit, then the mechanism. One line on what they get, then two or three on how it works if it needs explaining.

Plain verbs, sentence case, no exclamation marks. We are a company that moves their money. Read it back: if it sounds like an ad, rewrite it.

Never apologise in a fix note. State what was wrong and that it is fixed. "Reports sometimes showed a recurring bill as 'Subscription' instead of the real merchant. Fixed." — not "Sorry for the confusion!"

Anatomy of an entry

---
title:      A short, plain claim. Not a feature name.
date:       When it reached customers, not when it merged.
version:    The app version, if it needs one.
minAppVersion: Hides it in-app from anyone who cannot use it yet.
categories: new | improved | fixed
platforms:  ios, android
summary:    The one sentence. Reused on the card, in RSS and in the app.
---

Two to four short paragraphs. What changed, then where to find it.

Title. A claim, not a label. "Split your One Sub into two payments" beats "Split payments". If it reads like a Jira ticket, it is wrong.

Summary. This one line does the most work — it is the card, the feed and the app. Spend the time here.

Body. End with where to find it whenever there is somewhere to look: "Open any utility in your One Sub and tap the bill."

What never goes on the page

• Anything customers cannot reach yet. If the app cannot get to it, the note waits
• Security fix details. Say a fix shipped; do not describe the hole
• Pricing and fee changes. Those go by direct, legal-reviewed email — finding out from a changelog is how you lose trust
• Admin and internal tooling. They never see it

Changing something already published

Edit the markdown file and merge. The page, the permanent URL, the RSS item and the app's feed all rebuild from that one file, so they cannot end up disagreeing.

If a note was wrong in a way that mattered, correct it in place and say so in a line at the end. Do not delete it — the URL may already be in a support reply.

Where the copy actually comes from today

You write it. There is no generator and no house-voice model.

A drafting step is designed — it would take your Customer summary, the machine- read facts about what changed, and this guide, and produce a first draft for you to edit. It is not built. Until it is, this page is the standard.