Pitching WordPress as an Application Framework


“I'd like to know if you can help me build a web application.”

WordPress as an application framework

How many times have you heard the statement? Probably as much as I hear it. Someone's found a market opening they want to exploit. Somehow they got your name. And so they come calling. Or maybe it's your boss at work. But either way, the discussion begins about the development of a web application. And at that point, in the back of your head, you begin to wonder if WordPress could do the job. Maybe you already use it at work, or on your projects, or maybe you've only used it for personal fun. But however you get to this point, the question remains.

How do I pitch using WordPress as an Application Framework?

Assuming it's not just a web site but an application that someone is wanting, the first thing I do is check to see which of the following features apply.

  • Does the application assume people will log in?
  • Does the application require profiles?
  • Does the application  have rights for those users?
  • Does the application assign rights by groups?
  • Does the application allow people to change their passwords?
  • Does the application limit access by rights and roles?

Assuming the answer is yes to all of them, you're already on your way. Because regardless of what platform you choose, you're going to have to create these features. But if you use WordPress, these features are already there for you. People like to hear that because they're hearing the price of a project go down. So that's part one.

Part one of the pitch highlights what WordPress delivers out of the box.

From there, I begin digging deeper into the functionality. More often than not, the features of the new application revolve around data (or “objects”). So I begin asking about those data elements. I want to know several things.

  • How many different kinds of data objects are tracked?
  • How much data is collected for each kind of object?
  • Is there a particular look or engagement model per object?
  • How are these objects related?
  • Who creates, uses and disposes of these objects?

These questions help me determine two things. First I want to know if custom post types (CPTs) will deliver the functionality that I need. Second, I want to know how data-centric the solution is. The reason I dig into that so quickly is that I want to know if the application is mostly what I call a big filing cabinet (capture data, store it, let others look for it) or if it's more like conversations (rapid, ad hoc, non-persistent, and run in real time).

WordPress works great for the first kinds of applications. It's not always the best for the second kind.  I'm not saying you can't do it, but I wouldn't create a stock options trading desk solution in WordPress. Finding out how well the application maps to CPTs and the kind of transactional use that the system requires helps me make part two of my case (when appropriate).

Part two of the pitch highlights that WordPress is great for collecting, managing and displaying data.

Now if you're a WordPress fan already and notice I haven't hit the plugin argument yet, just hold on. I don't like to jump there too quickly because if I haven't made sure WordPress is a great fit, the plugin argument won't matter. We'll get to that, but in part four. Right now, we're going to talk about people. In general no one wants to feel like they're going to be stuck with you forever. It's about being held captive to your rates and availability.

So I like to mention how many people contribute to the core. How many people write add-ons (plugins for us in the know) to the core base of the software. I often jump over to freelancer or odesk and highlight just how many WordPress developers exist around the globe (at least 150,000). That helps people know they can always replace me, or whoever they're working with.

Part three of the pitch highlights how easy it is to get a second (and third) opinion, because everyone knows WordPress.

Now that we've highlighted how big the community is, I like to focus on the plugins. There's a lot of them. And they're nicely arranged (many of them) in a single directory (which isn't always the case in other languages/frameworks). They're rated and you can see how many times they've been downloaded and what support is like. It's a remarkable thing we all often take for granted. But it means developing a feature might be as fast as installing a plugin. Hard core developers just cringed but customers just shouted for joy. So pick who you listen to.

Part four of the pitch highlights how many plugins and additional features exist that could keep project costs down.

And as I wrap up my pitch I close with what always closes any good pitch – contrast. I highlight the difference between using and not using WordPress as an application framework. In my experience, in terms of time and cost, using WordPress can cut the cost down by anywhere from 10-50%. That's a huge savings. I've also worked on projects where it's been even larger, in terms of saving but those may have been outliers. My point, as I close, is that someone should have a really good reason not to use WordPress if you're looking at an increase in time and cost.

Part five of the pitch highlights the contrast between using and not using WordPress as an application framework.

So now you know how I pitch WordPress as an application framework. You know my approach, my set up, and my case. If you're in the same spot, feel free to use it. And if you have success, not just in pitching but in building an application on top of WordPress, come back and tell me about it. I want to hear your success stories.