WordPress or a custom site: what actually decides it

WordPress is the better answer when the site's job is to publish and the people who publish are not developers. A custom build is the better answer when the site's job is a function — a calculated quotation, an order that reserves stock, a customer area — and the written pages are a by-product. The decision flips on two things a feature list never asks: who edits after launch, and whether the site must enforce a rule that is yours.

What is the site actually for?

Two jobs, not one. Publishing: pages describing what you sell, photographs, a few articles, a contact form, changing on a rhythm somebody sets. Functioning: the site takes something in — an order, a request, a booking — and answers with a number or a record.

WordPress was designed for the first job: a writing screen, a media library, a menu. A custom build starts from the second job and usually does the first badly, because somebody has to build the writing screen before anyone can fix a typo.

Who edits it after launch, and how often?

If the answer is "whoever is in the office, without calling anybody", WordPress answers the real question. A custom build then has to reproduce it: a new page, a replaced image, a corrected sentence, with no deployment. Skip that and the site is accurate on launch day and stale by quarter's end.

If the site changes only when a decision is made — a new service, a new price structure — the editing screen is not where the value is. What matters is that what gets published is correct, and a build you control can be simpler about that.

What does a custom build buy that WordPress does not?

One thing, and it is not the design: a rule that already exists in your business and has no ready-made add-on. A price computed from weight, wilaya and payment method. A quotation that needs two approvals before it leaves. A stock figure reserved at the moment the order is placed rather than when it is confirmed.

WordPress can host such a rule through an add-on somebody writes for you. So the honest comparison is not custom against WordPress, but a custom application with a site attached against WordPress with a custom add-on attached. Both work; they differ in who carries the upgrade risk when the core moves.

What does WordPress cost you in maintenance?

No licence, and that is the least interesting part. The cost is surface: core updates, theme updates, and one release schedule per add-on — a form, a cache layer, a page builder. Each is maintained by someone else, on their timetable, and each update is a chance that two of them stop agreeing.

That cost is staffing, not money. A custom build has the opposite profile: nothing updates itself, so nothing breaks unannounced; only whoever you contracted can change the site.

Why does the language question change the arithmetic?

Arabic and French are not a translation problem on either approach, but an editing problem and a layout problem.

On WordPress the multilingual layer is an add-on, and right-to-left quality is inherited from the theme: the menu, the forms, the tables. Some themes do it well and say so; others claim support, mirror the page, and leave the type and the fields wrong. A custom build designs the Arabic layout in: more at the start, less at every page added after.

Test both with a product name mixing Arabic and a Latin model number, an address form with wilaya and commune, and a table on a phone.

Which one can you hand to someone else?

Ask what happens when the builder disappears. On WordPress more people know the tool, and the content sits in a database you can export. On a custom build the code is yours only if the contract says so, and owning it means little unless another developer can read it: a repository and a documented deployment.

The comparison in one table

Dimension	WordPress	Custom build
Built for	Publishing on a rhythm you set	Holding one rule of your business
Who edits pages	Anyone you train, in a browser	Whoever you commissioned, or nobody
Adding a function	An add-on, on its own release schedule	Work on the code, quoted and scoped
Where it breaks	Add-ons that stop agreeing after an update	Bus factor, and drift from your process
Arabic and French	An add-on, plus whatever the theme got right	Designed in, paid for once
Leaving	Export the content, rebuild the presentation	The repository, if the contract granted it
What to verify on the vendor's page	The theme's right-to-left statement, and the add-on's limits	The contract: ownership, handover, where it will be hosted

In what order should you decide?

1. Write one paragraph on what the site must do that a printed page cannot.
2. Name who will publish, and how often, in the first year.
3. List the rules the site must enforce. If the list is empty, the argument is over.
4. Ask each proposal what happens in year two: who applies updates, who is called when a page breaks.
5. Ask to see the Arabic version first, on a phone, before the English one.
6. Compare the proposals on what is included, not on the total at the bottom.

Where this goes wrong

• WordPress chosen for a function. Three add-ons are commissioned to imitate an application, and none was built to talk to the others.
• A custom build chosen for a brochure. The invoice pays for an editing screen one person uses twice a year.
• The contract is silent on ownership and hosting, so "your site" means an account somebody else controls.
• Nobody owns the updates. The installation runs untouched for months, then one add-on takes the site down.
• Two proposals compared as if they were the same object. The gap in the total is the gap in scope.

When neither fits

When the site must publish on a rhythm and also enforce one rule, neither pure form is right. The usual answer is WordPress as the content core, a small add-on written for the rule, and both on hosting you control — an integration job, smaller than a rebuild and larger than a theme edit. It holds only if the add-on is written to survive core upgrades, a decision taken at the start rather than a repair made later.

What this does not cover

No prices appear here on purpose: a figure would be out of date within months, and what decides the project is the scope written down, the person implementing it, and the support terms. Nor does this judge specific themes or hosts, or take a position on migrating an existing site. It assumes one person can decide.

We build and integrate sites and systems: the content structure, the add-on that carries a rule nothing off the shelf expresses, the Arabic layout that has to hold on a phone. We resell none of these platforms and take no commission from any of them.