The True Cost Of LEGO WordPress Development

When I switched to WordPress over a decade ago, I was aiming at maximizing RAD (Rapid Application Development).

But not for the reason everyone assumes first.

Coding Can Last Forever

My background in engineering is enterprise-grade development. I spent a few years with Java (JavaServer Faces, Google Web Toolkit) and some dabbling into .NET.

Gathering a team of 20+ working on a project for 5 years is significantly different than bootstrapping a powerful application in two or three months.

Throughout my transition period, I switched between web and mobile Java development, Python (Django) for a UNICEF project, programming for set-top boxes before smart TVs were a thing, and PHP development with CodeIgniter, CakePHP, and custom frameworks.

I even tried to sell my own custom Java CMS, but this was pointless. I couldn't match the "time to market" with PHP's abilities, nor the server costs back in the day.

WordPress Can Be A RAD Framework

This is one of the reasons why WordPress currently powers nearly 33% of the Web.

A PHP-driven CMS promising backward compatibility, offering unlimited design opportunities, a streamlined editorial experience, and a powerful modular infrastructure was a key seller for businesses.

Ever since I remember, WordPress kept gaining 2% in market share year after year.

The motto of the web behemoth is "democratize publishing". In all fairness, it does provide a quick and easy install, adoption across every virtual hosting provider, and an opportunity for students, hobbyists bloggers and photographers, or beginners to practice publishing, along with basic power user activities.

The Dreadful DIY Mentality

And WordPress is best known for its endless pool of free (and really cheap) WordPress plugins.

With enough time and perseverance, enough bandwidth for browsing beginner tutorials, and a pile of plugins, a beginner can set up:

• An eCommerce website
• A network of small pet projects
• A forum
• The next-gen social network
• A portfolio site
• The clone of Forbes or Entrepreneur

Conveniently, this sparked a new wave of service providers with no technical background offering WordPress development services. Millions of self-taught power users go by job titles such as:

• WordPress developer
• WordPress expert
• WordPress specialist
• WordPress guru
• WordPress ninja
• WordPress rockstar

Note: The capital P is rarely found but hereby stated for accuracy.

Which led to years of "race to the bottom" and "professional" services priced as low as $50 apiece.

Once we have this cleared out, let's discuss what makes WordPress a powerful platform with a dangerous community of DIY power users.

The Dangers Of DIY Applications

I took the time to write a comparison between custom builds and DIY sites a few years back and this still stands today.

My team has established the so-called "3S" framework for approaching each and every new lead that comes in, which stands for Stability, Speed, and Security.

Or the three most common issues we're dealing with while onboarding a high-scale application built by DIY builders or less experienced agencies.

This is primarily caused due to the influx of free "Swiss Army Knife" plugins bundled at large in a web application, along with a powerful, badass premium WordPress theme -- usually, a multi-purpose one, serving 150 templates, 1300 theme options, and a myriad of sliders and page builders.

I get it, this makes the editing experience... easier. That is, once you go through a 120-page handbook disclosing the slider options and all components within Visual Composer, or another alternative heavy builder out there.

Once you start scaling, though, things look differently. More importantly, it gets extremely complicated dealing with proprietary 3rd party solutions (despite being open source).

And comparing quality to cost or time for execution is a constant battle.

Sample Study: Updating An Article Layout

Context: A new publisher serving 20M monthly views calls you and asks for a set of changes to their existing post layout.

1. You ask them for access to their git repository (which is non-existent).
2. Then you want to browse through their staging server. What a surprise, this ain't there, either.
3. SSH access? Lucky you, we offer SFTP, or even FTP maybe.

Once you take a deep breath and realize there is no changelog available, any documentation, or a sensible way to deploy with contingency plans in place (rollbacks), you offer an adequate hosting solution (varying from Digital Ocean through Elastic Beanstalk to a managed WordPress vendor that supports the core needs of an application plus support).

The estimate for the job is rejected, let alone the "risks of a migration". Let's assume that they have an SSL certificate at least.

