An Argument for Building Your Own CMS

By Deane Barker • • 3 min read •
AI Summary

This post argues for the benefits of creating a custom Content Management System (CMS) tailored to specific needs. The author discusses the limitations of off-the-shelf solutions, emphasizing greater flexibility, control, and the potential for better performance when building a CMS from scratch.

Content Management Systems just don’t work. : This is an excellent post about something we’ve discussed before – is a “boxed” CMS really worth it? For instance, in this excerpt, the author is struggling with the decisions that the vendor or platform makes for you:

See, the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more “opinions” it has. And the more “opinions” it has, the more likely one of them is going to really tick you off.

I can relate to this. We work with one system in particular that makes an astonishing array of presumptions about how you’re going to use it, and if you try to step outside those presumptions, demons fly out of the abyss and try to suck your eyeballs out.

This goes back to a previous discussion we had about Content Management as an API. In that post, we had a great experience with hand-rolling a CMS. Sadly, in another situation it was the exact opposite – we tried to hand-roll something simple, but the client wanted more and more “CMS-ish” features, and there came a point where we realized we had spent so much time and effort that we could of purchased a commercial system and been better off.

For me, the solution is a boxed system with a great API. In fact, ensure that the system is built from the API out, rather than the interface and publication layer in. For now, Episerver has filled this need for us. eZ publish is good too, and Ektron’s API is getting better and better every release (though they’ve had the distinct disadvantage of backing the API into the product, which makes it so much harder and longer, as they’ve been fleshing out this API for about four years now, and are just now getting close to done with it….)

So, in the end, I don’t agree with the author’s contention that you just need a good Rails/Django developer over a boxed CMS. He says it’s an over-used point, but I still believe you just end up re-writing too much functionality in the end.

Links from this – Why Boxed CMSs Can Suck November 22, 2006
I’ve Never Met a Boxed CMS I Like : SitePoint has a brutally accurate post about CMSs and making them run actual Web sites. The first issue is that the very nature of a CMS is not easily boxable, without creating an application that tries to do everything for everyone and fails at doing most things...
Links from this – Content Management as an API October 2, 2007
A good CMS is built from the API out, not the interface in.
Links from this – Your Interface is NOT Your Application May 23, 2006
The interface you interact with when using your CMS is only part of the picture. You need to be concerned with the API that lies under that interface as well.