At Crowd Favorite we get a lot of inquiries from people who are interested in building something with or on WordPress. These potential projects vary greatly in scope and concept – some are just a couple of days, some are 6 months or more. To make things more complicated, these potential clients often view WordPress in very different ways. The main difference is fundamental – do they see WordPress as a platform or as a product?

Some people view WordPress as a CMS platform to build on. They want us to help them create a website, service, etc. and they see WordPress as a platform that their idea can be built on. For these projects we will typically use some existing tools for various features but build customized solutions based on the feature set we work to define with the client. The final solution typically has a smooth and cohesive back-end administrative interface and is logically consistent throughout the feature set.

These projects are typically larger engagements and these clients are typically willing to make a larger investment in the development of their project in exchange for a more cohesive, consistent and robust result.

On the other side of the spectrum are people who come to us viewing WordPress (and the thousands of plugins that themes that are available for it) as a product. These folks typically are looking to create a website with a certain feature set and may already have in mind a collection of existing plugins that they think may be useful for creating these features. They expect the project to be more a matter of configuration than development.

These clients are typically primarily interested in keeping costs down and will trade elegance for expedience.

As you might imagine, these two very divergent approaches can lead to some significant challenges, especially when initially talking to potential clients.

The first thing we do is try to figure out which camp a project falls into. Once we know if it’s a platform or product project, everything gets quite a bit easier. This can be much more difficult than you might imagine. Our prospective clients typically see WordPress in only one way, while we can see it from many angles given our extensive experience. A number of clients will describe what sounds like a platform implementation, then all of a sudden they may tell us something that swerves onto the product path. The opposite can also be true. We always try to determine this as early in the process as possible, but we’ve also had rare cases where a project has switched tracks in the middle – I recommend doing all you can to avoid this.

Once we’ve established the type of project involved, we have to do a couple of things:

1. determine if the client’s desired approach will lead to a successful implementation based on their description of the end result
2. do a finger-in-the-air scope to budget check to make sure they are compatible
3. determine if we are comfortable building the project as the client desires (we think it could be a product implementation, but there’s a Twinge…)
4. if we get through all of the aforementioned, create a rough development outline for the purposes of creating an estimate

The first part here is the most important. It’s very important to us that we have a happy client at the end of a project. If we are hearing requirements that all lean towards a platform project but the client is voicing an opinion for a product implementation, that’s a concern. When everyone is on the same page, the chance of missing expectations is greatly reduced.

For example, if a client wants to do a product implementation but has specific functional requirements for various components and is unwilling to relax those requirements based on existing functionality (in WordPress, a plugin, etc.), then we should really be talking about a platform project instead of a product project.

There are also some significant differences in post-launch support and follow-up development with each approach. We will often engage in an ongoing support and maintenance relationship with clients whom we have developed larger platform sites for. These relationships generally run quite smoothly, with requests for additional features and functionality being built incrementally on top of the foundation we built in the initial implementation phase of the project.

Conversely, for the product projects we engage in, it is more typical that we build the site or service and hand it off to the client to run from there. When the client comes back in the future and wants changes made, the ease of implementation and resulting cost of new features can vary widely based on how these new features can be implemented on the wide variance of approaches utilized by the off-the-shelf plugins that provide many of the features for their site. It’s also not uncommon for upgrades to a 3rd party plugin to change certain functionality in such a way that it no longer works exactly as desired for the client’s purposes.

Another challenge with WordPress as a product engagements is managing expectations in regards to 3rd-party plugins and themes. In most cases we will try to budget time to code-review any plugin we include in one of our builds to make sure it is secure and will scale to client’s needs. This can result in us advising the client not to use the plugin or theme they had intended, or require additional time and cost investment in addressing shortcomings of the plugin or theme. There is also the issue of fixing functional bugs in these plugins.

People who view WordPress as a product will typically expect that any collection of plugins will work elegantly and seemlessly together. Rarely is this the case. Even between experienced WordPress developers you will find preferences for different implementation approaches. Mix in plugins written by developers that do not have extensive WordPress experience and you can end up trying to weld the transmission from a 57 Chevy to a tricycle.

The important thing for us from a project perspective is to be honest and consistent with our clients. They may not want to hear than plugin X and plugin Y aren’t going to be compatible, but it’s a lot better to tell them up front than to have to tell them late in the development cycle when you discover that you’ve run out of duct tape.

While you can probably tell from my descriptions here that we prefer to work with WordPress as a platform because we like building elegant solutions. However, we do engage in WordPress as a product projects as well and have built some sites and services we are quite proud of.

WordPress is both a platform and a product – it’s a wonderful and confusing world.

If you’re a WordPress developer or are interested in building something interesting with WordPress, taking a moment to figure out if you need/want to use WordPress as a platform or as a product may save you quite a few headaches.