Drupal is amazing software. I think when I consider all the different places I have worked crafting Drupal solutions, I have been really fortunate to not only learn a lot about Drupal but also about the business of Drupal software development.
Although I don’t speak for every Drupal dev out there, I think it’s safe to say that if you have been working with Drupal for more than a year that one thing will stand out about Drupal and that is how fast it is to develop custom code. The Drupal software ecosystem is designed to be fast to deploy, stable and easy. It’s not just a framework, it’s a vehicle. Drupal offers so much extensibility that a new feature can be added in just under an hour, and honestly if we handle the codebase using the recommended workflow, it becomes a customer satisfaction engine. The intention behind the software system is to make it easy to build out functionality. The intention is to be able to deliver value to the customer. Instead of writing boilerplate functionality, Drupal devs use Drupal’s baked in functionality and extend it, to deliver speedy and low cost easy to ship software solutions.
Lately, there has been much discussion throughout the Drupal community about the recent changes wrought by AI and the death of the Drupal Agency model. The crux of the matter is always cost, and AI is a great time and expense conservator. The Drupal community is stalwart, erudite and supportive, and I think sometimes too self-critical. We rack our brains over Drupal adoption rates, public perception and marketing. We all try, to some extent to give back, but not every agency or developer who is using Drupal cares about that.
Today I want to explore the cost of developing for Drupal using a standard Drupal workflow and Drupal practice, versus a non Drupal centric approach.
Meet Mickey Patch.
Mickey is a software development company owner, and their company works on Drupal sites. Mickey is a very clever mouse. He’s an IT Generalist, and he does not have the time or the inclination to delve deeply into Drupal, how it works or what it’s strengths or weaknesses are.
To Mickey, Drupal, WordPress, Laravel or any framework or system is just code. They don’t care about the value that these systems provide, or the cost savings that can be passed on to their customers. Mickey only cares about profit.
Meet Sharkey Shark. Sharkey is a Drupal dev and a product owner who knows how to leverage the entire Drupal software system. He’s trained not only on best development practices but on how to code applications using the very best and latest methods.
Let’s compare the cost of development between how Mickey Patch would approach Drupal vs. how Sharkey Shark runs it.
We will start with a familiar scenario. The customer has a legacy Drupal site that needs upgrades and new features. We will track three movements each for both parties. First, fix a bug, second, build a custom function, and third perform a security update.
- Bugfix.
The customer reports there is a problem with the site, when they submit a contact form, Drupal throws an error displayed on the page. Both Sharkey and Mickey can trace the issue to some code running in their site that is old, and not compatible with their recent environment upgrades. Both apply a fix using different methods.
Mickey, the IT Generalist, sees the error code generated from a problem with Drupal core. Not understanding how software dependencies are managed in Drupal, and being ever cost conscious, decides it’s easier to just fix the issue in Drupal core rather than address the problem in their custom code by writing new code. Patching Drupal core with a few “fixes” simply solves the issue of the error message without the added cost of refactoring the old module code. Sharkey knows that performing an upgrade of the custom code takes longer, but will preserve Drupal’s extensibility moving forward.
| Mickey Patch | Sharkey Shark |
| 1 hour to patch Drupal core – $100.00 | 3 hours – fix code and upgrade Drupal – $300.00 |
| Total – $100.00 | Total – $300.00 |
Mickey wins here. His method is cheaper and faster for this, and he believes that the future tech debt is pretty manageable – he simply needs to remember to apply his little patch every time he performs upgrades or improvements to his application, so he automates the patch. It becomes a part of the system permanently.
2. Custom functionality.
The customer wants to build some custom functionality with their form. They want some conditional fields and some custom logic in the submit handler to distribute form data into their Drupal application. Both Mickey and Sharkey choose to use a contributed module to provide some of the functionality the customer wants, but now things will become more complicated for Mickey, due to his patch. When the contributed module is installed in Mickeys site, it throws an error that breaks the site in some way. When it’s installed into Sharkey’s site which has been upgraded correctly, there is no issue. Mickey needs to do a bit more now to deliver the product to the customer, and of course he is going to charge for it.
| Mickey Patch | Sharkey Shark |
| 1 hour to patch Drupal core – $100.00 | 3 hours – fix code and upgrade Drupal – $300.00 |
| 4 hrs develop custom module $400.00 | 1 hr deploy contributed module – $100.00 |
| Total – $500.00 | Total – $400.00 |
3. Perform a security update.
The customer is aware of a recent exploit that might affect their site’s security, and request a security update. Mickey knows he will not be able to get Drupal to perform these security updates automatically, because they depend on Drupal core, and when he runs the updates using composer they create errors. He is going to have to patch again.
| Mickey Patch | Sharkey Shark |
| 1 hour to patch Drupal core – $100.00 | 3 hours – fix code and upgrade Drupal – $300.00 |
| 4 hrs develop custom module $400.00 | 1 hr deploy contributed module – $100.00 |
| 3 hrs develop and patch module code – $300.00 | 1hr deploy code security update – $100.00 |
| Total – $800.00 | Total – $500.00 |
To make this scenario more accessable let’s get realistic. Customer requests and requirements are usually multifold in nature, and frequently require a bunch of custom coding and adding several contributed modules and libraries. What would that look like as the demand scales up and a new feature is built out? Let’s also assume there is a new Drupal core security upgrade thrown in for good measure. Mickey now has to manage a lot more patches and his code is diverging from the product baseline steadily, creating more issues which will need fixed.
| Mickey Patch | Sharkey Shark |
| 1 hour to patch Drupal core – $100.00 | 3 hours – fix code and upgrade Drupal – $300.00 |
| 4 hrs develop custom module $400.00 | 1 hr deploy contributed module – $100.00 |
| 3 hrs develop and patch module code – $300.00 | 1hr deploy code security update – $100.00 |
| 4 hrs develop custom module $400.00 | 1 hr deploy contributed module – $100.00 |
| 4 hrs develop custom module $400.00 | 1 hr deploy contributed module – $100.00 |
| 3 hrs develop and patch module code – $300.00 | 4 hrs develop custom module $400.00 |
| 1 hour to patch Drupal core – $100.00 | 1 hour to upgrade Drupal core – $100.00 |
| 3 hrs develop and patch module code – $300.00 | |
| Total – $2300.00 | Total – $1200.00 |
Mickey Patch is laughing all the way to the bank.
Customers seldom understand code, application security or best practice as well as a professional developer. They judge how well a site works by looking at how things run when users interact with the code at the presentation layer. Mickey’s customer and Sharkey’s customer are both getting what they think they are paying for, but one customer is paying almost twice as much.
It’s no wonder that some people think that Drupal is expensive and problematic. Mickey’s approach will always produce bugs that need fixed. Every time Mickey touches the codebase from this point on it will cost an arm and a leg. Simple tasks will become complex. Building out features will always take longer, and the customer will always be responsible for the costs.
REAL Drupal developers have no use in making their own lives more difficult. We do not come to Drupal looking to work harder but rather to benefit from the Drupal communities work to make things… work.
Mickeys customer will always be grumpy because they are trapped in an endless cycle of buggy results and instabilities. Mickey does not have any way of comparing their development efficacy against a baseline because Mickey does not really care about Drupal. Mickey only knows one thing. How to write patches.
Sharkey Shark’s customer is very happy. Costs are low, so they have the budget to invest in lots of new features.
Mickey’s developers are miserable. Developing on a broken software installation is like taking two steps backwards for every step forward, and it’s not much fun, while Sharkey’s people are motivated, having fun and moving fast. Sharkey’s agency can take on MORE Drupal work because they have the bandwidth.
Mickey will have to hire additional developers to keep up with the volume that Sharkey is able to deliver, and that will further drive up costs passed on to the customer.
Sadly, I have seen leaders like Mickey Patch too often. Their methodology is like a cancer for Drupal because it makes Drupal look and function badly. All Mickey produces is technical debt, but that is factored into his cost analysis as well. Mickey knows that if he keeps the contract going, he is likely to keep making a lot of money, but if customer dissatisfaction causes him to lose the contract, he still gets away clean, because his customer can not quantify what work was performed and the hidden tech debt is passed on to the next company who has to deal with the big mess that Mickey created.
Once Mickey’s former customer gets the estimate for backing out of all of that patching, why wouldn’t they choose another software solution? To them, Drupal is now an expensive and costly experience, and does not really feel durable or convenient.
In my opinion, based on my experiences, this type of greedy mouse robs the entire Drupal project of its potential. Taking and cashing in, but never giving back, never admitting, never taking responsibility.
This, more than anything else, has been devistating to Drupal’s image and reputation.
Let’s reset this.
End of line.