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:- 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.
- 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.
- 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.
So, IP is what it is, and an incomplete vision can always be worked on. But what’s changed most over recent years are the enabling technologies that materialize a SaaS business model, such as subscription billing, marketing automation, and, most of all, cloud management tooling.
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.We wipe 90% off your CapEx budget for building cloud and give back much of the remainder as variable cost OpEx. You will only be paying for the compute and storage each new client needs. These low costs are made possible by container technology. We built a global grid, and you benefit from the economies of scale we receive buying volume capacity from hyperscalers.