High-performance for cloud application development

In my last article, I shared the recent story of a white-label client who launched their software-as-a-Service cloud offer and grew in value from 2.5x to 12x revenue over two short years. Today, we’re looking slightly further back into the life cycle of an application to understand why some make it to a $2 billion SaaS acquisition—and some do not.

Since my first management buy-out in 2007, I’ve worked closely with hundreds of digital agencies and software vendors. In that time, I’ve noticed some clear patterns in the applications being built and sold to clients. Some haven't changed since they were first delivered, and some have evolved into full-blown SaaS offerings with tens of thousands of subscribers.

What is it about those applications that didn’t? Why didn’t they move on? Could they still?

What blocks some apps from making it to SaaS

I’ve spoken with many a CEO about their plans to SaaSify their apps. They all believed they had the prerequisites in place: a great development team, solid product positioning, and a viable market. But what I noticed stopping them, time and time again, were the following roadblocks:

1. Ownership of the IP. If code was delivered to a third party, and the contract maintained client ownership, there wasn’t much that could be done, except negotiate a change in return for payment. Mostly, this was of little interest to enterprise-size clients, and so rebuilding something fresh was the only option.

2. Viable infrastructure. Architecting and mapping an application onto a scalable hosting infrastructure is always a major feature of any cloud offering. Whether building a multitenant service for 100,000 subscriptions or a single tenant offer for just a few hundred individual clients, some serious cloud management tooling and integrations were needed.

   This was expensive and complicated to say the least. Despite the availability of Docker-type frameworks such as Kubernetes and a multitude of third-party tooling, specialized engineering skills were needed to build it out, plus an operations/support team with hard-to-find resumes.

   For many smaller, less well-funded application builders, the effort and cost of doing it themselves put SaaS out of reach.

   This isn’t the case any longer, just not everybody knows it.

3. Incomplete vision. For some of the CEOs I met, exponential SaaS-type growth was just a fleeting pipe-dream, while others spent considerable time writing up their business plans. The blocker in both cases was usually the same: the amount of money needed to build out the initial cloud offering and effectively promote it. A common observation of mine was that running a busy agency got in the way of working toward the bigger picture. And while some CEOs could clearly articulate a wider market for what they had built, for others, getting there just seemed a step too far.

A good idea only gets the opportunity to become a great idea only AFTER it’s been implemented. I left many meetings with this playing on my mind!

An application’s journey to SaaS

Before we work out what you need to do to get SaaS, or even just do it better, let’s see what stage of the journey your application is in.

This chart shows the progression of an application on its journey to SaaS. Most applications start life in the hands of a developer or digital agency (stage 1), built for a single client. Some then evolve into products that require the agency to restructure itself into a software vendor (stage 2-3) and so on. Many apps are also built by well-funded start-ups; others come out of larger, more established vendors.

Stage one challenge: becoming a product vendor

Digital agencies with a repeatable application usually evolve into service-based product vendors.

Applications mature over time—growing up with new features and better security, for instance—but only some evolve beyond their original use case. Why is that?

Many applications begin their life cycle based on a client requirement or an entrepreneur investing time and effort to build something they believe will sell.

And many more apps have come out of digital agencies, many of which won contracts to build something clients were asking for. Those projects that were publicized then generated demand for something similar. And, in turn, those apps that gained sufficient market traction led to better monetisation and repeatable business models until they started looking like a product.

However, digital agencies offering an open-source application couldn’t sell licences unless they created some sort of ecosystem for plug-ins. Instead, they provided enhancements and implementation services, plus maintenance, thus improving growth, though still somewhat constrained by a lack of finances. This category I call the service-based product vendor, because they are making money primarily from services.

Agencies retaining IP, however, generated higher software deal values selling product licences, professional services, and maintenance. Doing so, they were blessed with stronger cash flow, which they invested—or secured funding against—to continue their evolution towards full-blown software product vendor status.

So, generally, making the first big jump from one-off application builder to full product vendor required money—and quite a bit of it.

Stage two and three challenge: leaping from product to SaaS

The next stage in the application “tree of life” is the big jump from a product vendor to a subscription-based SaaS offer hosted somewhere in the cloud.

Agencies and service-based product vendors

