Run a versioned download with a changelog your buyers can see

Someone bought your template in February. In June they email to ask whether it still works with the new version of the software, and whether they should buy it again to get the current file. That email is the whole problem in two sentences: your product moved on, and the person who paid you has no idea.

The version problem nobody warns you about

Every digital product ages. Software you built on changes its interface, a tax threshold moves, a font licence expires, a link in your PDF dies. The work of keeping up is manageable. The work of telling people you have kept up is what most sellers never solve, so they stop bothering, and a product that was excellent in year one quietly becomes a liability.

The honest difficulty is that updates are invisible by default. A buyer who downloaded once has no reason to come back and look. If your delivery is an email attachment, there is no back to come to; the file is in a phone, in a thread, in whatever state it was in the day it arrived. That is the real reason people stop maintaining their products. Not laziness, just no surface to show the work on.

There is a second, sharper difficulty. Once you promise updates, you owe them. Writing "free lifetime updates" on a product page is easy in launch week and expensive in month fourteen. Deciding now what you are actually promising is kinder to you than discovering it later in a refund conversation.

Two ways to ship version two

Set the same update side by side and the difference is not effort, it is who does the work. In one column you are a distribution system. In the other you replace a file and get on with your day.

Running it properly

The mechanism is one upload on the digital download product itself. The habit around it is what earns the trust, and it takes about fifteen minutes per release once you have the shape. Work down this list.

Numbering versions without convening a committee

You are not shipping an operating system. A two-part number is plenty, and the only rule that matters is that the first number moves when a buyer would need to redo something.

• Second number up: corrections, new examples, a link fixed, small additions. Nothing a buyer must act on.
• First number up: a restructure, a new platform version supported, anything where a buyer's existing copy is meaningfully different from the new one.
• Date the release as well as numbering it. Buyers understand "June 2026" faster than they understand 2.3.

A quarter in the life of one file

Picture a spreadsheet template sold at £24. It ships in April as 1.0. In May a buyer points out a broken formula on the summary tab, so you fix it and ship 1.1 the same evening. In June the software adds a feature worth using, you rebuild two tabs and ship 2.0 with four lines of changelog. Three releases, maybe two hours of work in total, and every person who bought in April has the June file waiting on the page they already have a link to.

What that buys you is not a bigger number this month. It is a product description that reads like a maintained thing, a reason to raise the price at 2.0 without apology, and a stack of buyers who have watched you keep a promise. When you eventually launch something adjacent, those are the people who open the message. Your customer list builds itself from every purchase, so they are already gathered in one place.

The mistake most sellers make

They version silently. The file improves four times in a year and not one buyer knows, because the changelog lives in the seller's head. The second version of the same mistake is a changelog written in engineer, full of internal names for tabs and modules nobody outside your machine has ever seen. A changelog is a trust document, not a commit history. Three plain lines that a buyer can map onto their own copy will do more for your renewals and referrals than a hundred precise ones they cannot read. If you want to see whether it lands, per-product analytics shows views, buyers and revenue on each product, so you can watch what a release week actually does.

A versioned download is a small promise kept in public, over and over. The file is the product, but the changelog is the evidence, and evidence is what makes a stranger comfortable paying you for something they cannot hold.