Most WordPress sites are fine on launch day. The decision you are really making is about year two: who applies the updates, what happens when a plugin is abandoned, and whether the markup will still let you pass Core Web Vitals. Here is the honest version, including the cases where WordPress is the right answer and you should not hire us.
Why WordPress still runs so much of the web
WordPress earned its position, and pretending otherwise would be dishonest. It solved content management before most of its competitors existed, and the ecosystem compounded from there. If you need a membership area, an events calendar, a multilingual layer, a booking flow or a product catalogue, a mature plugin already exists, has been maintained for years, and has been broken and fixed in public by other sites before yours. That is real engineering value a custom build does not inherit on day one.
The operational advantages are just as real. Hosting is available everywhere: shared plans sit at the very bottom of the market, while managed WordPress platforms cost considerably more and price by traffic, by the number of sites and by whether staging is included. Check the current tiers yourself, because they change often enough that any figure printed here would be stale within a year. You can hire someone who knows WordPress in almost any city and any time zone. Your content lives in a MySQL database and an uploads folder, so leaving is technically possible even when it is tedious. Editors get revisions, scheduled publishing and role-based permissions without anyone having to build them.
For a content-driven site with a handful of templates and a team that already knows the tool, that combination is genuinely hard to beat. Nothing below is an argument against WordPress as software. It is an argument about what happens to one specific WordPress installation after two or three years of unplanned growth.
What actually degrades, and why it takes about two years
Failure is rarely dramatic; it accumulates. Every plugin is a third-party dependency with its own release cadence, its own opinion about where to hook into the page, and its own front-end payload loading on routes it has no business touching. A contact form plugin loading its stylesheet and its jQuery handlers on your product pages is normal WordPress behaviour, not a misconfiguration you can fix. Twenty plugins later, your Interaction to Next Paint is dominated by event listeners nobody remembers registering.
The theme layer is the second constraint. When you need to fix heading order for accessibility, remove a render-blocking stylesheet, or stop a lazy-loading plugin from deferring the hero image and wrecking LCP, you are editing someone else's template hierarchy through a child theme and hoping the next update does not overwrite the hook you depend on. Page builders make it worse: deeply nested wrappers and inline styles that no amount of critical CSS work can flatten.
Then the database. Autoloaded rows in wp_options grow quietly, expired transients pile up, post revisions multiply, and TTFB drifts upward on exactly the pages a full-page cache cannot serve: cart, checkout, account, search, anything with a logged-in session. Add a PHP version bump that a plugin was never tested against, and a routine security update becomes an outage. None of this shows up in a launch-day Lighthouse score.
Next.js against WordPress, and the headless middle ground
The architectural difference is the rendering model. WordPress builds the page in PHP on every request, then works very hard to avoid doing that again, through object caching, full-page caching and a CDN in front. Next.js inverts it: pages are prerendered at build time or on demand, served as static HTML from the edge, and revalidated in the background when the content changes. For an anonymous visitor reading an article on a well-tuned WordPress site behind Cloudflare, the gap is smaller than most agencies admit.
The gap widens in two places. First, the routes that cannot be cached: personalised pages, carts, dashboards, faceted search, anything tied to a session. Second, the payload, because a framework lets you decide what JavaScript ships on each route instead of inheriting whatever the theme and its plugins load globally.
Headless WordPress is a legitimate compromise: keep wp-admin as the editing interface, read content through the REST API or WPGraphQL, render the front end in Next.js. It buys you the editor your team already knows. It also costs you things people forget: live preview has to be rebuilt, every plugin that worked by injecting markup into the front end stops working (your SEO plugin's fields now need mapping by hand), publishing needs a webhook to trigger revalidation, and you maintain two systems instead of one. Alternatives worth costing out include Sanity, Payload, Supabase or Git-backed markdown in the repository.
The maintenance line most comparisons leave out
Build cost is the number everyone compares. Custody cost is the number that decides the outcome. Over five years, someone has to apply core, theme and plugin updates on a schedule, on a staging environment that actually mirrors production, with a backup that has been restored at least once so you know it works. That person is either on your payroll, on a retainer, or nobody, and the third option is the expensive one.
The recurring items are easy to forget when you compare one build to another. Premium plugin licences are typically annual and per site, and when one lapses you usually stop receiving updates, security updates included. Plugins get sold, change their monetisation, or are abandoned with a polite note in the changelog. PHP versions reach end of life on a schedule that ignores your roadmap. And an hour of downtime on a site that takes orders costs more than the whole maintenance argument.
We do not publish prices, so here is what actually moves an estimate instead: the number of genuinely distinct templates rather than pages, whether content is migrated programmatically or rewritten by hand, how many external systems have to be integrated, whether editors need a CMS at all or the content is stable for a year, and how much of the legacy URL structure has to survive with redirects. Pricing is on request, per project, in writing.
When WordPress is the right answer, and when you should not hire us
Stay on WordPress if you publish constantly with several non-technical authors, if your team already knows the admin and works in it every week, or if a mature plugin covers a requirement that would take months to rebuild: a specific booking system, an LMS, a membership tier structure, a country-specific accounting or invoicing connector. Stay if the budget is genuinely tight, because a careful build on a good commercial theme, properly maintained, beats a half-finished custom site every time. Stay if the site simply has to exist and be correct, rather than be a competitive asset.
Do not hire us if you want a weekly call or a standing check-in. We work in writing only, and if that removes something you need, we are the wrong shop and you will resent it by month two. Do not hire us if you need someone physically present, an out-of-hours phone line, or a 24/7 rotation. Do not hire us if your team must restructure page layouts visually, themselves, several times a month: a component-based front end deliberately trades that freedom for control. Do not hire us if decisions in your organisation only happen out loud: our process assumes someone can write a brief and approve it in writing. And if you already have a competent in-house developer, hire them a second one before you hire an agency.
Saying this early is cheaper for both sides than discovering it after a deposit.
Two people, one office in Dijon, and why we work in writing
We are Robin Monteiro (full-stack development, Next.js and React) and Florian Loppion (digital marketing), at 9 rue Jean-Jacques Rousseau, 21000 Dijon, France. That is the whole company and the only office. There is no account manager layer, so you talk directly to the person writing the code, and we take on fewer projects at once than a larger agency would. Both of those are true, and you should weigh them together.
Everything happens by email, in writing, with a reply within 24 business hours. No calls, no video, no scheduled slots, not even as an option. For an international client that is an advantage rather than a limitation: a founder in California never takes a 3am call, a team in Bengaluru never waits for a European afternoon, and the time zone problem disappears entirely. It also means every decision is searchable in month nine, when someone asks why a particular redirect exists.
What you have to do differently: batch your questions into one message instead of sending eight, describe bugs with a URL, a browser and a screenshot, and nominate one person who can approve. You own the code, the hosting accounts and the domain name, with no mandatory subscription holding them hostage. Pricing is on request. We have worked this way with French SMEs including Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats and Vectosolve.
