Avature releases a new version of its application to each customer every two weeks. That’s no small feat when you consider this happens across hundreds of customer instances, what amounts to thousands of users. This rapid release cycle provides huge benefits both to the customer – faster access to new features and functionality, better software quality and security – and the developer – reduced risk, improved project management, and market agility.

First Generation SaaS and the Dreadful Upgrade

Enterprise software companies have been banking on huge revenues for “version upgrades” for years. These upgrade cycles, happening every few years, have proven to be costly to manage and potentially disruptive to business execution. They’re often described as “like another implementation”. Most of the time, the new version is too buggy when initially released, it isn’t compatible with other applications, or its new features don’t add enough value. So why pay to upgrade in the first place? Do you have the IT resources available to manage the upgrade? Why not just wait? But if you don’t upgrade you miss out on any new features and eventually the vendor will stop supporting your version. Unfortunately, this is a reality most companies have learned to live with for decades, always balancing the business value of the upgrade against its cost in order to decide when to make the move.

In the consumer market it’s common to have a steady and fluid release cycle for everything, from Facebook to Angry Birds to Gmail. Can you imagine having a version of Facebook that isn’t compatible with your friend’s anymore? Requiring IT support to upgrade and make sure your old settings will still work? Having the upgrade tested for days or weeks to check all of your apps and browsers are compatible? Of course not.

Next Generation SaaS

Chrome OS, Google’s operating system released in 2009, has four versions: Canary, Dev Channel, Beta and Stable. Stable is the most reliable version and has been thoroughly tested in Beta. Beta has been tested in Dev, and Dev in Canary, so Canary represents the least stable of the four versions (it is named after the canaries used as sentinels to detect toxic gases in coal mines). Most consumers will always be on Stable and will always get the latest version that includes both fixes and new features. The release cycle is fluid and rapid to insure stability, security, and steady improvements in the product. It also allows Google to quickly respond and change direction based on real-time market feedback from each incremental release.

At Avature, we’ve taken a similar approach. We have four versions of our software with all customers’ instances on a production version that has been thoroughly tested. Some customers’ sandboxes (customers can opt in to our beta program for their sandbox instance) and internal Avature instances (we use our own software) are on a “Beta”, less stable version, which allows us to test in a low-risk environment and get real-time feedback from actual users. Once the product finishes this Beta cycle, it gets released to customers gradually. This ensures that if a problem was missed in Beta, it gets identified, solved and released very quickly (what we internally call “Priority Zero”, as it goes on top of everyone’s priority list). All new releases include bug fixes alongside new features. Large feature changes and new functionality being introduced for the first time get released under a permission, allowing the customer system admins to “turn them on” for different user roles, so that they retain control of the upgrades.

We release frequently but almost eliminate any disruption to our users. Before releasing a new version to an instance, the system looks for a window of time in which there are no active users and only then it releases the change – which usually takes just a few seconds. If the system can’t find any inactivity window in a 24-hour period (not likely), it releases the change at the time it affects the least amount of users – usually in the middle of the night of the most active time-zones. This rapid release cycle allows us to take a truly agile approach to software development. With a steady phasing-in of new features, users are gradually introduced to an ever-improving set of tools delivered in a familiar user interface that keeps pace with consumer-software usability standards. We can immediately gauge how customers react to the steady improvements and adjust them very quickly based on their feedback. That lets us evolve lockstep with customer demands and market changes, delivering solutions within weeks instead of months or years.

In an industry as competitive and consumer-facing as recruiting, keeping up with new technology can make a big difference on how well you execute talent sourcing, selection, employee referrals, hiring manager engagement, candidate experience, employer branding and reputation, and so on. The days of multi-year upgrade cycles are over. The world has moved on. The rapid release cycle is unquestionably core to the next generation of SaaS, and to businesses executing on an agile talent acquisition and management strategy.