You set up DeployBot (or any of the other bridges hooking SFTP via webhooks in your git repo) and jump to the second step.

Handling Maintenance In WordPress

As expected, the existing setup is cluttered. Aside from the multipurpose premium theme, you find 54 activated plugins: two sliders (God knows why), a page builder, an ad management solution with a gazillion checkboxes, a randomly activated "Related Posts" piece, and a couple dozen more.

A sensible approach forward would require a thorough code review and some profiling. This, however, costs money, which the client isn't used to paying for the past few years.

Your customer is eager to set up "infinite scroll" for their articles on specific categories. Once you double check the DevTools console and find the endless list of JavaScript errors caused by the builder and the slider plugins, you come up with an action plan for getting these fixed.

"No need to worry, just get it done, thank you."

Selecting an appropriate library for implementing infinite scroll is feasible, and you can make that work. Or even use Ajax Load More, a plugin with a set of extensions that works somewhat okay with WordPress (with a set of caching and feature limitations).

How To Perform The Update?

I know that you are not a risk-averse person by now. So let's play YOLO!

You pitch the idea of a headless WordPress build, just in case. This would make the layout development significantly easier and less dependent on the core platform. This doesn't fly, of course, so you're on your own.

While you're tackling the old build, you suddenly remember that WordPress launched its own page builder, Gutenberg, in its latest WordPress version 5.0. Since you are running an outdated version, you attempt to upgrade your local copy, and all hell breaks loose, even when installing the Classic Editor maintaining its core behavior.

Regardless, you're persistent enough to decouple the core logic of loading posts into a separate template, attaching it to a mapped list of categories or a set of checkboxes for easier control.

You run a couple tests on local posts and it looks fine. Due to the lack of a staging environment, the client is nagging you to push live ASAP, which you do, and "pray and hope" right after.

Exceptions, Warnings, And Errors

While the initial test looks fine, you receive an emergency email an hour later.

Some posts don't work at all!

Turns out that those JavaScript errors played their role, after all. The dynamic ad management solution embedded randomly broken videos across the board, completely annihilating the core post layout, crashing both the HTML of the page and its corresponding JavaScript for the infinite scroll logic. You revert (thanks to your own temp magic) and take another look.

Fast-forward a few endless all-nighters, you've patched the whole thing with a bucket full of sweat and tears next to you, asking for a properly planned code refactoring, cleanup, a partial rebuild, a hosting migration, and then some.

This is ridiculously expensive -- the site has been running just fine since, and changes can happen instantenously!

Moral Of The Story

WordPress isn't bad by itself.

But conveying value and the dangers of "technical debt" requires a Grant Cardone-type of sales skills to pull through, in addition to his own personal brand and credibility.

And great engineers aren't interested (and often lack the skills) in making this happen.

Until then:

• The lack of a staging app will make iterative development nearly impossible.
• Same goes for the non-existent SSH access, or even the ability to set a git repo on the server for automated deployments.
• The theme is apparently cluttered. Applying minor changes requires a complete refactoring and separation of the core logic into template parts or their corresponding includes.
• Installing a myriad of "Swiss Army Knife" plugins would do you no good -- for performance, stability, and security. Every single update risks a partial collapse of the platform.
• Controlling tons of logic through admin panels results in millions of possible permutations, making QA nearly impossible, let alone the stability factor.

Having worked with a dozen publishers serving tens or even hundreds of millions of page views, building a robust and scale platform on top of WordPress is possible.

Plenty of stuff has to be built from scratch. A lightweight, custom theme, with "separation of concerns" and "loose coupling" in mind.

Simple and carefully thought plugins following the UNIX model of tool development.

A coherent editorial experience that does the necessary.

Sufficient time for setting up new layouts or building features, with QA and management in mind.

And a process that engages all parties, including the product managers, our team, and all involved 3rd party vendors into a careful evaluation.

Everything else can help, but we should start with something.

But selling that to a mid-sized business who has been monkey-patching a platform after hundreds of crashes for years to come is challenging.

Let's hope for a better future.