I get asked the same one question by almost every prospect I speak with:
“You don’t really build a whole CMS project from scratch, do you? Surely you must use some software somewhere?”
The truth is, yes, there is almost always some third-party software that we integrate into our CMS projects. Building out an entire CMS without third-party tools can be a massively time-consuming and expensive proposition, after all, so it only makes sense that when viable options exist, we take advantage of them.
The question that prospective clients should be asking, however, is a little bit different. I’d prefer to be asked something along the lines of:
"How do you decide what third-party software packages to integrate into your custom CMS projects, and when to use them?" 
This question is much more interesting—and important.
In many ways, access to third-party libraries is one of the benefits of building a custom CMS. Many of the best libraries being developed with cutting-edge technologies take many months or years to become compatible with off-the-shelf platforms—and usually only with some hacking and adjusting to be made compatible. On the other hand, custom CMSs allow site owners to embrace new technology piece by piece as it becomes available.
This means that as a proprietor of a website running on a custom platform, you actually have more options than those other systems with libraries of thousands of plugins.
But first, let me conceptually talk about third-party software and how we view its usefulness.
Obviously, as stated before, building each CMS project from absolute zero is a costly and time-consuming proposition. Our approach to each project typically starts with a software base that we developed as a “foundation” for the project. This gives us a head start in making your project a reality.
As we progress with the development of the project, we may at times see functionality that is ubiquitous—a requirement that is common and seen in use often on the Web. It is in this scenario that we’ll consider using third-party tools that are built specifically with this particular use case in mind.
Secondly, I want to clarify our position so there is no confusion. Most of our messaging and written content focuses on the avoidance of software platforms. By “platforms,” we are referring to large pieces of bloatware such as Drupal, Joomla, and the like. It’s important to clearly delineate the difference between third-party software that can be helpful and a platform.
As stated, platforms are considered an end-to-end solution. This post is referring to “pieces” of software that may become part of your ecosystem. This can mean anything from HubSpot for marketing automation, CKEditor for your WYSIWYG editor, or any number of software packages available on GitHub or similar that address a specific need or requirement.
Yes, third-party software comprises both SaaS applications AND code libraries!
With that clarification in mind, and knowing that it’s inevitable that you’ll turn to code libraries to make your project progress easier and faster, here are a few key points to consider when evaluating third-party software solutions.
When Is Third-Party Software the Right Choice?
Typically, deciding when to use third-party software is a fairly simple decision. The formula is primarily dictated by the economics of the prescribed functionality you are looking to achieve, with some constraints.
If you look at one of our previously mentioned examples, CKEditor, you will find a complicated piece of software that has taken many years to develop, and serves one primary function as a text editor. In almost every CMS project, it makes zero sense to redevelop a WYSIWYG text editor that can take many hours of manpower and produce less than desirable results.
Likewise, when building front-end applications, there are many libraries that can make a designer or developer’s life easier. So why recreate those pieces that are lightweight and already work well?
The constraint, which I’ll speak about more shortly, is mostly centered around your ability to maintain control and flexibility over your system. If you are looking to choose a WYSIWYG software package for your CMS, choose one that has had a successful history, minimizes your security concerns, and has a small footprint.
While I’ll dig more into what to avoid, always think in terms of utilizing software that will not complicate the simplicity of your ecosystem.
Types of Third-Party Software to Avoid
The biggest pitfall to avoid is making any third-party software provider or package the centerpiece of your system. This, in almost all cases, is a dangerous scenario. One of the reasons you choose a custom CMS platform is for its flexibility in addition to having ownership and ultimate control.
When you build your system utilizing a third-party chunk of software that is not proven, you are ceding that control to the software.
We ran into a scenario like this with a prospective customer recently. Their planned set-up was a custom CMS that utilized a third-party infrastructure as a service (IaaS) platform, Firebase, to power their data storage.
Mind you, we’re not averse to Firebase by any means—much of what the software is capable of doing is impressive, and we have used it for client projects before. Where we get weary is the thought of basing an entire company’s infrastructure on the platform when there is really no reason to do so.
In that customer’s case, it made more sense to base their platform on open-source technologies such as MongoDB within a LAMP stack and build out a solution that wouldn’t leave them solely dependent on how Google choses to maintain the Firebase product.
Another area of concern is the lifespan or health of the project or software provider. Any time you use outside software, you are giving up control and choice. It’s important to carefully consider the long-term prospects of any chosen solution.
Back to our previous example, Firebase would be a good choice to power real-time text editing or any other fast I/O application. And you can be reasonably sure that Google will maintain the offering. Overall, Firebase would be a good choice to augment your system—but again, not be a centerpiece!
To take it a step further, let’s say that a startup just launched a Firebase competitor. It could be an interesting, but ultimately risky proposition you would have to carefully consider. Would the features of this new system outweigh the risk of potentially having to rebuild in an urgent manner if the business goes under?
Finally, be careful to choose the most efficient software possible. This may not always be the largest player in the category you are researching. CKEditor is a great tool for WYSIWYG, for example, but it is comprehensive in that it’s trying to handle 99% of all requirements for a text editor. If you need a simple editor that just bolds, italicizes, and changes font sizes, you can find something more lightweight. Your application will run faster that way, and you’ll have fewer headaches along the way.
Beware Saas / IaaS
In my last point, I spoke about Firebase, which is known as an IaaS solution. There are many services out there that are taking pieces of infrastructure and bundling them together with some management software with the end goal of making the end user’s life easier.
I’m always very weary of these providers and the solution they bring. Again, it comes down to flexibility and control.
One example popular today are services that make developing and scaling applications “simpler, in a streamlined manner.” That is their wording, not mine. Heroku comes to mind as a player in this space, though there are many other, and my criticism is not solely focused on their offering. I could easily even include Amazon’s AWS services, which are also focused in this area, especially EC2.
While these platforms may be good for spinning out applications quickly, I do not believe using them to build a scalable CMS with a focus on longevity is the smartest decision. Conceptually, their platforms are solid, but it is a risky endeavor to base your entire business on what those providers are offering at this very moment.
Remember, if you build on top of a proprietary environment, you are essentially making that provider a business partner. Utilizing a system like Heroku or EC2 is different than spinning out some servers utilizing Rackspace or AWS. You are ceding control to their ecosystem, and that means you will have to make changes and adjustments to your project to make it work within that world. That also means that eventually moving from one platform to another will be difficult.
Sure, Amazon isn’t going anywhere any time soon. The risk factor of losing their services as a provider due to them going out of business or force majeure is nil. But with some smaller players, why take the risk?
Even worse, consider this: EC2 or Heroku may be great solutions today. But where were they 5 years ago? Can you really build for the long term on those platforms knowing that there could be a new player tomorrow that your tech team will want to consider once you’ve already taken the time and the money to build your system?
Conclusion
Much of this post is based on my own biases. I am completely aware of this! As your “Mercenary CTO,” I always focus my recommendations for technology, software, and infrastructure on giving you the most control at the most cost-effective figures that will ensure a certain level of longevity.
In my 16 years of working in technology, I have seen solutions come and go. Yet the most successful businesses we’ve worked with have avoided getting into bed with the technology of the moment and stuck with tried-and-true solutions, moving to third-party software only when the economics made sense and the choice didn’t limit their flexibility or options going forward.
I still recommend utilizing a similar mindset when evaluating your options. Be open-minded to possible solutions, but never commit to anything that will limit your ability to grow in a flexible and scalable way.
