We can make it - why we are developing a publishing platform from scratch

Posted in: Beta, Team

I was recently asked by a Product Manager why the Bath Digital team was building a CMS in-house seeing as it "isn’t central to what a university does". A similar point came up at the IWMW15 conference:

It's a good question and there’s a chance that others might be interested in our thinking, so here’s how I explain it.

It is central

First of all, online publishing definitely is central to what a university does. The job of a university is to advance knowledge, and with digital media we can attract, generate and share knowledge more effectively than ever before. Like every other university, the content we have on our corporate website is managed through a content management system - no surprise there.

Through its website, a university will promote its course catalogue, provide students with timetables, list academic vacancies and explain how the quantum mechanical and thermodynamic properties of nanostructures can be dramatically modified by careful atomic-level design, amongst other things. There’s no part of the University of Bath that doesn’t have a presence on our site and all the content is managed through the CMS. All of which makes the CMS integral and worth investing in to get right.

We can

True, it's unusual for a university to build its own CMS. Conventionally, the development of a CMS would be outsourced to an agency or an off-the-shelf product would be licensed and then customised by the in-house team. These approaches are normal and can work.

At the University of Bath we had another option - to build a CMS, by ourselves, from the ground up. This is possible because we have a decent-sized central team of 16, made up of designers, developers and editors. We have the management, production and technical skills in our team (built up through hiring and training) to develop and maintain our own products - like a CMS - that are built precisely to the specifications of our users.

Having considered the options, we selected the one that allows us to build this essential software at marginal cost, in exactly the way we choose, meeting our specific users' requirements, and to which we can add whenever and however we choose.

This option still allows us to bring in external support in the future if needed. We may in time - if our software turns out to be any good - share it in part or in its entirety with other institutions for their reuse and improvement.

It's rewarding

I work with a team of people who are motivated by making useful digital products and services by their own hand and creativity. A desire to make things is a unifying thread running through our team. Being makers (as well as consumers) of digital products and services allows us to be innovative and add value in ways that are entirely in-keeping with our University’s strategy to be a centre of world-class research and teaching excellence.

As Bath makes its own publishing platform (of which the CMS is one part), we are learning through doing and sharing what we learn. In this context, the development of people is as exciting as the development of any technical or design feature of the platform.

It’s a big challenge, but it comes with the promise of a big reward and that is a uniting, motivating force for our collective. By developing our new publishing platform we get to put all our delivery principles into practice at once, test our every skill and do very exciting things everyday. That's something worth being part of.

