WordPress Development: What the Process Should Actually Look Like End to End

I have reviewed enough stalled WordPress projects to recognise exactly where they break down – Not with code or with the technology stack. In the process that was either never designed or quietly dropped once the pressure to start build became loud enough.

The most instructive one: a mid-market brand, six months in, still not live. The PHP environment had been configured for the wrong version. The REST API scope had never been documented. The client had been providing feedback across four channels with no structured review cycle. Nobody was wrong, exactly. Nobody had ever agreed what right looked like.

The short answer: A proper WordPress development process runs in five defined phases – discovery and scoping, architecture planning, staged build and review, QA and launch readiness, and post-launch handover with ownership transfer. Each phase has defined inputs, outputs, approvals and responsibilities. Any agency that cannot walk you through all five before the project starts is giving you a timeline, not a plan.

This guide maps what each phase should actually produce – and what to ask when a agency’s process looks thin. If you want to benchmark against a structured approach before entering those conversations, this overview of what a rigorous WordPress development agency delivery process looks like in practice gives you a useful baseline.

Start with discovery, scope and technical decisions before anyone touches the build

If a agency wants to jump straight into design or development, slow the conversation down. Discovery is where goals, user journeys, content structure, integrations, constraints and decision ownership get pinned down – before they become problems.

A good discovery phase does not just set direction. It produces usable outputs: sitemap, feature scope, content model, phased priorities, acceptance criteria and a cleared list of assumptions. The difference between a good discovery and a bad one shows up six months later in rework costs. If you want to see what structured discovery outputs look like in practice, a project discovery workshop is one of the highest-leverage investments you can make before committing to a full build budget.

Critically: the key architecture decisions – Gutenberg versus a page builder, ACF versus Custom Post Types for content modelling, plugin boundaries, REST API scope, PHP version compatibility requirements, MySQL environment specification – need to happen during or immediately after discovery. Not after three weeks of build. That is when changes become expensive.

What the end-to-end WordPress process should look like

Discovery: inputs are business goals, user journeys, content inventory, integrations and constraints. Outputs are scope document, sitemap, content model, phased priorities, technical decisions and acceptance criteria. Typical duration: a few days to two weeks depending on complexity.

Architecture and planning: inputs are approved scope and requirements. Outputs are theme approach, plugin boundaries, PHP and MySQL environment specification, REST API design, staging plan and delivery roadmap. Typical duration: several days.

Build and staged review: inputs are signed-off architecture and designs. Outputs are working features in staging, structured review rounds and resolved feedback. Typical duration: varies by scope.

QA and launch readiness: inputs are a near-complete staging build with real content loaded. Outputs are tested user journeys, security review, Yoast SEO and schema configuration, backups confirmed, rollback plan defined and a signed-off launch checklist. Typical duration: several days to over a week.

Handover and post-launch ownership: inputs are the live site and deployment notes. Outputs are access transfer, documentation, update protocol and named support ownership. Duration: immediate handover plus a defined stabilisation window.

When you are evaluating a agency, check whether their discovery includes real technical calls – not just stakeholder alignment sessions. Ask how they decide between Gutenberg, ACF, Custom Post Types, Elementor if it is even relevant, and any REST API requirements before build starts.

• Ask what gets produced at the end of discovery, not just what gets discussed.
• Check whether timeline estimates change after scope and architecture are confirmed.
• Watch for proposals that promise certainty before requirements are clear.

The build phase should be planned around architecture, not plugin guesswork

Once scope is confirmed, the build should follow an architecture plan. You need to know what belongs in the theme, what belongs in plugins, and what should live outside WordPress entirely – before a single template is written.

Theme architecture handles presentation: page templates, layout logic and front-end behaviour. Keep it thin. Business logic does not belong here.

Plugin architecture is where custom functionality should live – contained, maintainable and independent of the theme so it survives redesigns. If you hear “we will just find a plugin for that” more than once, treat it as a structural warning rather than flexibility. Off-the-shelf plugin stacks look economical at proposal stage and become a maintenance problem at month 18, when plugin conflicts, PHP version incompatibilities or abandoned dependencies start surfacing.

Custom plugin development standards matter more than most buyers realise. Ask how code is structured, how PHP dependencies are managed, how database queries are optimised at the MySQL level for scale, and who owns the logic if the site changes hands. These are not developer-level questions. They are ownership and continuity questions.

REST API design needs deliberate intent from the start. If the site pulls data from CRMs, stock systems, forms, membership portals or a headless front end, you need to know exactly what data moves where, how failures are handled and who monitors API health. Vague answers here almost always mean expensive surprises later. If you are weighing decoupled options, this guide on when a headless CMS architecture helps and when it adds complexity is worth reading before the architecture call.

Performance belongs in this phase too – not at the end as a fix. Asset loading strategy, image handling, MySQL query efficiency and caching architecture need to be part of the build plan. Every hour spent fixing performance post-launch costs considerably more than the same hour spent in architecture planning.

I have seen builds where a mid-sized marketing site became nearly impossible to update because all the business logic was buried inside the theme and three overlapping third-party plugins were competing for the same hooks. The visible problem looked minor. The real cost showed up in fragile updates, degraded performance scores and a six-week rework sprint nobody had budgeted for.

Not sure if your WordPress brief is ready for scoping?

We can help you map the discovery inputs, architecture decisions and staging plan before you commit to a timeline or quote. A short diagnostic call often saves weeks of rework later.

Start a scoping conversation

No obligation. Just a clearer view of what the process should cover.

A good process gives you working staging reviews, not a big reveal near launch

