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!
Freelancer? Me too!
I made lots of mistakes growing my business. Maybe I can help you avoid those mistakes?
Join my newsletter and I'll send you my best content about the business of freelancing and software, for free.