The Problem with SaaS CMS Platforms - NP GROUP

SaaS CMS platforms offer many features, but are they the best choice for your business?

Skip navigation and go to main content

New Possibilities Group, LLC

1033 Route 46 East, Suite 107
Clifton, NJ 07013
(855) 674-7687

The Problem with SaaS CMS Platforms

  1. NP Group
  2. Blog
  3. BlogThe Problem with SaaS CMS Platforms2020-06-05The Problem with SaaS CMS PlatformsIndustry News
    New Possibilities Group
The Problem with SaaS CMS Platforms
Need a second opinion? Show us another firm's proposal and we'll make a counter offer same-day. Sign Up Now.
You might also like...
Cutting Corners: How Digital Agencies Reduce Costs at the Expense of Quality
View
How to Develop Custom Software During a Recession
View
Has Software Development Gotten Easier or More Complex?
View

In recent years, software-as-a-service platforms have delved more and more into the CMS space. This is in part because of the prevalence of all software moving to subscription models, but also in response to the fact that websites are somewhat complicated. For some users, the work required to develop a website can add to serious budgets that many small businesses can't afford or justify.

So, much like everything else, there is a time, place, and use-case for a SaaS CMS. However, these platforms do have significant shortcomings, and as we are seeing more and more enterprise-scale clients inquire as to their capabilities, we feel it's essential to review in detail what those shortcomings are and how they can affect your day-to-day marketing operations.

First, to remove all doubt, I want to define what we see as being a SaaS CMS. For this post, we're looking exclusively at systems that provide the design, development, configuration, and hosting all within a single umbrella. Players in this space include Squarespace, Web.com, Webflow, Shopify, and even other higher-end providers such as HubSpot. Each of these offerings is mainly playing in the fully-managed CMS space, one way or another. However, we are not going to cover headless or other content-first systems as we've already covered that topic in detail in prior posts.

With that, let's dig in…

Who Benefits From a SaaS CMS

I've noticed a trend from past posts, wherein I review the problems with specific solutions, and then when wrapping up the post, explain who would benefit. Today, I am going to do it in reverse because we all need a little variety.

I've said it one million times before and I'll repeat it – there are always multiple ways to complete a project. And it applies here as well. Some folks would benefit from these types of systems. If this sounds like you, then you should take a look into them and explore the possibilities:

  • Small business with limited funds.
  • You have zero technical knowledge and are not interested in hiring an agency.
  • Your site is informational but not meant for lead generation.
  • Online is a secondary concern, and you simply want a minimal presence.
  • You have few to zero third-party integrations and want to have everything you need working under a single umbrella.

If any of those scenarios apply to you, then for sure, you should look into these systems. With that said, let's look at where these platforms will start to be problematic for more sophisticated use-cases.

Limited Technical Flexibility

This is, for the developer in me, the most problematic part of the equation. Whenever automation is added to something, it's at the cost of flexibility. These platforms don't allow power users to build any advanced functionality. The majority of developers will almost always prefer either an open-source option or something licensed with source code availability. The reasoning for this is because systems that are on-premises or installed on a local server, serve not only as a CMS but also as a foundation from which custom functionality can be developed.

People often ask me what specific type of features they would be unable to build on these platforms. Truth is, it's almost anything that would require access to source code or raw files. An analogy makes the most sense here… These systems are like Duplo LEGO sets – big pieces, but less you can do with them. Whereas with a proper LEGO set, you can get a lot further, as you have more detailed and specific pieces with which to work.

Finally, traditional development procedures are not often available on these platforms. As an example, rarely do these platforms have comprehensive development sandboxes with proper deployment procedures. There is no concept of code repositories or other tools developers utilize when adhering to best practices. Granted, most people using these platforms probably don't care, but if you are a corporate environment or make frequent changes to your site, this will be limiting. I find it very difficult to believe that any enterprise environment can run on Webflow or Squarespace – they don't even market to those users. On that note, though, I do see Hubspot making inroads toward corporate marketing departments. In fact, we have completed implementations within their CMS for larger enterprises. So it is now becoming more prevalent.

Rigid Templating Engines

I have yet to run into an experienced designer or front-end developer who likes working with these systems. Ask someone forced to work within one of these platforms how their experience is, and often you will hear a negative series of feedback. First of all, each system has its own templating engine that must be learned and adapted to. There isn't anything universal between them other than HTML.

