You are here

Website Builders

Interview with Lullabot on Drupal

Clutch spoke with Brian Skowron, the President of Lullabot, about Drupal - a popular, open-source CMS. Learn more about Lullabot on their Clutch profile or at


Introduce your business and what you do there.

Lullabot is a strategy, design and open-source development company which puts forth a lot of expertise in Drupal, as a CMS, and JavaScript technology. Our sweet spot is helping people translate their brands and content into beautiful, usable digital experiences. We tend to focus on organizations whose content is their product—multichannel publishers, media and entertainment companies, higher-education, and technology companies. We’ve been around since 2006, and have made our name in the Drupal community, writing some of the earliest Drupal books, and contributing a lot of the foundational code that is a part of Drupal today. I am the President of Lullabot and mostly focus on sales, business development, marketing, and client relations.


What is the main challenge a client will have when they come to you looking for a website?

There are many different challenges, and each organization is unique. In general, most of the challenges our clients will find themselves facing are how to effectively manage their content across multiple different platforms. Our clients tend to be companies which aren’t just putting out content via a website, but also through things like mobile apps, connected TV platforms like Samsung and Roku, and even emerging platforms like VR or connected Internet-of-Things devices. In general, the common thread with our client base is that they have lots and lots of content, multiple editors, and face challenges in terms of wrangling all of that into a compelling design and experience.

What factors should people think about when first choosing a platform for their website?

What the purpose of their site is going to be, and what needs the organization has from it on the backend. Many times, at least within the CMS landscape, people are drawn towards demoable features, whatever may be interesting and unique, but, what’s really important in choosing a platform, is how well it will match the needs of the organization, and the publishing needs of websites and various other channels. If it doesn’t effectively do that, it won’t matter if there are additional bells and whistles involved with the technology.

Questions which come out of that type of decision-making are “How big is my editorial team?”, “What kinds of technology expertise do I have?”, “What are my IT resources?”, “What are my design resources?”, “How extensible and customizable is the CMS going to be?” All of these things weigh in.


Could you provide an introduction to Drupal? What is it known for, and who might be an ideal client for it?

You may get different answers to this question, based on whom you talk to. Drupal is an open-source CMS, one of the two most widely-known ones, along with WordPress. Drupal’s strength from the outset has been its ability to be customized and extended. It’s a powerful platform, and it can do just about anything. It’s very feature-rich in terms of its ability to model content, in terms of editorial capabilities, and in terms of its abilities to accommodate customized workflows and permissions governance.

For some, the downside to this is that, with all of these capabilities, there’s a fair amount of complexity as well. Drupal has always had the reputation of having a steep learning curve. I personally feel that it’s a great choice for many industries, as well as different enterprises. In general, the best fits for Drupal tend to be those where there is a large content management need—maybe there’s a big editorial team, maybe there’s a big publishing frequency, or maybe there’s a need to push the envelope on what a website is doing.

More and more, as Drupal evolves, it’s becoming less accessible for someone who simply wants to create a blog. It does have a lot of capabilities, but its strengths are really the ability to be the central content management system which drives all the different publishing channels, with the web being just one of those.

Going back to the original question of who would be the ideal client for Drupal, it would be someone whose website is mission-critical, and someone for whom there are specific, custom publishing needs, with possibly the need to publish across different channels like websites, mobile apps, and connected devices.


Do you have any clients for whom you’ve built a website, but who continued to maintain it on their own? If someone was to choose to go that route, how much technical knowledge should they have?

We do have clients whom we’ve worked with on building a website, and who continued to run it in-house. Actually, the majority of our clients end up in that spot. We’re definitely not trying to force a vendor lock-in and have them stuck with us forever.

The good news is that many companies have made it a lot easier for in-house teams to maintain and own a Drupal site without having to staff-up a full development team. There are many tools available, as well as Drupal hosting platforms like Pantheon and Acquia, which facilitate much of the ongoing maintenance. Usually, when working with an enterprise client, we recommend that they do retain some sort of in-house Drupal expertise, which may equate to a single developer or more, depending on how advanced their environment is.

For the most part, if there is a well-architected Drupal site, which has been built well and is stable, we can maintain it with little ongoing in-house resources, and without relying on vendors. If the company is continuing to build on top of its site, or if it has a very complex environment, it may make sense to either maintain a relationship with a development company or retain its own in-house Drupal experts.


You mentioned a few examples of who would be a good Drupal client, but are there any organizations you wouldn’t recommend Drupal to?

As time has gone on, for organizations whose website is not really a core part of their business, and if the website tends to be a static asset, Drupal is probably not the best choice. It brings more complexity for something which isn’t really leveraged to its fullest extent. There are tools which service that market well—WordPress or even Squarespace and Wix types of offerings—and those tools are getting more and more advanced. For this type of “Listen, I have a website, but it’s not necessarily the mission-critical part of my business. I’m looking to set it and forget it.” type of client, Drupal is probably not the best choice.

If the site is a key part of the business, and you are routinely publishing content and are looking to continually add new design, functionality and feature sets to it, or if you have a larger team interacting with the site on the backend, pushing out content and making updates, then Drupal is a much better fit.


Generally, the community behind a CMS tends to be the driving force for the continued innovation and growth of the platform. Could you talk a bit about the Drupal community?