If the first time you see the site properly working is two days before launch, the process has already failed. That is not a project near the finish line. That is a project that skipped the part where problems get caught while there is still room to fix them.

You need a staging environment up early – separate from live, version-controlled, accessible to all reviewers – with structured review milestones mapped out before build begins. Not improvised as you go. Defined at the start.

The failure pattern I see most often is teams treating staging as a demo tool rather than a decision tool. Staging reviews should confirm working functionality, not just visual layout. That means navigation paths, form submissions, REST API data flows, ACF field structures under real content, admin workflows and content entry patterns – in a live CMS environment, not a static mock-up. Catching a content model problem at the second staging review costs one conversation. Catching it on launch day costs a week and a project relationship.

Feedback discipline is equally important and equally ignored. Every review round needs a defined scope boundary: comments tied to agreed functionality, not requests for features that were never scoped. Without that boundary, review rounds become scope creep sessions and launch dates slip without anyone being able to explain exactly why.

One more failure mode worth naming: leaving content entry, feature testing and integration checks until the final review. By the time those things are in the same environment, there is no time to fix what they expose. That sequencing error is responsible for more missed launch dates than any technical problem I can think of.

What each staging review should confirm

The first staging review should confirm structure, templates and core page behaviour – navigation, layout, template logic, and that the PHP environment and MySQL connections are behaving as expected under development data.

The second review should confirm feature logic, content entry patterns and integration data flow. This is where REST API connections, WPML multilingual configurations and ACF field structures get stress-tested under realistic content and volume.

The final pre-launch review should confirm content accuracy, tracking setup, redirect mapping, form submission behaviour, Yoast SEO schema and meta output, and sign-off against the original acceptance criteria – not against how the site looks, but against what it was agreed to do.

If you are managing an existing live site during the build, your staging approach also needs to account for content drift – pages updated on live that need reconciling before go-live. It sounds like an operational footnote. It costs projects days when it is discovered at the wrong moment.

Launch should never be the first time the site is tested like a real website. If it is, the process has already failed.

QA, security and launch readiness is where a rushed WordPRess project usually get exposed

This is the phase where weak delivery teams start hoping instead of checking. I can usually tell within the first ten minutes of a QA review whether the team treated this as a stage or a formality.

QA at this point should cover named tests, not categories. Functional user journeys across all core paths. Browser and device behaviour across agreed targets. Form submissions and error handling. Redirect accuracy for any migrated or restructured URLs. Content accuracy against approved copy. Integration behaviour under realistic data conditions. And Yoast SEO output – schema, meta titles, meta descriptions, canonical tags and Open Graph data – reviewed and signed off before anyone talks about go-live.

Security hardening belongs here and it is not a vague promise. It means: environment separation between staging and live confirmed, admin access controls reviewed and tightened, plugin audit completed, file permissions set correctly, unnecessary features disabled, WordPress core and PHP version current and verified as compatible with all active plugins, and login protection configured. If the answer to any of these is fuzzy or deferred, the launch process is not ready.

Performance needs another pass once real content, plugins, scripts and tracking are loaded. Lighthouse scores on an empty staging build with placeholder content mean very little. Run performance tests against real page weight with MySQL queries executing under realistic conditions and with third-party scripts firing.

Before go-live: backups confirmed, rollback steps named and tested, launch-day responsibilities assigned to specific people, and post-launch monitoring defined. If ongoing monitoring matters to you, clarify how it transitions into structured support before sign-off, not after the first incident.

What handover and post-launch ownership should include

Going live is not the same as finishing properly. Handover is a phase with deliverables, not an afterthought. I have watched perfectly functional sites become liabilities within six months because access credentials were not transferred cleanly, update protocols were not documented and the team that built it had moved on.

A complete handover should cover:

• Admin access, hosting access and key third-party account ownership – with named holders confirmed in writing
• Code repository, deployment notes and full environment specifications including PHP version and MySQL configuration
• Documentation for custom theme logic, plugins and integrations – including any non-obvious dependencies or custom database table structures
• Backup and update protocol with specific steps for testing updates before applying them to the live environment
• Warranty or stabilisation period, bug triage path and named escalation contact

Ask who monitors updates, who applies them, how changes are tested, and what the escalation path is if something breaks two months after launch. Do not assume project completion includes ongoing maintenance. That assumption is one of the most consistent sources of post-delivery friction I see across projects of every size.

If you want a deeper structural lens before development starts, reviewing your information architecture strategy before development begins is time well spent – because weak structure almost always surfaces again at handover, when fixing it carries a real cost.

Red flags that tell you the process is too thin

By this point, you should be comparing agencies on process maturity, not just price or likeability. The process either exists – with phase inputs, outputs, approvals and named responsibilities – or it does not. If a agencies cannot map the journey clearly, the quote is built on assumptions.

I would treat these as serious red flags:

• Fixed timelines promised before discovery is complete
• No clear answer on theme boundaries, custom plugin ownership or REST API design decisions before build starts
• No structured staging review rhythm and no named launch checklist
• Security hardening, PHP environment configuration and backups treated as optional extras rather than delivery prerequisites
• No named owner for handover, warranty or post-launch support

If you are comparing agencies, ask each one to walk you through phase inputs, outputs, approvals and responsibilities. The one that can do that clearly is usually the one with fewer surprises on the other side.

For sites with wider platform, integration or trading complexity, the same process discipline matters even more. That applies in eCommerce development in London just as much as in WordPress alone. And before committing to a full rebuild, it is worth finding out what is actually broken first – a WordPress UX audit to identify what is blocking leads and trust often changes the brief considerably.