[L0j1k]

It's not dramatic if you appreciate not having panicked clients calling you at 2am because Turkish hackers have swapped out the main page or worse, RBN is distributing BlackHole from their site. I am not particularly keen on pretending I'm a hosting provider (even if it's extremely profitable), because I don't want phone calls at 2am about problems from something I built six months ago. I'm old enough that I know what I want and what I don't want in life, and I am not ashamed of this.

I'm a developer, not a babysitter, and while I can stand guaranteeing a product I build, I cannot and will not try to guarantee a product that stands a very good chance of being hosed by some retarded exploit (relative to a custom product). Since I'm not in the babysitting business, "better" for my clients is a product that won't be the Turkish graffiti or BlackHole distribution engine in six months' time.

It also needs to be said that for some reason lately, clients have consulted developers who have put it into their heads that using WP automagically brings your price and development time down by half, regardless of the circumstances. That's absurd, but it's usually the first real question I field about the technology we use to build products and services. If a client really wants to know the specific reasons why we don't use WP, you can bet that I don't have a problem explaining this exactly as I've explained it to you, albeit perhaps with different terminology. Simply put, I don't use WP because it is too risky versus the custom product we build, and that whole mess is something I don't want to clean (for free, which is what they'll demand when it happens). Even if I "maximize" some profit margin using it, I still feel that I'd be doing a disservice to my client. I'm totally honest with my clients, and if they insist I use WP, I insist they go somewhere else. And at the end of the day, if you aren't honest with your clients, you're a bad developer and a bad person.

That's my opinion, and I realize other people feel very differently, and that's fine.

[pknight]

Well, I think you are pointing out issues with clients in general. A well maintained and well managed WordPress site is going to be more secure than something custom built. Having said that, if said clients installs all kinds of stuff willy nilly, that is an extra burden I can see that (you could lock that ability down though). If you can fully satisfy a clients needs with something custom and do it cost effectively all the better.

That certain clients have unrealistic expectations because WP should be cutting dev time in half etc, that's an interesting point. I think client education factors in here.

You can be running another CMS or something custom and run into security exploits all the same though, if not more so. Something custom doesn't get the same amount of eyeballs from developers to ensure everything is secure. And even static sites can be hacked and abused if a hacker gains access to the server.

[L0j1k]

You make a good point here, and it's true that I shop around for "the right kind" of client. I read an article some years ago (on HN) about firing terrible clients at the same time we were having trouble with one client in particular. I resolved to never even negotiate with a client that I think is going to cause problems for myself or my team. We haven't looked back, and it's been one of the best decisions I've ever made for the company. When a potential client starts insisting on this magic time/money saving thing called WordPress even after I explain my concerns, I know that they're probably not a good fit and start recommending other developers in the area that we know that do quality work with WordPress. And there is absolutely no shortage of those kinds of developers, so the client will end up getting what they want.

On security, the custom code we have written and deploy for our customers is stuff that I trust, because it's something we built ourselves and are extremely familiar with. Our products also come with a built-in automated "security service" that helps tremendously in keeping us from being the lowest-hanging fruit. Importantly, not even using WordPress immediately shuts down the near-constant traffic on the internet devoted to finding insecure WP deployments. While I completely agree that a WordPress deployment in the right hands can be as secure as anything out there, I don't trust the codebase in general, and certainly not as much as I trust my own code, despite there being a large number of coders sifting through WP. And all bets are always off if an attacker gains entry into the hosting provider.

As a specific example, WordPress doesn't use PDO at all, instead using the mysql_ functions (not even mysqli_). This is a pretty glaring problem from my point of view. The excuse WP core developers have used is that it's basically too tightly-coupled to use anything but MySQL (and specifically the mysql_ functions). That's a pretty big red flag to me, when a developer says that their product is too tightly-coupled to stop using functions that have been officially deprecated in the language for quite a long time. In fact, the feature request for PDO in WP is a kind of in-joke to outsiders (http://core.trac.wordpress.org/ticket/21663).

Also (and importantly), I don't sell myself as a WordPress developer, but as a custom web and mobile applications developer. I have done this intentionally so that I won't succumb to the temptation to start rolling out quick and dirty WP deployments, but instead focusing on providing a custom-built, quality product that I can honestly say they can trust to function well and function securely for a long time to come.