As far as software is concerned, I’m particularly fond of working on web applications and have spent the majority of my career focused on exactly that.

Specifically, I spent the first few years of my career working on enterprise applications in .NET. Like any programmer, I spent a lot of my free time tinkering with various languages, frameworks, and tools partly because it was fun and partly because I wanted to stay current on newer technologies.

It’s funny, though: The longer you work on web applications the more you recognize that all of them – at some basic level – come back to the same thing: getting data into the database and getting data out of the database.

Sure, there’s a lot going on between the two and there are tons things to consider but, at the end of the day, that’s what’s happening and everything else is details.

For example, the majority of web applications usually include user management, registration, authentication, session management, sanitization, validation, and so on – and on and on (this list can get really long and boring).

The point is that as applications grow, they become harder to maintain.

Of course, our computer science degrees and all of the people who go around touting the latest-and-greatest techniques for building web applications talk about all of the various ways we should be building our software in order to make sure we avoid this maintenance problem.

You’ve heard it before: it ranges from all sorts of various testing techniques to different design patterns mixed with any given framework and the latest client-side library.

Don’t get me wrong – all of that stuff is important to think about, it’s fun to discuss, and it’s absolutely worth incorporating into your work as much as possible, but practically speaking it’s a slippery slope – if you end up spending all of your time searching for these silver bullets to help create your weapon of choice, you may never get around to actually building stuff.

And that’s where frameworks come in handy. For any given language there are numerous frameworks that seek to help mitigate the problem of organization, maintenance, and the mundane tasks of web development. And that’s awesome. Seriously, I love that for any given tedious job, there’s likely a library that exists for it. That’s half of what software development is all about.

But the dark side of this is that you end up breeding these religious wars over what framework is better and why, then it devolves into what language is better and why, and suddenly we’re not only not building stuff, we’re not building stuff and we’re arguing over the fact that we have too many options with which to build stuff.

Weird, right?

If web applications all reduce to the same two things – that is, data in and data out – and we have so many options from which to choose, why not just try to sit at the intersection of what set of tools help solve your problem best* and pick set of tools that you or your team enjoy using the most?

Anyway, for years I spent the majority of my time in .NET and I spent a lot of my free time in Rails. Truth is, I like ’em both though. I also spent time messing around with a variety of other frameworks and languages. While doing all of this, I was also maintaining a small blog on top of WordPress (this was back during the 2.X version).

At some point, I began to do more customizations for my blog on WordPress, then I began to do small customizations for others, then I began building larger projects, and as I began to educate myself more on the platform, the Codex, and really began to enjoy working with it.

Here’s the thing: WordPress isn’t typically considered as an option for application development nor as a software development stack. But just like you spend long enough time working in web applications, spend long enough time in WordPress and you’ll begin to recognize many of the same things:

  • Database
  • Middleware
  • Presentation
  • User Management (Registration, Authentication, etc.)
  • Sanitization and Validation
  • Caching mechanisms
  • …and so on

Bottom line: WordPress is a completely viable option for application development.

At this point, I’m spending a large majority of my time building products for both my startup and for others using WordPress and I really enjoy it. This raises an interesting question: Why isn’t WordPress considered to be an option for building certain types of web applications?

No, I’m not advocating that the next social media website be built on WordPress – I’ve already said that it’s often about finding the right tool that helps solve your problem best* – but I am saying it’s totally worth considering for a certain type of web application.

So, the original question, why isn’t viewed as such?

I believe that it comes down to how WordPress is marketed and presented – as product. It’s not presented as a framework. Developers aren’t the target audience. There’s very little marketing lingo or landing page that calls attention to its API or its viability of building your typical CRUD-based web application.

Instead, it’s presented as a blogging platform, a content management system, or a way to easily build a website.

All of these other frameworks – be it Zend, Rails, Sinatra, .NET MVC, CakePHP, etc. – present themselves as a way to help you go about building software. WordPress presents itself as a way for you to blog about building software (or anything else, obviously).

But for developers who have spent significant amount of time working with WordPress, you understand that it’s just as much a development stack as some others that are available and that it’s subjected to the same development processes as any other framework, and building for it can often be just as frustrating and/or rewarding.

* This is an idea that probably deserves its own post and this isn’t that post.

This article is also provided in Spanish language thanks to Maria Ramos from