To audit a platform’s maturity, start on a public page almost nobody opens during a vendor evaluation. It is the release notes. In SMARTFENSE’s case there are 136 of them, each with its own date, from 1.0 on 17 April 2017 through 4.38, dated 29 August 2026.
The exercise is more or less that. Read the release history and check whether the story the sales team tells lines up with the dates. No permission required, no non-disclosure agreement, no waiting for the next demo.
What is a public release history, and why does it help you evaluate a vendor?
A public release history is the dated record of everything a vendor has shipped to production, published on the vendor’s own site and reachable without signing up first.
It helps for an uncomfortable reason. It is the only document in the buying process that the vendor did not write with the buyer in mind. A demo gets rehearsed. A case study gets picked from the ones that went well. A release history, by contrast, accumulates on its own, and when it has gaps those gaps are still there two years later.
That makes it a hard data point inside a decision that usually leans on feature comparison tables. We covered the full decision framework for choosing an awareness platform elsewhere on this blog. What follows is one piece of that framework, the piece you can verify without talking to anyone.
What signals should you look for in a vendor’s release notes?
There are four, and they are worth checking in this order.
- That they exist and carry dates. A list of updates without dates makes any cadence impossible to calculate. It is marketing material under another name.
- Cadence before volume. The total number of releases says little. What says something is how many there were per year and, above all, the longest interval between two consecutive ones.
- What the release that closed each long pause shipped. Every platform has pauses. The useful question is whether the next release shows the deep work that would justify them.
- Which languages the history is published in. If a platform is offered in several languages and the notes live in only one, what got translated is the website and not the product.
None of the four requires privileged access. All four can be answered in a sitting with the vendor’s site open.
What shows up when you apply those signals to SMARTFENSE?
Here is what comes up, with the numbers as of 24 August 2026.
| Signal | What SMARTFENSE’s release history says |
|---|---|
| Releases published | 136, from 1.0 on 17 April 2017 to 4.38, dated 29 August 2026 |
| Releases per full year | Between 12 and 17, every year since 2017 |
| Typical interval between releases | Median of 21 days across the nine years |
| Last 24 months | 26 releases, median of 28 days, longest interval 43 |
| Pauses longer than 45 days | Three in nine years |
| Languages the history is in | All five site languages, each current through the latest release |
The company was founded in 2016 and the first version of the platform shipped in April 2017, so the history covers nine years and four months of delivery. The notes for the current generation sit on the same page where anyone can redo this count.
It is worth pointing out what the table leaves out. There is no growth figure, no customer count, no satisfaction score. These are delivery numbers, and they speak to delivery alone.
What happened during the long pauses?
Two of the three line up with a generation change.
The 63-day one ended on 18 August 2018 with release 2.0, which introduced support for several organisations linked in a hierarchy along with the platform’s first dashboard. That is where the architecture behind today’s partner work comes from, something we develop in managing multiple organisations from one portal.
The 70-day one ran between December 2021 and February 2022, right after 3.0, the release that added gamification with badges. A new generation opens with one large capability and the rhythm takes a quarter to return to normal.
The 78-day one, between June and September 2021, is the longest, and it sits in the same public list with its date alongside.
What does a long release history fail to prove?
A long release history proves quite a bit less than it seems to.
It does not prove the training content changes behaviour, which is ultimately what gets bought. It says nothing about support when support is needed. And it leaves open whether the platform fits one organisation’s actual operation, its identity provider, its languages and its audit calendar.
What it proves is sustained investment and a sustained ability to ship. That is a necessary condition and it does not stand alone. The rest of the questions call for other evidence, and we wrote about that in the honest criteria for evaluating a simulation tool. The deeper discussion of what it takes to manage human risk end to end does not get settled by dates either.
The check, in ten minutes
Open the release notes page of whichever vendor you are evaluating. Write down the date of the first release and of the last. Count how many there are. Find the longest interval between two consecutive ones and read what the release that closed it shipped. Then repeat the exercise in another site language.
If any step cannot be completed, that is already a result. And if you want to start with us, the full release history is published there, with the other three generations linked from that same page.
Leave a Reply