Build vs Buy vs SaaS: content management systems

The question of building your own content management system or buying an already established system comes up regularly within companies that are either starting from scratch, or more commonly are dissatisfied with their current option. This article tackles the issue from both sides and investigates each option in detail, while exploring a third viable option that can mitigate the common problems with the other solutions.

Section titled What is it that you are trying to build, buy, or subscribe to? What is it that you are trying to build, buy, or subscribe to?

In the context of managing content, we are usually talking about building or buying a CMS, the heart of any content strategy in an online setting. A CMS is essentially a company’s foundational framework that shapes the way communication with users is conducted, and how content is organized within the organization itself. This may seem obvious, however putting this fact into context can actually nudge you in the right direction of finding your answer. Let me explain:

Section titled Who are you doing all of this for? Who are you doing all of this for?

It’s quite clear that the end goal for any content strategy is to create engaging material and distribute it in the most efficient way, resulting in a high return yield. Essentially, creating a gripping experience for your users is the goal here. On a deeper level, this also means creating an environment for your content creators, developers, marketers, and project managers where they are empowered to deliver top notch experiences for your visitors.

So how does this connect to the original question?

Section titled The Build/Buy dichotomy The Build/Buy dichotomy

Earlier, the “buy” options were extremely limited in their capabilities, leading to many enterprises creating their own CMS just to manage their content in the way they wanted. Granting customized and personalized user journeys was usually limited to the “build” option, leaving smaller businesses with limited capabilities, and big businesses with a huge drain on their resources. A simple analogy would be trying to get a bunch of stuff from point A to point B and either:

A) Having enough resources to first build a straight road from A to B, and then building your own truck to deliver the material.

B) Having limited resources, you choose to pay a big sum upfront to a company to use their road and their car, having no say in the route or the structure of the car itself. You just know it connects A to B. While it gets the job done, the road is nowhere near a perfectly direct line, and instead of a truck, you end up with a small sedan. It gets the job done, however far from optimal.

This obviously meant bigger businesses had to sink an incredible amount of time and money just to build and maintain the “road”, and smaller businesses were left with medicore options with huge upfront costs.

What does this mean in the real world?

Section titled “Build” as a solution “Build” as a solution

In this case, you obviously will have a great amount of freedom in choosing what to do with your custom-made CMS. This is in fact the most important advantage of taking the “make” route. However, there are many pitfalls that are not that easy to ignore:

• Resource intensive: Again, this is a very obvious attribute. Building your own CMS requires the full commitment of a development team, and a huge amount of time to create a quality product. It is not necessarily re-inventing the wheel per se, but it is like building a wheel from scratch just so you can customize its appearance at the end, without any meaningful design improvements to the structure of the wheel itself (not to mention, you are not even in the “wheel making” business).
• Lack of proper documentation: If you are making your own custom-made wheel from scratch, then creating the user manual is also on you personally. The development team can do their best to create a good documentation system, but you can be certain that it’s never going to be as comprehensive as the documentation in a “buy” option. In a buy scenario, the product has been tested thousands of times by different users. The sheer amount of feedback coming from completely different cases can never be compared to the isolated case of a “make” scenario.
• Lack of support: An established CMS comes with an experienced support team, something that is not really the case with an in-house built CMS. What is even worse is that sooner or later, the original developers in charge of creating the CMS will leave the company. This is a massive issue, as the only guidance left for the rest of the team (and the future incoming developers) is the extremely limited documentation. This is in fact a crippling problem that has almost no workaround, except for sinking more and more resources into creating better documentation after going through a steep learning curve.
• Intensive maintenance: Creating your own road means you are also in charge of maintaining it. Keep in mind that “maintenance” is a very general term and includes a huge set of issues within itself. It’s not sufficient to simply have a functioning CMS, but key issues like security updates are whole different stories on their own, which will result in yet another set of sub-issues (like SEO optimization). A competent team of specialists must be engaged with the CMS at all times, just for it to function properly. This is another not-so-hidden cost of the build option.