Drupal had a slogan for a long time, namely “Come for the code, stay for the community”. It existed because it’s known for having one of the friendliest, most accessible open-source communities out there. Many of our employees and clients actually started out as Drupal hobbyists which were asking questions in the forums and IRC channels back in the day. This community is very much instilled with the values of sharing openly, and I think that, as a byproduct of this, we’ve gotten an extremely rich resource of contributed modules for Drupal. People are volunteering their time and making contributions to the community all the time—our company and developers do this openly and willingly.

One of the things I like about the Drupal community is that it’s not just about maintaining the CMS itself, and the software which exists today but also thinking about where the future of the web is, and what CMS options will serve us for the next 10 or more years. I think that much of this comes with a vibrant, rich open-source community—not following a specific product roadmap, but rather continually asking the questions of what people need and what the future is going to be, and augmenting this with contributed code from people who are actually using Drupal. It’s a powerful model which creates a great CMS.


Is there anything you wish clients knew before going into a project?

By virtue of my role within the company, I wish people understood the complexities around content management, specifically with many of the new and emerging platforms out there. Many times, we see client teams underestimate things like migrations and rolling out a new design. This can lead to an inadequate and unrealistic timeline and budget expectations. We think that advances in technology would make things easier, but, in fact, the proliferation of different content channels, displays and display modes, has been driving a huge amount of complexity for CMSs in general, which means that the demands of digital projects related to content management are higher than they’ve ever been. I don’t know if we’ve reached the point where client teams really appreciate that complexity. We’re not living in a world of static HTML sites anymore; there are many moving parts.


What does it take to maintain a website and make sure it’s up-to-date?

Maintaining a site typically involves rolling out patches and maintenance updates. It’s generally not a matter of maintaining the site as it exists today, but more about keeping up with the changing demands of the business using it. Oftentimes, what we see is that something will be designed towards a specific editorial or publishing need at a given point in time, but the way in which articles are formatted or the editorial process for publishing them can change over time. Organizational and editorial team changes filter down to the CMS and require technology changes. Many times, this will be harder to plan for and see with maintaining a site. Similarly, as organizations change and evolve over time, the visual front-facing side will need to evolve accordingly. With our own website, we’ve realized that the format and ways in which we displayed case studies 5 years ago may not translate well to our current line of business.

Websites are a constantly changing thing, and they are less and less a matter of “build it once and maintain it”; we’re always iterating on them. An organization can plan for a big redesign or another effort and think that, once that’s done, they can just go into maintenance mode. The reality is that, once in maintenance mode, they find themselves continuing to want to do more things, and bump up against new needs for design and development for the existing CMS.


Could you talk a bit more about what some security best practices may be for Drupal, in order to make sure that all of the content and user information is safe?

One of the great things about Drupal is that, because it’s an open-source platform, there is a lot of attention to it coming from a whole security group which focuses solely on analyzing and responding to security-related issues with Drupal. Unlike working with proprietary vendor software, where the client is reliant on them to give notifications on and patch any vulnerabilities, Drupal has a team which is constantly working on this. Some of our team members at Lullabot are part of that security committee.

For the end-user of Drupal, the most important thing is to keep their environment up-to-date and patched. These security releases happen on a routine basis, and, like with any software, there is some responsibility on the user side to patch their system. Otherwise, there is a number of security best practices around securely hosting the site, as well as configuring Drupal such that it’s secure. This includes anything from the way in which certain fields and input formats are configured. There are too many security best practices to cover on a phone call, which is true for almost any other CMS or website.


Does Drupal have any drawbacks or limitations as a platform?

One of its drawbacks, as I’ve mentioned, is complexity. It has thousands of contributed modules, and it can be customized in infinite ways, but we have to know what we’re doing in order to get the most out of it. This ends up being seen as Drupal not being user-friendly, and it being complicated and difficult to maintain. The truth of it is that it requires a bit more expertise, and has a steeper learning curve.

Another thing which is often seen as a drawback is the editorial user experience. I know that people within Drupal have been focusing a lot of attention towards that, but, historically, people have tended to think that the editorial experience in it is non-intuitive at times, and not as user-friendly as it could be. Oftentimes, we end up working with our clients to customize the editorial screens in Drupal and make them more user-friendly. This could be and will continue to get better over time.


We have 5 additional questions. For each of these, we ask that you rate Drupal on a scale of 1 to 5, with 5 being the best score.

How would you rate Drupal for its functionality and available features?



How would you rate Drupal for ease of use and ease of implementation?



How would you rate Drupal for support, as in the response of their team, and the helpfulness of available resources online?



How likely are you to recommend Drupal to a friend or colleague?



How would you rate Drupal for overall satisfaction with the platform?


Expert quote
"Drupal is an open-source CMS, one of the two most widely-known ones, along with WordPress. Drupal’s strength from the outset has been its ability to be customized and extended. It’s a powerful platform, and it can do just about anything. It’s very feature-rich in terms of its ability to model content, in terms of editorial capabilities, and in terms of its abilities to accommodate customized workflows and permissions governance. For some, the downside to this is that, with all of these capabilities, there’s a fair amount of complexity as well. Drupal has always had the reputation of having a steep learning curve. I personally feel that it’s a great choice for many industries, as well as different enterprises."