The Django vs WordPress series: Part 3 (Which one to use?)

So, you are ready to go ahead with your project. It is time to showcase your digital presence to the whole world. And you run into the eternal dilemma: Django or WordPress? Which one to use?

Hopefully, you have already read part 1 (“WordPress“) and part 2 (“Django“) of this series. They present a more detailed background on these two, arguably the most popular and successful technologies in the web development world today. This article will present a brief summary of how they compare in the real-world applications.

Truth Lies Within

Show me your project and I shall show you your future technology (read with Jedi tone). As noted in the previous parts of this series, each technology has its home ground. Another important distinction is that unlike WP, Django is not a CMS. It is a framework, which can be used to build CMS or other platforms. Therefore, your project is the main dictator of the technology of choice.

Consequently, the first step in answering the million-dollar question is to define the scope of your project together with its limitations.

Scoping your project

Let’s look at your project in two dimensions: the breadth and the depth.

The depth of your project is the level of required customisation. Usually, the more customisation a project needs, the more bespoke code the developer needs to punch out. That said, projects could be customised in various ways. For example, the project may require integration with a big number of third-party applications. These ready-to-use technologies may come together in a unique way to present a highly-custom product. To summarise, the more fine-grain and fiddly bits your project has, the ‘deeper’ it is.

The breadth of your project is the level of scalability. This goes up by the increase in the number of concurrent users, the intensity of usage, inbound/outbound traffic flow, the geographic spread of the access to the system, etc.

As a rule of thumb, as deeper and broader your application is, the further away you are from the WordPress domain. It goes without saying that each project should be considered separately and there are always exceptions to the rule.

WP Django Chart

It is important to know where your project stands in the breadth-depth plane. But you should also know your limitations well.


Main limitations for web development projects come from time or budget restrictions. But there could be other, more implicit, but crucial limitations. For example, you may have a favourable account with a certain payment provider. This will limit your project to that payment provider only, and the technology that you choose should be compatible with that provider. As another example, certain industries require storing digital information within the local jurisdiction. In other words, your server may be required to be located in Australia to comply with the laws. In this case, you should find out if the Australian server of your choice is biased towards one technology, or the other.

Now, you know what WordPress is, what Django is and what your project scope is. In most cases, this will leave you in the blended area between WordPress and Django and you will need to pick your shade. However, being equipped with the knowledge provided in this series, you are already intuitively inclining one way or the other. In the worst case, you can always reach out to us for a helping hand.

Let’s wrap up the series with an example project and a complex judgement in the WordPress vs. Django battle.

An example project

This example project will be one of the common cases we face in the industry. The details of the application may be different from yours, but consider the situation and goals in the following scenario. Let’s assume that we need to build a messaging platform that will integrate with an existing public file management system. Think of a Dropbox that lets you chat on the side about the files you just dropped. Our scoping tells us the following:

The Scope

  • Depth: A modern messaging platform carries a serious baggage of front-end magic. From “Joe is typing…” to new message notifications, there is a lot of complex technology involved on the messaging interfaces. Our app should fall no short of the trends. Also, consider peculiarities of integration with the existing file management system. This indicates an average-to-high depth of the project.
  • Breadth: As a Vertical SaaS product, the user base of our messenger will be dictated by the file management system. Therefore, we should be ready to scale at any moment. There may be a high number of concurrent users from a variety of locations. Thus, it will be fair to determine an average breadth.
  • Limitations: We are a start-up, which means a limited initial budget. There are no time constraints. The only other limitation is compatibility with the API of the file management system.

As you can see, the scope leaves us somewhere midway in the spectrum, perhaps slightly leaning us towards Django. There are no technological limitations to discourage us from Django. Moreover, Django REST framework will give us the needed flexibility to implement the elaborate user interface. Therefore, we would ideally prefer Django. However, the budget is limited and there are no internal resources to bring a Django project to life. What does Coderoo suggest in this scenario?

The Technology

We believe that your budget should not keep you from achieving your ideal tech product. We recommend a stepped approach to building it.

  1. Minimum Viable Product: Build the proof-of-concept prototype using WordPress as early as you can. This will help with a number of things. First, you will have a working prototype. This is crucial in the early start-up phase to motivate the team. It also helps to grab the attention of potential investors. Second, it helps with early-stage branding. And lastly, it can be used as a marketing and data-collection tool.
  2. Funding: Prepare a funding strategy. Funding can be secured from institutional investors, friends and family, crowdfunding, etc. Having a prototype product will be of an enormous help with this.
  3. Ideal product: Now that the only hurdle between us and the ideal product is resolved, we can proceed to build the Django application and conquering the world!

WordPress and Django are highly incompatible between themselves. However, a carefully structured project can make a use of the best of both worlds. It is not ideal to build-and-rebuild the product on each phase. However, if used wisely, it may make the difference between success and failure.

About the “Django or WordPress” series

The ever-growing field of web development has produced a countless number of frameworks and content management systems (“CMS”) over the years. Most of them did not stand the test of time. Django and WordPress are two technologies that did. Moreover, they keep growing in popularity and supporting more websites than ever. In Coderoo, we offer web development using both Django and WordPress and many of our customers ask – which one is better? This series will try to answer this question in a nutshell.

Whether you want to build a website on WordPress or on Django, we hope that this series will be helpful for you.

Also in this series:

Leave a Reply