Building a CMS is a serious investment, one that in earlier times was usually unavoidable for enterprises. As mentioned before, in previous years, delivering personalized experiences was very limited in the “buy” options, leading to the popularity of the in-house systems amongst bigger companies.

However, these investments come with an array of deep structural issues. These issues are only getting worse as users continue to diversify their online journeys with different devices and touchpoints. More on that a little bit later. First, let’s look at the traditional counterpart, the “buy” scenario.

Section titled “Buy” as a solution “Buy” as a solution

Traditionally, buying was a viable answer to the massive problems of building an in-house CMS. It would immediately fix the problems with documentation and the huge ongoing costs. Some of the other problems though would be only partially solved, not to mention problems that would be unique to the buy option. For example:

• Maintenance: While maintenance was much simpler, the company would be completely dependent on the CMS vendor for any functional updates and new capabilities. If a new technology would emerge, which would perfectly fit the needs of the company, they had to first wait for their vendor to acquire the tool. This dependence on the vendor could sometimes severely hinder companies’ ability to quickly adopt new technologies and tools.
• Costs: while overall costs would be reduced, the upfront payment could still have been a problem for some. Buying a complete monolith of a system is a big investment with only a little wiggle room. The migration process is not only expensive, but also very time consuming.
• Customization: A buy option almost never gives you the same amount of freedom to create what you exactly want, with complete control over the whole process. This is in fact a natural outcome of the whole “buy” philosophy. Since the same product is made for everyone, the company has to give away control at certain points.

While buying can fix many of the problems, it comes with its own set of drawbacks. However, for both “buy” and “build”, there is a huge problem that has not been mentioned yet, one that has to do with the way our relationship with digital experiences has been evolving in the past couple of years.

Section titled More devices, more destinations, more complications More devices, more destinations, more complications

The nature of users’ interaction with the internet has fundamentally changed in the past few years. While earlier, time spent online was dominated by desktop users, today mobile internet traffic constitutes 55.64% of the total global traffic.

The diversity of touchpoints is not limited to desktop computers and phones. With the steady growth of IoT, emerging technologies like wearables, voice activated assistants, and VR headsets are starting to take a considerable share of the traffic. Every prediction about the near-future of our connection to the internet, points to a diversification of the entrypoints (see here and here as examples). This is why Gartner reports that 63% of enterprises expect they will achieve financial payback in 3 years for their IoT projects, as more and more enterprises are trying to catch up with this diversification of entry points.

So how does this connect to the build-or-buy question?

Going back to the A-to-B analogy, imagine adding not one, but multiple new destinations, each in a different direction from your starting point (A). Now faced with delivering material to points B, C, D, and E, one has to either build and maintain roads to each destination, or pay for multiple companies in charge of each route.

Section titled Multiple CMSs and content silos Multiple CMSs and content silos

For both “buy” and “build” options, a single CMS is most usually not capable/suitable for running operations on multiple fronts. This always leads to companies acquiring multiple CMSs, one for websites, one for mobile devices, etc.

There are many problems that come from having multiple CMSs. The most obvious ones are the extra costs and time that are required. Or the fact that presenting content on any new emerging technology is going to be delayed greatly, since a new CMS first has to be put into place.

However, there are even deeper problems with the potential of hindering the content publication process altogether. These deeper problems are the result of having multiple content silos. With more than one CMS in operation, the process of creation and publication of content has to be distributed across 2 or more CMSs. This means:

