WordPress is a strong way to publish pages an editor will change. Django is a strong way to hold records, permissions, and payments. The wrong choice is the one that fights the thing the site actually does.
If editors change the words every week
A marketing site, a news page, and a set of service descriptions want an editor, media, and a preview. WordPress does that without a developer in the loop, if you keep the plugin list short and someone owns updates. Adding a plugin for every idea is how the site becomes a system nobody can explain.
The moment the page must know who the visitor is, what they owe, and what they are allowed to see, you have left publishing. You can bolt that onto WordPress. You will then be maintaining someone else’s application framework inside a publishing tool. That can be right for a small member directory. It is a poor home for a ledger.
If the record is the product
Invoices, stock, bookings, applications, and case files want models, constraints, and tests. Django gives you those in the same place as the admin an operator can use on day one. The admin is not the product design, but it is a real back office while the polished screens are still being built.
A portal still needs pages a stranger can read: what you do, what it costs to start, how to ask. Those pages can live in the same Django site, edited by staff through a small set of fields, or on a separate marketing site that links to the portal. One canonical host either way, so you do not split the name.
The cost you will actually pay
WordPress costs less to launch when the work is pages, and it costs attention every time a plugin updates. Django costs more to shape the first records, and it costs less surprise when the rule is “this payment may be recorded once.” Pick from the rule that will hurt you, not from the demo that looks finished.
If you already have WordPress and the new work is a portal, put the portal beside it and link them. Migrating the articles into Django for purity does not help the customer. Rebuilding a ledger as WordPress posts does not help the bursar.
Pick from the rule that will hurt
WordPress is the right base when someone who is not a developer will change the words every week, and when you keep the plugin list short enough to explain. The moment the page must know who the visitor is, what they owe, and what they may see, you have left publishing. You can force that into WordPress. You will then maintain an application inside a publishing tool. That can be right for a small directory. It is a poor home for a ledger.
Django fits invoices, stock, bookings, and permissions, with tests and an admin operators can use while the polished screens are still being built. The admin is not the product design. It is a real back office. The public pages, what you do and how to start, can live in the same site or on a marketing site that links across. One host either way, so the name does not split.
The costs are different. WordPress is cheaper to launch for pages and costs attention at every plugin update. Django costs more to shape the first records and less surprise when a payment may be recorded only once. If both already exist, link them. Do not migrate articles into Django for purity, and do not rebuild a ledger as posts.
Write the choice down with the rule you used: editors own the words, or the record is the product. The next person who wants to add a plugin or a model can see why the base is what it is.
When you are choosing the base
- Use WordPress when editors own the words and the pages are public.
- Use Django when the product is records, permissions, and payments.
- Link the two rather than forcing one tool to be the other.