App Store for the rest of us


The reason we are building an app store is that we specialize in building bespoke desktop applications for the enterprise. For example, one of the applications we built is for comparing fingerprints and it is used by a large number of police forces around the world. Anyone who has had to build installers, copy protection, licensing system, payment gateways knows how difficult it is. Often building this infrastructure is far more effort than building the application you are trying to sell. Ideally there would be an official app store that would take care of this. Unfortunately for us the official Microsoft App Store is for Windows 8 only, and given that our customers are enterprise it is very unlikely that they will upgrade to Windows 8 in the foreseeable future. That means that there is a 10 year window before we can rely on the Windows 8 app store and a lot can happen in 10 years.

By taking control of the full stack we can experiment with a few novel ideas. Many of ideas are things that I wish Microsoft had built a long time ago. They definitely would have made my life easier as well as every other Microsoft Windows user on the planet.

The ideas in short;

The plan is to give Tsunami away for free for app store users and to only charge a 15% commision of the app sale price.

Royalty Model For Components

One of the major benefits of building commercial software is that you can buy various components that you may need. Many of these components exist because someone was paid to make them. This is especially true in the more niche domains - for example we use a commercial 3rd party library for feature detection on fingerprints. It would not have been economical for us to try to build that in house.

Unfortunately it is often difficult to reconcile the licensing of the components. Often to make it easier component makers charge for licenses per developer and allow you to distribute the combined software on a royalty free basis. Royalty free licenses often means that you end up having to pay thousands of dollars for a component. This is the same price if you have ten customers or a million. What if you don't have thousands of dollars? Switching to a royalty model enables the developer to build software without the massive upfront cost. The royalty model enables software for niche industries that may only have a few customers.

The difficulty for component makers to price discriminate based on sales is a well-known economic problem. The situation when a component maker sells to a big customer who would otherwise easily be able to pay more is called 'consumer surplus'. The situation when a component maker does not sell to a small customer who couldn't pay is called 'deadweight loss'. By moving to a royalty model the seller is able to fit the price over the demand curve capturing some of the consumer surplus and reducing deadweight loss - it is a win-win for all.

  1. Component makers can sell to more niche domains
  2. App developers no longer have to pay for components upfront and have access to more components
  3. End users get access to more apps that otherwise would not be made

App Store Demand Curve

NuGet Downloads

Technologically the solution is for the App Store to also be a Component Store where the payment for the Apps can automatically be allocated to components (along with the seller).

Revenue Breakdown Example:

Copy Protection

My first enterprise application did not have copy protection and was widely pirated. It was a beta, it wasn't finished, and had a number of egregious issues that I assumed meant that no-one would ever want to use it in production. I was wrong. Enterprise users have a very high tolerance. In the end the pirating helped fuel adoption and selling upgrades to people already using it was easier than starting cold.

Having learned my lesson I licensed a 3rd party copy protection library. This library became the number one issue for end users and managing upset customers ended up taking up more time that the application development did. The copy protection mechanism didn't work in a decent number of cases and in many other cases stopped working long after the installation. We would get emails from customers that lost access right before an important presentation and there was nothing we could do to fix it. Some people even went so far as to format their machines to get it working again (niche software has a powerful effect on users). We tried a number of different copy protection vendors but each had their issues. Enterprise users often have exotic setups with unusual user permissions, highly managed environments, and in many cases no access to the internet. In the end we built our own licensing system which has worked well for our needs. For the app store we're going to open this up and let other people use this functionality.

Integrated Installers

We initially used click-once deployments - this was an endless source of issues and is a complete non-starter in the enterprise. Enterprise network administrators like having control over what gets installed and often users were not given enough space or permissions to install the click-once deployment. It has to be a Microsoft Installer (MSI). For a while we used the build-in Visual Studio installer tools but this was removed in VS 2012 and has been replaced by WIX. WIX was conceived during the height of XML mania and 'coding' the XML is incredibly cumbersome and error prone. A big thanks to Google and Stack Overflow for getting me through those tough times. In the end we wrote an F# DSL to generate the XML and execute the WIX compiler and this has been an effective solution.

To make this easier for other people we have built a MSI generation server and an F# API to call it. The API creates a zip with the needed files and generates a JSON manifest for configuration and uploads it to the MSI generation server. The entire process takes ~ 40 seconds - 10 seconds to upload, 20 seconds to build the MSI, 10 seconds to download the MSI.

Payment and User Management

As most of our previous customers have been larger institutions we've been happy to manage each engagement on an individual basis and process payments by hand. Now a greater proportion of our customers are for single licenses and the manual process is becoming a bottleneck. Many of these individuals don't want a personal engagement. Most of them want to download the software, send us money, and get on with their lives.

For this reason we've built an integrated payment, customer management, and licensing system. This is the kind of infrastructure we would like to open up and let other people use.

For the customer management interface we provide an easy to use Excel like Pivot Table frontend to the data with charting. For more advanced users we have even integrated Cloud Tsunami to process the data in any way they can think of. Think Google Analytics on steroids.

Pivot Chart View
Pivot Chart View
Pivot View
Pivot View
Map View
Map View
Cloud Tsunami View
Cloud Tsunami View

Sell to Anyone from Anywhere

We will support Visa / MasterCard wherever possible but for everyone else there's Bitcoins! Creating a 'merchant account' for Bitcoins is far easier than for Visa and MasterCard. We can streamline the process to make it seamless. We can set up an account for you in Bitcoins in seconds as opposed to weeks. The plan is to have these accounts able to sell to Visa / MasterCard users much like existing app stores. This way payments can be processed the instant an app is purchased instead of weeks later.

BitCoin payment
BitCoin payment

Apt-Get for Windows

Apt (Advanced Packaging Tool, a.k.a apt-get), is an incredibly successful package management system for Debian Linux and its derivatives (e.g. Ubuntu). It means that to install software, e.g. apache, you just need to type the command apt-get install apache and it will fetch apache and install apache as well as all of apaches dependencies. It is incredibly convenient and I have wanted to see first class support for this functionality in Windows since seeing apt-get for the first time 15 years ago.

This idea isn't new. There is Chocolatey that works with NuGet (get it?). Scott Hanselman has a blog entry on it here.


Because we manage the creation of the installers we can create a much simpler process of managing and installing dependencies that integrates with existing with MSI technology.

Bring Your Own Software / User Based Licensing

Bring Your Own Software is a trend we're noticing with end users being given a greater degree of autonomy over what software they can use at work. It isn't commonplace yet but it is a trend that I expect to continue. In addition more people are taking work home with them, using multiple computers, and virtual machines. In this environment it makes sense to have licensing available per user instead of per computer.

I think having end users in charge of their software will drive a great deal of bottom-up innovation. End users are often closer to the problem and are more able to determine if a piece of software will make them more productive. BYOS will open up the enterprise market to the same level of innovation we have seen in the consumer space and this will be a big boon for small startups.

Enterprise friendly user specific licensing is something we would like to experiment with in the future.


What is Next?

Much of this infrastructure is being built to support our own applications. Once that is in place we will start a long private beta before launching a broader public beta.

To make sure that we are building the right thing, and that this is something that people will actually want to use, we need to hear from you! So please fill out the survey below and forward this post on to others you think would want a service like this.