The second issue is that these systems take options away from the developer to make it easier for non-technical folks to utilize. So, as an example, while a good developer may just adjust HTML tags directly, these systems may conceal where those tags exist in the templates to favor some tool hidden in another place. This is frustrating to real developers who could make the change in seconds.

Finally, the idea of a fully-customized design being feasible on these platforms is somewhat misleading. While you could definitely design a site from the ground up and host it on these systems, it is worth noting that the complexity of working within the capabilities and functionality of the platforms means custom design will take a long time – which translates to budget. As such, we don't necessarily see a significant budget difference for a client who chooses WordPress versus a SaaS CMS when the project calls for 100% custom design. The best success is had when you utilize a pre-made template and simply modify it for your purposes, which most small businesses would do anyway.

Content is Secondary

I find that one real problem with these systems is they are so template-centric that they lose track of content management as a requirement and focus area. This means they are weak in defining content types, managing sophisticated collections of content, and then distributing it accordingly. These tools are better at a series of singular templates for informational purposes. However, for large quantities of material, they fall short. This is why, as I mentioned above, these platforms are suitable for limited page count sites, where you have more of an informational goal than content-heavy destination sites.

Of course, the vendors will tell you differently, and they may have tools available for recurring content such as blogging, etc. But in reality, when building a site, you often see all sorts of content areas that are repeating. I like how CMSs such as Drupal make it easy to define content types. Also, headless systems do a great job as they are designed to be content-first. But again, in the case of these platforms, the focus is so heavy on the visual and the ability to edit discrete templates that content is often forgotten.

Vendor Lock-in

Unfortunately, these platforms feature the absolute worst-case scenario for vendor lock-in. Often, there is no allowance for exports to reusable formats. If you can export your site, it'll be in HTML code that is somewhat proprietary and almost uneditable. Moving from one platform to another will be hyper-challenging, but that is precisely what these companies' business models are all about. They want to become a lynchpin and keep you on the platform for as long as they can.

Because of this, we tell clients to consider where their next move may be, down the line. If you hit some metric of success, what would you want to do then? And in the case that you may expand and or migrate to a new system, how well will your initially chosen platform migrate the content? This all must be carefully considered now to avoid headaches later.

Unpredictable Roadmap & Longevity

Another issue with heavily investing your infrastructure with a third party is the idea of longevity and future enhancements to the system. If you are making a significant investment, you want to know that the system underneath your investment won't change and that the company providing it will be around for a while. Sadly, you can't really be assured of this to any reasonable extreme, especially with the smaller players in this space.

In the worst case, the provider could go out of business or stop offering the product. That would be catastrophic for users, depending on how it happens. And in a slightly better scenario, the platform continues to evolve, requiring you to continually adapt to new features, functionality, or whatever else they are changing. Less catastrophic, but still something outside of your control.

There isn't any real way to know where your provider is going to go in the future. Sure, this can happen to any software package. However, with on-premises software, or software you install on local servers, you have more control over when updates occur and whether you opt-in to them at all. Most large-scale enterprises will appreciate, if not require, that level of oversight.

Slow Innovation

One area of frustration for us, as an agency, is how slow these platforms are to innovate to new innovations. By "requirements," I mean either client requirements for new features in response to fast-moving technology, or on the other hand, compliance and third-party requirements that may be needed. The web moves fast, and marketers are nimble creatures. Being handcuffed by some hosted solution isn't beneficial.

Sadly, there often aren't many options for website owners to consider when technology is evolving, and their platform is behind. In some cases, it can take many months to adapt to a new technology, which can leave you chasing competitors to catch up later. This tends to be less of an issue with on-premises solutions that give you many options for extensions, plug-ins, or source access.

Wrapping up

SaaS CMS platforms provide a decent, comprehensive solution to many small businesses who need help on a budget. For that purpose, they excel at their mission. However, it must be carefully considered whether or not they are the right choice for larger businesses that have more sophisticated marketing operations and may need to get down a bit deeper to the nuts and bolts of how their site really works.

If I had to make a recommendation, I'd have users consider my points above before making a choice. And if there is a long-term expansion plan, prepare for the idea that all of your work on a SaaS CMS will not migrate, and your next development project would be a complete rebuild. Chances are, that is more likely than not when an upgrade cycle occurs in the future.

Get Started With Your Project.

Please select and fill out all options below

What do you need help with?

Website Design / Development

Custom Mobile or Web Application Development

Website Maintenance / Monitoring

Accessibility Services