For many agencies and service-based product vendors, this jump was always going to be a leap too far, largely due to the cost/complexity of building multitenancy plus billing plus management services, all precariously balanced on top of a hosting service.

Even today, despite some great new tech coming to market, many aspects of SaaS are still really difficult to cobble together in-house. Assuming the absence of the blockers we covered earlier—IP and vision—sufficient resources now become the hurdle to SaaSify your app. Unless you’ve been able to solve the cost/complexity problems of cloud infrastructure, your way forward remains blocked.

Now let’s consider full-blown software product vendors— those starting up and those more established—both of which are far less resource-constrained. Quite the opposite in fact, they tend to be well financed and the start-ups well funded.

Cloud natives, especially start-ups

Start-ups these days generally plan to be SaaS from the outset. They tend to develop cloud native code, 12 Factor, and fit for purpose. However, all this means is that their apps will be optimized for containers; they still need scalable cloud infrastructure.

And counterintuitively—because they are developing the app cloud natively—the hosting components are viewed as part of the same landscape, which makes it a 99% certainty that they will default to building the cloud infrastructure themselves, emboldened by the wealth of tooling available.

Being a talented development team, with industry-specific knowledge, however, doesn’t make for an accomplished cloud engineering team. And this lack of experience usually comes back to bite the organization in the form of scaling and reliability problems, quickly followed by unexpected costs for the new hires needed to correct and rebuild.

Established software vendors

Last but not least is the established software vendor that has been successfully selling its application for years. Some still sell licences that their clients download and host themselves, whilst others may have transitioned to a managed hosting-based offer already.

Vendors selling license-only will have had little experience with the hosting issues their customers grapple with daily. This presents a steep learning curve when attempting to redesign an application for SaaS. For starters, the architecture will likely need an overhaul to optimize it for the cloud. They will need to build a cloud framework and hire an army of new engineering and support skills in the process.

For those vendors that have already transitioned to a managed hosting-based offer, surprises await in terms of the number of people and the complexity required to run their cloud service at scale.

Stage four: making it easy to launch and operate any service

With the Platform.sh PaaS, you can single-handedly manage one application (or even thousands) in the cloud without having to know anything about the cloud. We currently offer the choice of four cloud providers: Amazon Web Services, Google Cloud Platform, Microsoft Azure, and Orange Business Services. You won’t need to build container management, and there are no up-front setup costs. For each new client you sign-up, payments are usage-based and monthly/annual depending on how big the project is.

Platform.sh eliminates the need to do any cloud infrastructure management. Instead, development managers describe the hosting infrastructure and services needed to run each application in just a few lines of code.

The deployment process automatically builds and injects code changes into the development, test, or live version of the hosted application. This makes it possible to deploy changes across hundreds of web apps simultaneously, which is especially useful for fleet-wide feature enhancements and timely security patching.

This is great for developers and DevOps teams and even better for SaaS vendors that want to focus precious money and people resources on application improvements and marketing efforts.

It’s all Git-driven

Because the PaaS is entirely driven by Git (or Bitbucket), all code changes are deployed to test, staging, and live services via a simple Git push through the UI or API. For a software vendor selling new subscriptions, this means you can automate the provisioning of different-sized hosting plans— to match your price plans—and allow new customers to instantly access the SaaS service as part of the sign-up process. At this point, partner agencies and developers are ready to continue setup and enhancement work on the client’s behalf.

Also, being Git-driven means there is no need to spend time decomposing your existing apps into microservices or re-architecting for containers. Platform.sh handles all that under the hood.

A History of Helping

Since 2016, we’ve helped about 25 clients launch SaaS offerings. We can help you, too, and not just with the technical implementation. We can assist you with business planning and cloud-offer pricing. We will work with you as you gear up for launch, and we will support you thereafter making adjustments. Triage, cloud hosting support, ‘cloud first’ training, incentivising the sales team, keeping the partner ecosystem excited, pre-sales, and sales support on large deals: we’ve done it all before and can help you do it, too.

In our next article, we’ll dissect the thinking strategies that set a SaaS vendor apart from other software companies.

In the meantime, if you’d like to open a conversation about your SaaS business model or the value of a PaaS cloud infrastructure on the rest of your business model, you can find me on LinkedIn or contact me at kieron.sambrook-smith@platform.sh.