• Less collaboration: Working together with other teams (and even within the same team) is going to be really challenging, when two (or more) completely separate CMSs are in charge. Editors, marketers, and developers have to be in perfect sync in order to publish and present the optimal content experience, something that is practically impossible while operating with multiple content management systems.
• Inefficient process: Since content is scattered across different systems, in many cases the same piece of content has to be created multiple times, once for each CMS. This means the team members in charge of these tasks have to waste their time with mundane duplications instead of creating new assets.
• Complicated content repurposing: Finding specific content pieces is going to be considerably harder when dealing with more than 1 CMS. Furthermore, duplications and potential blind-spots make it even harder to find specific pieces of content. As a result, repurposing older content becomes much harder than it should be. What is even worse, is that due to these problems, automating parts of the process becomes harder too. It is essentially a vicious cycle, where unoptimized content strategy leads to fewer chances for automation, which again goes back to make the content strategy even less optimized.

Section titled What is the solution then? What is the solution then?

Let’s go back one last time to our analogy:

Having to deliver things to multiple destinations in different directions has led to the need for a more efficient way of doing things. A solution which would be able to deliver everything simultaneously, without having to create a whole new road system.

This is why we have postal services in real life. After a certain point, it makes no sense to do things on your own in every step of the way. If you have an online shop, you shouldn’t be also working as the delivery man. It is just not efficient.

So instead of taking things from point A to B , C, D,and E in the traditional way, you gather everything in the same place (A), and simply hand them out to a delivery system which takes them wherever they need to go.

In the context of content management, this would be the 3rd option: Software as a Service

Section titled “Service” as a solution “Service” as a solution

The modern approach to content management allows you to use a single CMS to deliver content to every single device. This means everything would be managed from a single centralized content hub, instead of multiple content silos.

The “service”, or more specifically “software as a service” (SaaS) approach is made possible by the emergence of the modern “headless” systems. These systems function by handling all the content in one place and delivering them to any necessary endpoint through APIs. Just like the postal service in the analogy, “headless” systems take your content in a centralized place and deliver them simultaneously in all directions, without you having to worry about maintenance, the route, the road, etc.

Going with the “service” option fixes all the aforementioned problems with the “make” and “buy” solutions:

• Maintenance: There is virtually zero maintenance on your side. Headless systems take care of all the extra work by definition. Their unique architecture and best-of-breed philosophy means that all the heavy-lifting for updates and maintenance is done on their side.
• Costs: “Service” costs considerably less than building your own systems. When compared to the “buy” option, the advantage of hiring a service is that you will pay as you go. This means, instead of a huge upfront sum, you can start small and gradually scale your operations. This means lowering the risk factor, as you can first experience the new system on a small scale, and move forward only if you are happy with it.
• Documentation and support: While “make” options have extremely limited support and documentation, “service” options have substantial documentation and support systems. Unlike “buy” options which usually offer different functionalities, the services are highly focused solutions that are solely concerned with content management and digital user experience, resulting in more substantial support systems.
• Content hub: As mentioned before, a centralized content hub is superior to multiple content silos in every way. All the problems associated with silos (such as collaboration) will disappear immediately after moving to a single hub.
• Customization and freedom: It is true that an in-house built CMS will fit your needs perfectly, since it is made specifically for you. “Buy” solutions usually fail to live up to that level of customization. However with “service”, you will experience complete control over the management of your content. The “headless” nature of these solutions leads to a situation where the back-end and the front-end are separated, giving you 100% control over the presentation of the content (front-end). Furthermore, these solutions have been offering services to companies of all kinds and sizes, from small online shops to massive media companies. This is possible through their best-of-breed approach, which means you can easily integrate any extra tool that you may wish, scaling your operations as you grow. “Service” solutions let you build your own stack of technologies and tools, which unlike “buy” options, makes it possible to personalize your management process in addition to your content itself.

Section titled Storyblok: The “service” solution to content management Storyblok: The “service” solution to content management

Storyblok is a headless CMS that solves the build vs. buy issue by offering content infrastructure as a service. Storyblok’s unique approach to content management gives developers freedom of choice, and marketers complete control over their content by using Content Blocks and the Visual Editor.

You can try Storyblok for free to see how the experience looks like. You can also reach out to our specialists to get a more in-depth understanding of how it works.

Head out to Whitepapers & Guides to download the latest articles on content management and digital user experience.