I often tell customers that comparing the services of an agency and implementation specialist like NPG to the plethora of commercially available CMS platforms available is difficult.
CMS platforms and the companies that distribute them are vendors that sell software built to fit the majority of use cases they see. On the other hand, CMS developers craft solutions using a variety of available tools to fit your specific requirements. In some cases, a solution may start with an off-the-shelf CMS package; in other cases, it may need to be built from the ground up.
Yet, for some reason, this explanation still brings about confusion in people, so this week, I’m hoping I can clarify the difference with just a bit more color and clarity.
Defining “CMS Vendor”
A CMS vendor is defined as an organization that creates, maintains, and ultimately distributes or sells the platform. In the modern world, this means companies such as Sitecore, DNN, Adobe, and the many thousands of other companies that play in this space.
The commercial CMS space, where these vendors mostly play, is littered with companies that create and distribute content management solutions. In addition to the appeal-to-the-masses solutions I outlined above, you also have industry-niched solutions that are focused on more particular use cases.
Either way, the job of a CMS vendor is to identify a niche or broad appeal, define and develop the most common use cases, and then mold their product to solve as many of them as possible.
CMS vendors are interested in one thing and one thing only: license fees (and all other associated revenue). There is no other goal for them to achieve. They will decide what features are included and which are ignored based on what will allow them to earn the most revenue via those license fees. Then, much like every other company in the new subscription economy, they will up-sell additional services. Migration support, ongoing maintenance, and ongoing support plans are just a few of those additional revenue streams that these companies thrive on.
The sales process with a vendor is thus much like other productized services. It begins with a series of introductory or fact-finding calls that culminate in a demo that best represents how their solution can achieve your objectives. Then the process of licensing begins, ultimately ending in access to the software or an installed copy.
Defining Custom CMS Developers
Custom CMS developers, agencies, specialists, or implementers are on the complete opposite side of the spectrum from the commercial vendors above. The best analogy that I can think of would be comparing a custom homebuilder to a large-scale homebuilder.
Think of a local homebuilder who works on a limited number of projects per year, and pit them against Pulte, K Hovnanian, or Toll Brothers. The latter are seeking out industry-wide trends, trying to come up with designs that appeal to the masses and allow for minimal design-oriented changes. With these builders, it’s rare that you can customize the functionality or layout of your house. They will offer you choices in lighting fixtures, kitchen cabinets, paint colors and quality, and perhaps exterior siding, but this is all within the confines of the existing cookie-cutter layout and architecture.
With the boutique builder, on the other hand, you may have access to hiring an architect and sitting down to custom-build your house to your specifications from day one as opposed to choosing from a menu. The experience is totally different, and the house is built around your unique wishes and requirements.
This is precisely the difference between a custom CMS developer and a CMS vendor. The CMS vendor will wow you on the walkthrough of their property, AKA the “demo.” Then they will show you how you can customize the look and feel to meet your needs. But in reality, you won’t be able to change how the product is actually architected, how the functionality is defined within the admin portal, or how it handles front-end use cases.
The process with a CMS developer is much like the process of custom-building a home. You sit down with an architect (what we call the “discovery phase”), define your requirements, and they craft a findings document and completed architecture for the entire project.
What about open-source platforms?
You may be asking where open-source platforms fall into this discussion of commercial CMS vendors versus custom CMS developers. The fact is, open-source platforms are a bit different than commercial packages. They carry features off-the-shelf much like commercial products, but are not supported by any one organization. The community maintains the project and codebase, and the implementer relies on these platforms as the basis of your project.
These platforms are typically license-fee free, though in some cases, there are companies that back the open-source project looking to monetize on “enterprise-level” offerings of the same package, such as WordPress VIP or Acquia.
Things to Consider
Having explained some of the differences between a vendor and a developer, I think it’s important to spotlight the most major differences in how each side would approach a problem, opportunity, or other issue related to your project.
1. Developers think broadly about building solutions. CMS vendors think about configuration.
This isn’t meant to say that CMS vendors have no eye toward solutions. They simply look at achieving them differently.
In sticking with our home-building analogy, a developer looks at tools much like a carpenter looks at materials. If you tell your carpenter to build out your basement, they will know how to frame walls, utilize drywall, wire out the electricity, and install fixtures. They have a depth of knowledge about parts and how to use them—in their head, they often already have a plan of attack within minutes of seeing the situation at hand.
This is directly analogous to the developer, who has access to a similar selection of tools and parts. Both the developer and the carpenter see a blank canvas, and they know how to build creative solutions on top of it.
CMS vendors and those implementing commercial CMS solutions are much more limited in the tools available to them. In many cases, the codebase of the commercial CMS is not open source. This means there is only so much change they can affect per project. Even if it was open-sourced, in most cases, digging deep into the code would not be easy given the relative size and complexity of these packages.
Because of this, when working with commercial applications, most CMS implementers rely on the tools available to them to accomplish the task at hand. This means they are doing more in terms of configuration than actual development. And because of the nature of this practice, configuration never really gets you 100% of the way to where you want to be. This is the biggest difference between CMS development and CMS implementation.
In a way, open-source platforms are caught in the crossfire, a grey-area of sorts. Open-source CMSs are basically built more from the perspective of being a platform as opposed to being a package. This means they are built more for the developer with the ability to dig deeper into the codebase to make changes. At the same time, they are also built to be extensible via plugins (WordPress), extensions (Drupal), or both (Joomla).
However, this capability has created the biggest problem people have with off-the-shelf, open-source CMSs: the inability to understand if a developer is actually a developer or just a “themer.” It’s nearly impossible for a client to figure out if the person they hire can actually code, or if they’re just adept at installing some plugins and making them work together.
This is partly why the procurement of a CMS and a development partner is so difficult. It’s hard to know what you need, and even harder to know if the folks you are talking to are capable of completing the task at hand.
2. Developers deliver an asset. CMS vendors deliver a monetary liability.
Licensing a CMS package is exactly that—licensing. Since I’m all about real estate analogies today, the licensing of a CMS should be thought of as renting an apartment or an office. You have access to the features of the system and you can perform some level of customization, but there are limits as to the extent of the changes you can make. You never really “own” the compiled package.
Sure, you may own the front-end implementation of the channel your users experience, such as a website or the data in an API. But in almost every case, that front-end experience isn’t interchangeable or easy to make use of if you leave the system. In my book, anything you keep spending money on but retain no rights to is a liability.
Developers, on the other hand, develop a custom solution crafted to your exact requirements. This becomes an asset that you own, and it can add value to your company.
Yes, much like real estate, ownership of technology means maintenance and upkeep. But honestly, you’d need that with licensed software too. The difference in this case is that the time and money spent on continuous improvement to a custom-built solution make the solution intrinsically better and add value to the asset.
In the case of renting a CMS, you are not enhancing the value of the product at all, but rather just continuously bending and twisting it to (kind of) do what you require.
3. Developers are interchangeable. CMS packages…not so much.
Prospective customers are always afraid of “vendor lock-in.” It’s the most common concern I hear about when telling people what we do.
The thing is, vendor lock-in with custom solutions is actually a non-issue.
When you own an asset and a codebase, finding help to maintain or update it is never too difficult. In fact, it’s easier to swap a developer than it is to swap a platform that you are dissatisfied with. Think about that for a second: A developer who you are dissatisfied with can be replaced in a matter of days. But if you are unhappy with your CMS or the company that provides it, you are just plain stuck for a long time.
Back to real estate for a moment, if I may. Imagine that licensing a CMS is a long-term lease, completely the same as renting a location for a retail establishment. You will lease the facility, then put many dollars into customization, but you are still and always will be at the mercy of the property owner.
The one thing that’s different is that with a licensed CMS, the provider has no legal standing to provide you with any level of continuity of service. You are signing a lease that has zero protection for you, the “tenant.” This means at any point, the company can stop supporting the platform you are on, leaving you high and dry. Even worse, they could just go out of business. Licensing a CMS is a highly risky endeavor where you are assigning rights to a third party that you would never consider assigning as a lessor in almost any other setting.
4. Either way: You need implementation.
One last thought to leave you with. No matter which way you go—commercially licensed CMS, open-source platform, or custom-built CMS—you will always need implementation support. It isn’t as if licensing a platform means the vendor will take your website as it is and migrate it, or design you a new one. They will rely on their creative partner agencies to provide that service to you—and that implementation typically costs a multiple of the license fee.
The thing to consider here is that implementation costs are, in many ways, influenced by the platform you license simply because of the laws of value pricing.
I know I’ll take abuse from other agencies by telling you this, but agencies will charge a price that is directly proportional to the value of the platform you are licensing. That is why a site on Adobe Experience Manager can cost you $500,000 to design, implement, and deploy, while the same site on WordPress may cost you 10% of that budget. The hard and fast rule is that implementation is 3-10x the license fee. I realize that range is wide, but it almost never goes lower than that. And in some cases, it can go higher.
With that calculation in mind, why would anyone choose to license a platform that will lead them to unfair pricing practices to create something they don’t own and have literally no legal protections over?
I have no idea. But it happens every day.
Wrapping Up
At the end of the day, you have to ask yourself one thing: How beholden do you want to be to another company? When you work with a CMS vendor and buy what they’re aiming to license out to you, the sales process will probably be dazzling—and then you’ll be stuck.
On the other hand, working with a CMS developer gives you infinitely more flexibility from the get-go. And it’s that level of flexibility that will allow you to build something truly special, something that can serve not just as another tool in your company’s toolbox, but as a valuable asset that you can make better and better over time.
