1 September 2026 · 7 min read
What does a version number tell you about a vendor?
A changelog is the cheapest due diligence available to a buyer, and almost nobody reads one. It takes two minutes and it tells you things a sales page never will.
Why does this matter before buying?
Because you are not only buying today's software. You are buying whoever maintains it when a payment gateway changes its API, when a database version is retired, and when somebody finds a problem.
A sales page tells you what exists now. A changelog tells you what has been happening for two years, and whether anyone is still there.
What a good changelog looks like
- A version number and a date on every entry
- Specific descriptions rather than improvements and bug fixes repeated forever
- Fixes as well as features, because software that only ever gains features is not being maintained honestly
- Notes about breaking changes and what to do about them
- Regular activity, without a two year gap in the middle
Entries that name real screens are the strongest signal. Somebody who writes fixed a rounding error in weekly payout accrual is describing work they actually did.
An admin controlled investment platform, installed and configured for you. Full admin control, live in 6 to 12 hours, from $149.
What the warning signs are
| What you see | What it usually means |
|---|---|
| Every entry says bug fixes and improvements | Written to look active, not to inform |
| A long gap, then sudden activity | Maintained only when somebody complains |
| Version numbers that jump erratically | Marketing numbering rather than releases |
| The log starts recently for an old product | Possibly a rewrap, see the rewrap checks |
| No dates anywhere | You cannot tell whether any of it is recent |
The fourth row connects to the checks in how do you spot a rewrapped script sold as original?, where a changelog that begins suspiciously recently is one of the tells.
What a missing version number means
At best, a vendor who does not track releases. That has practical consequences: when you report a problem, neither of you can say which build you are running, and when an update arrives nobody knows what changed.
At worst it means the product is somebody else's work with the identifying details removed. Either way, the absence tells you something before you have spent anything.
How updates should reach you
Published, dated and applied when you choose. Not pushed silently to a running platform.
On software holding user balances you want to pick the moment, take a backup first, and be able to roll back. Silent updates to a live platform are how an operator discovers a change at the same time as their users. The wider point about licence servers and remote control is in how to buy a HYIP script without getting burned.
What to ask
Ask for the current version number and the last three changelog entries before you pay. It is a small request and the response is informative whichever way it goes.
Then ask how updates are delivered, whether they overwrite customisations, and how long the support window lasts. The customisation part matters more than it sounds, and it is covered in can you change plans and branding without a developer?
How do you verify a claim of regular updates?
Every listing says regularly updated. Checking it takes about three minutes and needs nothing from the vendor.
- Find the changelog and read the dates rather than the entries. Look for gaps longer than a few months
- Read the three oldest entries and the three newest. If they describe the same vague improvements, nobody is writing them properly
- Search a distinctive phrase from the product's interface. If several products share it, you may be looking at one product with several sellers, per spotting a rewrapped script
- Look at whether the marketplace listing date and the changelog agree. A listing published years before the changelog begins is worth asking about
Then ask one question by message: what changed in the last release, and why. A maintainer answers in a sentence, because they did the work. A reseller either forwards your question or answers in generalities, and both are informative.
None of this proves the software is good. It tells you whether somebody is still there, which is the part you cannot fix yourself later.
Common questions
Why does a changelog matter?
It is the only evidence you can check yourself that the software is still being worked on. Sales pages describe the present; a changelog shows the last two years.
What if there is no version number at all?
Treat it as a warning. Either the vendor does not track releases, which makes support and updates unreliable, or the product is a rewrap of somebody else work.
How often should a product be updated?
There is no correct cadence, but long silence followed by a burst of activity often means a product that is maintained only when somebody complains.
Should updates be automatic?
On a platform holding balances, no. You want to choose the moment, take a backup first and be able to roll back.
What if I customised the code and then update?
That is exactly why readable source and a changelog matter together: you need to know what changed to know what your customisation might break.
Does a high version number mean better software?
No. Numbering is a choice, not a measurement. What the entries say matters far more than what the number is.
Question this did not answer? Ask on Telegram. Reader questions get written up first.