Posted in: Beta, Team


  • (we won't publish this)

Write a response

  • Hi!

    Thanks for sharing the post - are you writing it *entirely* from scratch, or are you starting with a some kind of open source product, (WordPress, like this blog, or Wagtail, used by the Royal College of Art, etc) or framework (Django, Ruby on Rails, etc)?

    And what technology are you using for it?

  • I totally agree with your arguments as I did similar in local government (which ran for 10 years).

    Making your own CMS may start off by "here's the doc uploader" and "here's the WYSIWYG editor" but I found, it soon turned into "what meta-data can we inject/surface from this?" and "what application can we also derive from this?".

    Two other observations.

    My boss originally said to me "If we buy a CMS, we'll still need a programmer to customise it for us, that is even if it customisable, and we will have to pay a license. If it is not customisable, we will have to pay for the changes, and wait a long time. We may as well pay a programmer to make the CMS." Granted, this is the days before WP (for those who think WP is a CMS).

    A CMS is like a straight-jacket, you don't know how much it is going to constrain you 'till you put it on, and then its too late. (me)

    I left the same day as my boss took early retirement, and they bought a CMS, and their website simply stopped evolving.

    Stay nimble. More power to you.

    • Thanks for your response, Paul. The encouragement is much appreciated.

      I've bought, I've customised and I've built publishing platforms. Looking at the needs in front of us here at Bath, self-build looks like the best option in terms of keeping in control and in step with user needs as those evolve over time. It also leaves all other options on the table available to us should something change. It's that ability to tweak or pivot entirely which makes this feel right now and over the long term.

  • To me, the only reason to consider building a CMS from scratch is that you have gathered well-defined requirements from your users which you prove can not be implemented by extending one of the scores of mature, proven and free platforms there are available.

    There seems little reason to invest tuition fees in a product which does not aim to offer demonstrable advantages over openly available alternatives.

    The primary concern should be "Is this the route to provide the best service to students, to staff and to the University, in terms of quality, value and efficiency?"

    In my experience, the answer to such questions is very rarely "let's create a bespoke CMS from scratch". That path is well worn, and littered with casualties.

    • Thanks for sharing your view and experience, Alex. I agree with your stated primary concern and that is where we started when we considered the options, before then setting off down the route we have.

  • While it's good for universities to innovate and make in-house products, there could be serious challenges ahead with no 'rescue' options.

    A home-built CMS is great if you can spread tech and maintenance information, preserve that for future generations of developers and supporters. In my experience - and sadly that's many years in UK's HE, local govt etc - every 10 years or so, there is a hemorrhaging of web people, even in a place like Bath, where jobs outside the uni are as scarce as buses in the city after 21:00.

    Having said all that, if you make a successful product, then you have a captive market within HE; a spinoff company will smoothen any 'commercial challenges' along the way. Most universities I know of are hopeless at dealing with commercial successes. They are generally used to swallowing up money is vast quantities, not returning profits.

    You've also said that you have a "decent sized central team of 16." I read that immediately as "we are basically overstaffed." An average uni central web team is around 5. Yes, you have the luxury of an excellent level of human resources.


    • Thanks for sharing your views, Anil. As you say there are risks [to every option], which we have given due consideration to. I don't agree with the reading of our team size. I couldn't say what the size of an average uni team is but I feel that what we have in place is just about the right number and spread of skills to undertake the sort of product development we are involved in. I am blessed with a great team and I am thankful for the graft that each one of them puts in every day for the benefit of our university community.

      • Yes, I don't doubt your team's commitment and so on. But, it is a large team - and unusual by comparison with other universities. Heads of digital elsewhere would be hard put to find so many resources; inevitably, it's usually the dev side that gets farmed out. Nevertheless, if this turns out well, then you will be in a good place to make a real difference.


  • With hundreds of mature CMS solutions available on the market, building a home-grown solution is a very unusual route to take. Even more so for an organisation from outside the CMS industry (i.e. not a software vendor or a digital agency with lots of experience in software product development). Yes, CMS as a capability is central/essential to what universities need, but *developing* a CMS product is something else entirely, and it’s not what universities are known to be good at.

    What would be helpful to know for other organisations facing similar decisions, is how the home-grown solution will deliver value. What’s the business case behind the investment? What are the focal needs (high priority, idiosyncratic requirements) that drive the selection? Which platforms were shortlisted?

    Keeping the team motivated is a valid and important goal, but it’s not a technology problem.

    • Thank you, Marianne. As we go live in the coming weeks, the team and I will be talking further about our decisions, the proposed benefits, where these have or will be met, and how.

  • I've followed Baths digital journey with interest since attending IWMW2014.

    There are always doubters when people try to innovate.

    Personally I don't see the downsides as that much of a risk when weighed up against the potential benefits, coupled with Ross's views that he believes his team have the required skills to make it work. Also I'm sure the University gave it very careful consideration before embarking on this journey.

    Worst case scenario the CMS isn't fit for purpose and will be scrapped and Bath Uni buy an off the shelf solution.

    Big deal.

    Many Universities evaluate their CMS every 3 years or so anyway, for various reasons:
    - after realising the product they bought promised much but didn't deliver
    - the CMS supplier went bankrupt or where swallowed by a larger company (happened to us 6 months after buying)
    - the IT dept swings from one preferred technology to another
    - the platform is no longer developed

    Whatever the reason, Uni's look to replace their CMS regularly as their business needs change or their current system stagnates. In the HE sector you see it all the time.

    Even if the CMS fails, there are still positives to be taken:
    - experience gained for the entire team involved (UX, support, software dev, training etc)
    - innovative approach (how many uni's use this well worn phrase in their marketing/research blurb but don't actually deliver?)
    - it will attract staff to the digital team, after all - who wouldn't want to 'boldly go where no HE Digital Team has gone before?'

    However, what if its successful? 🙂

    I'm not naive to believe this is the right decision for everyone but I think its exciting and should be applauded.