90% there. The site is always 90% there.
It happens to all kinds of software projects. A well-meaning developer gets the bulk of the site done, and then comes the final 10%. The detail work. The edge cases. The home stretch.
And many developers quit before they reach the finish line.
That’s when I hear about 90%. “Andy, this site is 90% done, but the developer disappeared. Can you finish up the last 10%?”
Don’t get me wrong – I don’t look forward to the last 10%, either. But it’s work, and I do my best to optimistically turn it into a “challenge” to be conquered.
Sometimes, I succeed – we use the existing code to finish the project.
Sometimes, I fail – it’s impossible to make the code do what they’re asking. We have the painful conversation that we need to start over.
This Happens a Lot With WordPress
I was once contracted to help with a large WordPress eCommerce (won’t say which plugin) & BuddyPress integration. It was multisite. And it used Gravity Forms.
Each of the plugins individually did its job well. Integrating them was a nightmare.
For example, the client wanted each product to have a contact form that sent messages to the store owner (each a different multisite install) using a logged-in user’s BuddyPress profile information.
We managed to make it work, but it was a fragile net of dependencies, relying on modifications to the eCommerce plugin’s code. Updates to the eCommerce plugin were now impossible.
Then, a BuddyPress security update is announced. My heart = crushed. Who knows what will break?
Cheap Integrations Are An Illusion
The original developer meant well.
- The client wanted a private social network – BuddyPress does that!
- The client wanted microsites – Multisite does that!
- The client wanted eCommerce – Just install a plugin!
Leveraging the wonderful plugins available to WordPress developers meant 90% of the work was done, and he could keep costs low for the client. Until it all fell apart.
I have seen this happen a few times – each with different plugins but with the same outcome:
The project is hacked together, abandoned, and eventually thrown in the trash in favor of another solution.
It’s Bad For Everyone
It’s bad for the client. Obviously. They lose time, money and, in the best scenario, they’re left with a functioning but fragile piece of (effectively) custom software. They probably can’t update plugins even though WordPress is nagging them to, for fear of breaking the site.
It’s bad for developers. Yes, I can make money doing contracting work like this. But I’d rather be helping clients grow revenues; not salvaging projects that are likely to fail anyways. It’s depressing to spend hours on a project only to see it trashed in a few months.
It’s bad for WordPress. Botched integrations contribute to the myth that WordPress is only simple blogging software and should stay that way. Clients who are burned will *never* use WordPress again.
WordPress can do these types of sites well. It just might not involve bludgeoning together 2 or 3 big plugins.
How To Prevent 90% Projects
1. If a plugin doesn’t do 95% of what you need, consider skipping it.
That last 5% can take a long time – especially if you’ve never worked with a plugin, and especially especially when that plugin is an obscure commercial plugin without a helpful community to answer questions.
2. Don’t take on projects you couldn’t (in theory) code yourself.
You don’t have to be an expert programmer. But if you’re installing a plugin and crossing your fingers that it does what you want, you need to reconsider if you should be selling a “custom” solution to a client based on this plugin. When it comes to the final 10%, you need to be confident you can write the code to finish the job or you risk being helpless (and unpaid).
3. Sell big integrations like custom software.
Many WordPress projects end at hand off: Once the client has the site up and running, they do their own plugin installations & updates. For simple sites, this works relatively well and is an awesome perk of WordPress.
Contrast to a typical Ruby on Rails project: Clients are utterly incapable of updating Ruby Gems, fixing any breakage, or making changes.
Ruby on Rails projects are treated as custom software. When I sell custom software, I make it clear to the client that they will need ongoing support, and the costs of the software go well beyond the initial building phase. Expectations need to be set properly.
When you have a big, hairy WordPress site – something closer to custom software than “out of the box” WordPress – make sure to set the right expectations with your client, making sure they have the budget to support the initial investment they’re making.
What’s Your Experience?
I live in the small business/single-owner site segment of WordPress consulting. I’ve never seen a large integration of multiple plugins be successful, but I’m sure they exist. I imagine for larger clients (with larger budgets) these projects can work quite well.
Am I crazy? Am I the only one seeing this problem over and over? Have you been successful in doing these kinds of projects? Let me know in the comments!
Mario Peshev
13 Mar 2015One of the reasons I began using WordPress for development was that I got tired of building the same components for 90% of the websites. News module, user management, commenting, CRUD admin panel were all the same. Each site has a few specific bits so the code wasn’t copy paste, but it was fairly trivial once you build it once.
Moving to WordPress several years ago allowed me to focus on the business solutions without wasting my time with what the CMS offered by default. But as the plugin repository grows, people tend to skip hiring freelancers and agencies and indeed try to build 90% of their solution themselves. Not only the other 10% could be impossible since the plugins may not play together nicely, but having built 90% of the solution for free (or a very low cost) makes people shocked when you tell them how long it may take.
I’ve shared my $15 WordPress gig story a while ago, and I decline 90% of the fixed-fee customization requests due to the slippery slope of WordPress customizations.
So nowadays lots of my clients hire us for maintenance or consulting for outdated websites, some of them run a massive combo such as WooCommerce + bbPress + BuddyPress + WPML + some plugins for custom post types and custom fields, integrating with various 3rd party APIs, Multisite network with Gravity Forms and what not. One of the last networks of that kind I used to work on hadn’t been touched for almost 3 years, so imagine what happened when I started fixing away.
To be completely honest, I love the consulting jobs of that kind, since they pay well, I solve actual problems and I also find edge cases in plugins and the WordPress Core that could be patched later. However, the majority of the clients are looking for a miracle at no cost.
Ian Wilson
13 Mar 2015Absolutely man, this is a big reason for why I had to leave that segment. Never looked back.
Ed
13 Mar 2015It happens a lot with me too. I’m in a similar niche for WordPress development and I’ve gotten my fair share of inquiries looking for someone to finish up the work their previous developer had done. Not surprisingly they’re usually 90% there.
When you ask what happened to the previous dev, you find that they either lost interest towards the end of the project or they got stuck on this “one small issue” that surprisingly is keeping the entire project from being launched.
I’m not sure what the original saying was, but I do agree, that to finally ship on something you end up spending 90% of your time on that last 10% of the project.
Ishan
13 Mar 2015Has happened with me. For my most recent project which ended up running for 2 years, client kept asking for features and plugins upon plugins were added. So we have a big hairball and no way to be sure about updates and maintenance.
Your advice about selling big projects as custom software is gold. Thanks for sharing!
Jason Witt
14 Mar 2015I read your example and I’m confused. What you described is a really simple to accomplish with a custom template for the products.
If you actually modified the e-commerce plugin. Then you either didn’t take advantage of the plugin’s hooks, or the plugin didn’t have the hooks. If that was the case then you shouldn’t have used that plugin at all. If you used a well built e-commerce plugin like WooCommerce it would have been easier to do without having to modify the plugin files.
If you expect all plugins to do 100% of what you want, then your in a world of hurt. No plugin will be able to offer solutions for every edge case. Creating custom code to modify existing plugins is just part of being a WordPress developer. Plugins don’t offer a catch all solution, but a really good starting point.
If you’re one of these “developers” that just install a commercial theme with a few plugins, then you’re not a developer. Developing solid solutions for clients will actually involve writing custom code. That’s what developers do. If the solution doesn’t exist, we make it. Expecting plugins from other developers to solve all your development needs is just lazy and all around bad practice.
Andy Adams
14 Mar 2015I disagree that a multi-store site with a social component is simple to accomplish. The eCommerce plugin did not have the hooks necessary for the customizations the client wanted, and *any* plugin will have limitations on extensibility. When you hit that limit, what do you do? Like you said, you’d better be ready to code 🙂
Ian P
14 Mar 2015Great post. This happens everywhere, but in WordPress land it happens a lot and is arguably one of the worst aspect about the platform.
David McCan
14 Mar 2015This happens in lots of markets. Housing contractors have a finish crew for just this reason. They go through the house after it is “done” and take care of everything that got missed.
To be honest, this is the reason why some people hire an agency, instead of a single contractor, for software development. A good agency will have server / network expertise, front-end developers, back-end developers, trainers, etc, and you don’t end up with a project that is 90% done.
You make a very important point about integration. It often is not simple, requires good knowledge of all parts being tied together and it warrants a premium to get it done right. Also, just because it is WordPress, or PHP, doesn’t mean that the design of the parts will be easy to integrate. At this point I go on high alert when I hear the words, “how hard would it be to …?”
Andy Adams
14 Mar 2015Very good points! Another alarm phrase is “it shouldn’t be too hard for you…”.
Jay Fidlow
14 Mar 2015Thanks for the article. It illuminates something that occurs pretty often in all sizes of businesses.
It’s actually a huge pet peeve of mine in web development. The idea that “There’s a module for that” usually contributes to the long tail of the project, or what you call the 10%.
I started off freelancing on my own and have worked up to large, multi-million dollar sites working with decent teams. However, that idea is still something that project managers and discovery teams haven’t given up on, despite being burned multiple times. Regardless of the platform (WordPress is a good example, but it extends to many open source platforms) there is NOT a module for that. What there is is a module that, at face value, accomplishes the general goal that the client or internal team described. However, unless you’re familiar with the source code of that module and understand how it interacts with other modules that are planned to be implemented, your best course of action is to assume the worst.
It’s essentially bad project planning to take the client’s requirements, install the modules you’ve identified and maybe throw some theming on top of that. You’re not “90%” there, you’re closer to 40% there.
One of the most important lessons I ever learned while freelancing was to take that into account and make it clear to the client up front.
Additionally, assuming that modules will tick things off of the project plan leads to “module bloat”. Module developers make certain assumptions when building them, and they’re not the same assumptions you have for your project. That’s especially true regarding performance and scalability concerns. I’ve inherited more than one bloated codebase and its almost comical the amount of bloat that is injected into sites to save 1 to 2 days work.
Thanks again for the article. It was a good read.
Ahmad Awais
16 Mar 2015Andy, Right on!
For the very similar reasons, I started to stop taking such projects and turns out, it’s better this way. I only entertain new projects and in most of the cases I take projects which are looking for custom work!
P.S. The more frontend complexity (in development) the more I love the challenge
Blinky
29 Jun 2015Nice article. Really informative and agree with it on 100%. Long time ago WordPress was just a bloggins platform, where you can share information and thoughts with the rest of the world. In the same time, most devs use to build ut their website on Joomla, Drupal and some other open source platforms, and of course there were a lot of custom stuff.
Now WP is one of the best CMS, where you can build not only website and blog, but also a community, ecommerce website and you can even think of something more advance. All that happened thanks to the huge WP community, which have extend the platform to new levels. Now a lot of websites use it, even the biggest ones. About 90% of my projects are based on WP, the other – on other platforms, which are in some cases better solution.
Will keep an eye on the comments here. Have a great day and keep sharing such a valuable information with us.