By Kaare Bøegh | Jan 29 2015 | Insights

Today, we would like to introduce you to another way of thinking about apps heavily inspired by “Software-as-a-Service”, or SaaS. We call it: “Apps-as-a-Service”.


The core concept of Software-as-a-Service – a large computing resource maintained centrally – is as old as computing itself. In the early days of computing, size was mainly physical and maintenance included removing actual bugs from the hardware. Over time computers became smaller and moved on to our desktops and even on to our laps. That created a whole new set of difficulties in how to maintain many disconnected computers, which ushered in the age of the “IT-crowd”. The advent of the internet reversed this trend. Now we use cloud computing and the main interface is the web browser. Furthermore, now we no longer need to install applications, we use software services. It is a beautiful model and it has been hugely successful.


Alongside the emergence of SaaS, a successful seller of MP3 players turned the mobile market upside down and killed the MP3 player in the process. In 2007, Apple launched the first successful modern smartphone, the iPhone. In the very early days of the iPhone, using web-apps was the recommend way to create apps. Apple even added features to their browser to help developers make web pages more app-like. For a while, it looked like the iPhone was about to be a huge driver for SaaS-based solutions. Then, a year after the launch of the iPhone, the App Store was opened and suddenly everyone started saying "there's an app for that".

Many of our customers and indeed the whole newspaper industry started to take notice, especially when the iPad was introduced. Finally, here was a device and a form factor that could be used for reading and much, much more. Everyone felt an urgent need to have a presence in Apple's App Store. At the time, it was pretty unclear what the "much, much more" was; in hindsight though, it turned out to be mostly cat videos and Angry Birds!

Proponents of browser technologies as the basis for apps have long been very vocal. Though, rightly so, as the SaaS model enabled by browser technologies is very attractive for developers – but end-users do not care about technology, they are looking to be entertained or educated and, most importantly, they are looking in the app stores.

Nowadays, very few try to argue against having apps in the app stores, but at least one point remains from the HTML vs Native debate: Maintaining a native app is a bit more involved than just pushing the latest changes on to the production environment. We have to deal with everything from third-party review procedures, to users that decline to upgrade but still expect everything to keep working, to frequent platform changes. The latter is a root cause of many maintenance headaches. With major OS revisions arriving yearly, often with a couple of minor releases in between, and in addition to the release of new devices and form factors across two completely distinct platforms, i.e. iOS and Android, you can be forgiven for feeling a bit overwhelmed at times. 



With close to 800 apps in different app stores that is something we spend a lot of time worrying about and handling - but all our customers share a little bit of the pain too. Sometimes an app just needs to be updated, but someone has to foot the bill. For a very old app that is no longer up to date with the platform, that can be a large undertaking; for example, when iOS went to a flat design or, more recently, when everything had to be rebuilt for 64 bit.

However, it is not all worrying and gnashing of teeth – we have a small subset of projects that never trouble us. They are built purely on our standard software that we maintain every day. Need an upgrade? They barely require a developer. Need to enable a new feature? Sure! – that it is just a setting. The parallels to Software-as-a-Service should be clear.

We would very much like to extend that model to all of our customers – so much so that we have given it a name: Apps-as-a-Service. We cannot claim to have coined the term, but it’s definitely not as common as its main source of inspiration. In our definition:

Apps-as-a-Service shares all the main traits of Software-as-a-Service: Centrally maintained software shared by all, with a continuous integration of customer and end-user feedback, frequent updates, easy enabling of new features, and predictable cost.

The main difference: Code can still be managed centrally, but apps are built and deployed. The app in the hands of the end user is a snapshot that will not be updated until a new snapshot, i.e. version, is released. Since not every user upgrades at the same time, the back-end systems have to support many different app versions simultaneously, thereby creating a lot of complexity, which would be eliminated in the SaaS world.

Apps-as-a-Service is a very attractive model for the app buyer, offering: forward compatibility, continuous improvements and maintenance at a fixed cost. It is also a very attractive model for developers. By having a centrally managed code base, we can optimize our workflow to lower costs, invest more in higher quality and reliability, and draw on the experience from hundreds of apps every time we improve the app – to the great advantage of all.



You may think that Apps-as-a-Services also implies a "one-size-fits-all" model. That is not the case. A small local paper with two weekly editions will have very different needs from a large regional paper with 20+ versions every day. The question is what solution best fits your overall digital strategy.

Moving forward, we are working with two project types: Standard and Customized, which will be offered as Apps-as-a-Service solutions. And then, we have Co-Created: a project type used for time and material solutions.


A Standard app is build purely from standard components. Standard does not imply simple, standard just means that the building blocks are unmodified on a code level. The scope for configuring standard components and combining them is vast. For instance, you might just want a very focused reader app with a basic feature set or you might want a larger app supporting multiple editions, and/or featuring historic archives with search facilities, and/or live content from your website or something else from our 20+ list of features that can be added to an app – naturally, fully branded and with styling to match your paper edition. We estimate that more than half of the apps we have deployed so far could be upgraded to Standard right now without affecting the end-user experience. Going Standard is the easy choice.


A Customized app is mainly built from standard components. The users main contact points, besides the paper, the start screen and the log in screen can be fully customized or even rebuilt from scratch. Customized allows for additional branding, integration with live content, tailor-made kiosk solutions and so much more. Customized is designed to provide a very strong alternative to Co-Created by allowing changes in the areas with most end-user impact and limiting it in the areas that are fast becoming a commodity. Maintaining a customized app though cannot be as streamlined, since the customized components will need their own maintenance track. However, encapsulating the bespoke parts allows us to offer Customized apps as a service.


A Co-created app does not have to fit into any predefined framework. Anything goes. However, that untethered freedom comes at a cost. Sometimes the cost even surprises us, but mostly it surprises our customers. We are very keen to avoid the latter. Co-Created is an interesting category with plenty of room for experiment and learning. However, it is not possible to offer Co-Created apps as a service and for that reason alone we will be hesitant to recommend it for most projects.


In Visiolink, we are busy adjusting our mindset to an Apps-as-a-Service world. We have worked internally on the Apps-as-a-Service concept for quite a while now and are happy to finally start sharing it. Everyone in Visiolink is looking forward to working with future customers and helping them find the project type that best fits their needs and wishes. And also we are keen to enter into dialogue with our existing customers about their solutions and how they can be upgraded to an Apps-as-a-Service model.

Kaare Bøegh


Kaare Bøegh

Kaare is the Chief Technology Officer in Visiolink.