Clutch spoke with Brian Dainis, the CEO of Curotec, about the comparison between popular content management systems - Wordpress, Drupal and Squarespace. Learn more about Curotec on their Clutch profile or at curotec.com.
Introduce your business and your role.
Curotec is a custom web and app development company. We specialize in improving customer engagement for our clients by developing high-end customer portals. We also help businesses streamline their workflows and processes by developing systems that integrate with their various business software components and with the human business processes. There is a whole host of ancillary services that we offer, but those are the two core pillars. I am the CEO of the company. We have under 20 employees, so I still have a pretty hands-on role in some of our projects. I’m involved in the sale process, the financials, and various marketing activities.
What should people consider when choosing a CMS or a website platform?
There are quite a few things to consider. I would start by considering the actual CMS and the development community behind it, making sure there’s longevity there and the CMS is well-built. If you’re dealing with any of the major ones, that’s less of an issue. If you’re trying to find a smaller CMS, some development companies will build their own CMS in-house. If it’s done well, it can be a good idea and a competitive advantage for the development company. However, I’ve seen a lot of cases where clients have some CMS that’s just a one-off, built by a small company. The company can either go away, or discontinue support and development of the CMS, and then the client doesn’t have anyone who can support the CMS well for them. Choosing a well-known, well-documented, and well-supported CMS is the first thing to consider.
The next thing to consider is how you plan to use it. Who’s going to be using it? What are their skill levels? What type of information will you be managing? What will it integrate with? Those are all important things to consider and should be weighed into the decision. Generally, the first thing to really look at is the type of information you’ll be managing. There are various CMS’s that have different focuses. For instance, if you’re building an e-commerce site, Magento typically is more suited for that versus something like WordPress. There are plugins and extensions for WordPress that support e-commerce, but Magento is specifically designed for e-commerce.
If you’re building a simple information website or a blog, then generally WordPress is the way to go over Magento. WordPress is designed for managing information pages. If you’re looking for something more dynamic, with a lot of customizability on the backend, maybe Drupal’s a better fit. So, really looking at who’s using it, how they’re using it, what type of information you have.
Can you speak about what differentiates WordPress, Drupal, and Squarespace from each other?
WordPress and Drupal are more similar than Squarespace, as they’re both built on the PHP language, and they’re both open-source. You host them yourself. You go onto their community website, download the code, and then you build on top of the existing code directly. They do have admin panels you can log into and use from an administrator standpoint, but you’re actually writing code directly on top of their lower-level framework. You can touch and see the code. There’s an open-source community behind those, people who are volunteering their time to support the development of these platforms.
Squarespace is a private company that has built their own CMS, and they maintain their own code. Either way, you can’t look under the hood. They do give you the ability to upload some basic CSS and override some of the HTML a little bit. I think even on the HTML side, it is limited. They do let you override the CSS, but you can’t actually touch the code or see the code. It’s a platform that they host for you. You pay a monthly fee to use it. In some cases, it’s good. Some clients come to us and say, ‘We have a $2,000 budget, and we want to build a simple website. We already have our pages laid out.’ Sometimes we’ll just point them over to Squarespace because it’s more cost-effective. If someone in-house has a marketing background and is a little tech savvy, they can probably figure it out pretty quickly.
Whereas, some clients come to us with a more custom need. They want a WordPress site that integrates with their CRM system. Maybe they want to use it for sending out newsletters, so they want to integrate it with their newsletter platform. Maybe it’s a multi-lingual site in five or ten languages, and there’s a lot of customizability on the page templates and the types of fields they need to manage. Squarespace would have a lot of limitations. You’d be hitting roadblocks all the time with a client that has those needs if you tried to use Squarespace. With a WordPress site, we can custom develop that and have a lot of control over the functionality, the administration workflows, the data architecture, and the integration with external systems. In that case, WordPress would be a much better fit. It really comes down to the complexity, the budget, and which level you fall into as a company needing the service.
If you could describe an ideal client for WordPress or Drupal, what would that client’s needs be?
WordPress has really grown, and there are multiple ways you can use it. There are the wordpress.com and wordpress.org sites. The .com side is similar to Squarespace. It’s a hosted platform. You sign up through their service, and you can upload themes. It’s kind of a similar model. The .org side is the open-source framework side of WordPress. That’s where you actually download the code and build on top of it. WordPress is usually our go-to when we’re building websites because it’s got such a huge community and access to a lot of different modules that can be plugged in. Also, it’s fairly quick to build on top of WordPress. We’ve found that building on Drupal can take up to three times the number of man-hours.
WordPress does give you good flexibility over most things. The one case where Drupal might be a better fit is when you just have really custom requirements, where you need to write your own custom code. You let Drupal do its own thing, and then have other stuff you’re building on top of it. In those cases, Drupal can make more sense, but most of the time, we find WordPress fits the bill just fine. We can also build in some custom functionality. In general, the average business or marketing person, who doesn’t have a technical background, has a much easier time using and managing a site through WordPress than Drupal, just because of the way the admin is set up and the intuitiveness of the page builders.
Who would the ideal client be for Squarespace?
The ideal client for Squarespace is someone who just has a very simple website. If someone’s designing a custom site, and they say, ‘Here are the designs, and it needs to be pixel-perfect,’ then you’ll probably have to make compromises on Squarespace somewhere. You may be able to get pretty close if it’s just static information, but there’s going to be compromises somewhere. With WordPress, you can design something in Photoshop, and pretty much make it pixel-perfect, as long as you’re doing something that’s just an inherent limitation of the web.
So, Squarespace is ideal for clients who have very simple content management needs, don’t want to spend a lot of money, and just want something up and running quickly. WordPress is better when there’s more complexity, more requirements to have complete flexibility over the user interface, and even flexibility over the backend functionality. Drupal is the best when it’s even a step further than that, and you have very specific functional requirements on the backend. It gives you a little more flexibility on how things work back there.
Is there a particular feature on WordPress that has impressed you, and that potential users should know about?
The biggest feature on WordPress that is impressive, but can also be a detriment too, is how easily WordPress can be updated. You can go in and click a couple buttons, and then you’re on the latest version. It’s quick and easy to update, but you can also break the site pretty easily, especially if there are conflicts, the theme isn’t built properly, or you have a lot of plugins. Updates can cause problems sometimes. It’s a pretty cool feature that’s unique to WordPress in a lot of ways, but it can also break sites. We’ve seen that happen a lot. Clients go in and start clicking around, not knowing what they’re doing, and break something. Part of our process is to educate our clients on what to do and what not to do; however, they sometimes still do it anyway.
Another feature that has been impressive is that a lot of what they’ve done, and what they’ve stood by from the beginning, was not completely removing any functionality. They want everything to be backwards-compatible. So, if you were building a WordPress site five or ten years ago, and you try to plug that code into the latest version now, it would probably work. Maybe there would be some bugs, and maybe it would have some issues, but it would probably work. In a lot of cases, code written five or ten years ago would still work with the current version of WordPress.
A lot of other frameworks aren’t like that. Magento 1.x to Magento 2.x is drastically different. You can’t just copy the code over from one to the other and expect it to work. You have to rebuild everything. The same has been true for frameworks like Drupal and Joomla. When you flip between versions, a lot changes, even down to the database structure, how the tables are structured, and the overall scheme. Functions completely change. The names of functions and methods change. Old functions go away, and new functions come in. So, it’s almost a different framework between versions, and you can’t easily migrate your code. You have to refactor it all or completely rebuild from scratch. With WordPress, 70-80% of the time, that’s not true. It’s almost always backwards-compatible.
Could you talk a little bit about Drupal, things that are impressive and other features that can be improved?
I think the most impressive thing with Drupal is that, for an engineer, it’s a cool framework because it’s got a lot of complexities to it. It’s fun to get your head wrapped around it. It’s laid out in a very logical and linear way, from a programming standpoint. From an admin standpoint, when an inexperienced person goes in and tries to manage a Drupal site, they’re completely confused about where to go. It’s not very intuitive to an admin. For developers, once you get your head wrapped around it, it’s pretty intuitive. It makes sense. You can build a lot of functionality on Drupal, and it gives the developer a lot of control over the code. To engineers, it’s a good framework, but to end users, I’ve seen a lot of pain points with it, which is why we actually don’t use it. The end clients are the ones we’re building for, not the engineers. WordPress is a little less fun and a little less engineer-focused. It’s more end user focused. So, maybe we have a little less fun writing the code, but the end client has a better product that is easier to maintain.
Lastly, things that are impressive or can be improved for Squarespace?
We don’t do a lot with Squarespace, just because it’s outside of our model. The projects on Squarespace are too small for what we do. We do recommend it. If a small opportunity comes to us, and we’re not interested in taking it on, we do recommend to the client that they check it out. A lot of times, it’s a good fit and saves them money. If we’re going to custom build a website, it’s going to cost $5,000-10,000 on WordPress or Drupal, but they can sign up for $20-30 a month on Squarespace and do it themselves. Maybe it takes them a week to put together, and it’s a big savings for them. We’re happy to shed that light for people who could potentially be a good fit for Squarespace. I guess the impressive thing how they’ve made a business out of it. I think it’s a pretty cool model. They weren’t the first to market, but I think they did it pretty well. They captured a lot of the market share for the small business, simple website market.
The limiting factor is that they have limited control of functionality, limited control of the HTML. You pretty much have to play inside their page builder and their admin panel. They give you the ability to override CSS and add in your own custom CSS, but beyond that, you have no control of what’s going on under the hood. You don’t even really know. You can’t see the code, you can’t see what’s going on, so you just have to click your way through stuff. If you’re trying to build a really custom site, a lot of times you’ll run into problems that you can’t overcome.
We have a client who’s on BigCommerce. If we were to start over, we would have used Magento. They came to us with this website already built, so we were inheriting it. At this point in the game, it doesn’t make sense for them to invest in building a new Magento site. It makes more sense for them to focus their budget on SEO and digital marketing, and for us to make do with what we have and make the best of it. That was our recommendation. We didn’t want to see them have to spend the investment to rebuild. So, we’re working with what we have, but the BigCommerce model, even down to the way the data is architected, doesn’t make perfect sense for their business model.
We’re finding that we have to continuously come up with weird workarounds, structuring things in a less-than-intuitive way, in order to get the site to work and function the way we want. From a frontend user perspective, we’re achieving the goals. From the administration standpoint, we’re kind of adding extra steps, process, and overhead that really wouldn’t need to be there if we were using a different framework, like Magento, that gives us more flexibility.
Magento is like WordPress, in the sense that you can go and download the code and work directly on top of it. BigCommerce is like Squarespace, in the sense that you’re paying for a SaaS product, you’re leasing space on their server, and you don’t get to see the code. You don’t get to see how it works under the hood, and you have limited control for functionality.
Can you give some insight into what companies should expect in terms of cost, when setting up a new website, maintaining it, and adding new features?
When you’re looking at frameworks like Squarespace and BigCommerce, hosted SaaS model website builders, you’re typically spending anywhere from $20 to $100 a month. It could be more, depending on your needs, but it’s usually not that much. If the client is doing the work in-house, and building the site in-house, then they’re just paying for their time and for that low monthly rate. If they’re another company to build it, generally companies bill all different hourly rates. A project’s price is usually based on an hourly rate. I’ve seen some companies that do a decent job go as low as $75 an hour in this space, and I’ve seen some of the more high-end agencies billing up to $250 an hour, sometimes more. We’re kind of right in the middle. We bill around $125 an hour, and that’s a pretty standard range. $100 to $200 is standard for the industry, and a lot of companies fall in that $125 to $150 range.
To build a custom WordPress site, typically we would charge $5,000 on the low end. On the high end, we’ve built custom WordPress sites with a lot of custom functionality, and they’ve gotten close $100,000. It depends on how complex they are, how much work is involved, how many integrations, and so on. I think our average WordPress project probably falls around the $15,00 to $25,000 range, and that’s pretty standard in the industry.
When you get into frameworks like Drupal, usually that’s more because there’s more time involved in building on Drupal. The cost can be $20,000- to $50,000, and sometimes more. It’s the same with Magento. We recently did a custom Magento build. There’s integration with Microsoft Dynamics, integration with a custom [unintelligible 24:38] layer, and the cost was over $100,000. It was a six to eight-month project with multiple people involved full-time. It was pretty complex. So, it can fluctuate, but those are ballpark numbers for most agencies in the space.
Could you give some insight on SEO and security when you’re working with these different CMS platforms?
It’s good you brought that up because we take both of those into account. There are a lot of agencies that just focus on design, user experience, and functionality, and don’t take those two things into account. We recently acquired a company and took over a handle of projects from them, and we found that security and SEO are things that were not being considered in the projects. For instance, before one of the projects launched, we found a bug where you could access the admin panel without logging in, just by going directly to the URL. There were problems with the way the URL’s were structured and the way title tags were structured. That’s all really important. Discussions around security and SEO are large rabbit holes you could go down and talk about all day long. They’re both constantly changing.
Even as recently as a couple weeks ago, Google rolled out a huge update that’s targeting PBN’s, or public blog networks. They’re starting to penalize websites that have a high volume of links from sources that are not getting a lot of traffic. When it first started, it was all about the keywords on your page, back in the early Google days. Then it became all about the backlinks that you have, and how relative the anchor text is. Then it became about how relevant and powerful the backlinks were. Now it’s becoming about how relevant the backlinks are, how powerful the sites are, and how much traffic they get. These are all factors being considered because people were just artificially creating sites that had power. They were going out to auctions and buying domains that were expiring and had some leftover power from whoever was using it before, then building fake websites and using them for backlinks. So, Google caught on to this, and now they’re looking for that specifically, and they’re getting pretty good at finding it. If you’re not getting links from sources that are actually driving traffic, that’s going to hurt you. All this stuff needs to be taken into consideration.
Even before you get to that point, you need to look at how the site is built and managed, and how you’re targeting keywords. Doing proper keyword research is a big thing. We use a lot of tools to identify what keywords competitors are going after. If you’re selling used cars, and you have a directory of used cars all over the United States, just going for the keyword ‘used cars’ is too competitive, and it’s unrealistic to obtain it. You have Auto Trader, and Cars.com, and all these other sites that have been up there for over a decade that are dominating it. It’s going to be really hard to catch up with them. Sometimes we’ll advise our clients, and our strategy will be to go after long-tail keywords. So, rather than ‘used cars’, maybe we’ll go after ‘2010 used Grand Cherokee’, or something like that. We’ll go after lots of long-tail keywords that get less traffic but are less competitive.
So, doing that keyword research upfront, and making sure that strategy is incorporated into the content strategy of the website, but also making sure that the URL’s are structured properly, making sure your site funnels links properly through the site. That comes down to your site and how well it’s siloed, making sure you have XML sitemaps that are generated dynamically. Schema.org markup is a huge thing that falls into the technical SEO realm and making sure that you have dynamically generated Schema code that tells Google what data is on your page. Each page should have unique schema code. Good title tags on each page, proper length, and making sure they’re in line with your long-tail keyword strategy, making sure you don’t have spider traps on your website. I’ve seen a lot of e-commerce sites that have slide-bar filters, where you go to a category page, and you can say, ‘I want to filter by color, by size, by price.’ When you click those filters, it can add parameters into the URL, and that can turn into a spider trap.
Let’s say you have a couple thousand products on your website, and you may have five or six different attributes that you can filter on. When you do the math, that turns into millions of combinations of pages. Google is just crawling all these pages, and they’re finding basically the same thing on every page. It’s just a list of products. So, you can get into these huge spider traps, where Google tries to index your site, and eventually, they just stop trying because they hit seemingly infinite numbers of URLs. Just being able to identify those types of things properly is really critical, and a lot of agencies don’t do it. They focus on user experience and functionality, but they forget about the SEO and security, which are very important things. If you don’t really vet those properly, then you’ll get caught with your pants down. Your competitors will come and dominate you in the searches, or your site will get hacked. All kinds of negative implications follow not taking those things into account.
Are there any additional aspects of building a website, or dealing with a CMS, that you’d like to mention?
I talked about security and SEO a lot. I’ve seen a lot of agencies focus on functionality and user experience, and not so much on the SEO and the security. Actually, all of those things are really important. Just focusing on security and SEO, but not focusing on user experience, would also be a mistake. So, I think taking everything into account holistically is very important. Analyzing your users, and traffic patterns, understanding how they use your site and where your traffic comes from. We have a lot of different tools, and a big one is called Inspectlet, it lets you see video playbacks of what people are doing on your website. It’s as if you were standing over their shoulder and watching them. You can see their mouse move, what they click, their entire journey through your website on a video playback. We analyze stuff like that. We look at Google Analytics. We set up conversion funnels. We do multivariate and A/B testing to really get to the actual user experience that converts the best. So, just understanding all that stuff, where your traffic comes from and how you can maximize it. There’s a whole lifecycle, a whole journey a customer takes. There’s a cycle they take, from the time they turn on their computer or their device, how they find you, whether it’s through social media or a direct campaign. Maybe they heard of you on a TV or radio ad, maybe they saw a billboard, or maybe they did a search on Google or another search engine. From the time that they think of your brand, to the time they see you in a potential list, to the time they get to your site, to the time they take the journey through your site and potentially convert or not convert, to how you even follow up with them after that, it’s all really important. Obviously the security and the search engine optimization, and the administration workflows, the disaster recovery, and the data modeling, and the integration with external services, and legacy integrations, these are all things that just keep stacking on top of the whole process. We didn’t talk about business analysis, which is critical upfront. Meeting with the company, interviewing clients if needed, really analyzing what the company has now, their pain points, their long-term goals. Do their pain points align with the long-term goals? Do their perceived solutions align with their current pain points? If so, great. If not, then let’s have that conversation. Just having those upfront planning sessions and strategy sessions, and making sure everyone is on the same page, and that we have a true, long-term roadmap laid out, and then installing that roadmap through, but also having the flexibility built in to adapt. When you learn new things, or when the business model changes, the industry changes, or the technology landscape changes, having that flexibility built in is also important. This could easily turn into an eight-hour call if we go through everything, but that’s at the high level of things you should be taking into account.
We ask that you rate each platform on a scale of 1 - 5, with 5 being the best score.
How would you rate these platforms for functionalities and available features?
From a developer’s perspective:
WordPress – 4
Drupal – 4.5
Squarespace – 2
From an admin perspective:
WordPress – 4.5
Drupal – 2
Squarespace – 4.5
Squarespace is pretty simple for an admin to use, and it has a lot of basic, intuitive functionality built into it, but developers tend to get frustrated because you can’t see the code, everything’s hidden behind a GUI. It’s not very good when you’re trying to build custom functionality.
WordPress is very intuitive for users, especially if it’s programmed properly and the developer did a good job setting everything up. It can be very easy and intuitive to use WordPress. From a development standpoint, it’s also pretty easy and intuitive to write code for it. Sometimes you find some ugly workarounds for stuff.
Drupal is a little more complex. It takes more time to build on. Developers like it a little better because you find yourself doing less ugly workarounds. The framework gives you more flexibility as a programmer. From an admin standpoint, I think it’s probably one of the worst CMS’s I’ve seen. It’s really hard to get your head wrapped around if you don’t know how the backend works. A lot of times for clients, you have to write up dozens of pages of notes on how to do things. They have to follow the notes every time they do it because it’s just so confusing for them. Whereas WordPress, you still write up the notes and give them the documentation, but they figure it out pretty quickly and intuitively. After a couple times, they don’t even need to reference their notes anymore.
How would you rate them ease of use and implementation?
From a developer’s perspective:
WordPress – Ease of implementation, a 5.
Drupal – Ease of implementation, 3.5, because you have to get your head wrapped around it and read up on the documentation before you get started.
Squarespace – For ease of implementation, 5. For ease of use, 1.5, because you really can’t do anything as a developer. You’re limited to the GUI.
From an admin perspective:
WordPress – Ease of implementation, 2, because if you don’t know what you’re doing, you could really make a mess of it.
Drupal – Ease of implementation, 0, because you really have to know what you’re doing on Drupal. Ease of use, 1.5, because it’s a little difficult to use.
Squarespace – For ease of implementation, 5. For ease of use, 4.5, because it is intuitive and well thought out.
How would you rate them for support, as in response of their team and the helpfulness of available online resources?
From a developer’s perspective:
WordPress – 5, because there is such a huge community. If you really need support, you can get in touch with someone at WordPress.
Drupal – 2.5, it does have a good community behind it with a lot of people willing to help and a lot of documentation.
Squarespace – 5
From an admin perspective:
WordPress – 4, because you can get support on the wordpress.com side. I don’t think they help you if you’re using the .org. There’s also a huge community and a lot of documentation.
Drupal – 0, because it’s all open-source, there’s nobody there to support you.
Squarespace – 5
How likely are you to recommend each platform to a friend or client?
WordPress – 5, it’s our go-to framework for website CMS’s.
Drupal – 1, because there are hardly any cases where we recommend Drupal.
Squarespace – I’m likely to recommend it to someone with a low budget and simple needs.
How would you rate your overall experience with each platform?
From a developer’s perspective:
WordPress – 5
Drupal – 4
Squarespace – 1
From an admin perspective:
WordPress – 5
Squarespace – 5