Most WordPress development proposals describe the final product. They don’t describe the process. That gap causes real problems — clients think they’re buying a website and they’re actually buying a project, which is a different thing with different rhythms, different points of friction, and different points where decisions matter more than they look like they should. Understanding the process before you commit to a project is the difference between a build that goes smoothly and one that doesn’t.
This is what the WordPress development process actually looks like when it’s done well. Not the marketing version. The version that describes what will actually happen between the day you sign the contract and the day the site goes live.
Phase 1: Discovery and strategy
Every WordPress build starts (or should start) with real discovery. Not a form, not a questionnaire — actual working sessions with the people running the business to agree on what the site is for, who it’s built for, what success looks like, and what the site absolutely has to accomplish that the current site isn’t accomplishing.
The output of discovery is a written project brief that includes the business goals, the audience, the content strategy, the technical requirements, the integrations needed, and the success measures. This document is the compass for everything that follows. A project without a real discovery phase produces a website that looks fine but doesn’t do the specific job the business needed done — and by the time anyone notices, the budget is spent.
Discovery typically takes one to three weeks depending on the complexity of the business and how much internal alignment already exists. It’s the phase most clients want to rush and the phase that most predicts whether the project succeeds. We’ve written more about the underlying methodology in Content Strategy for Service Businesses — the same discipline applies to the whole build, not just the content.
Phase 2: Information architecture and content planning
Before any design happens, the structure of the site gets mapped: what pages exist, how they relate to each other, what the URL structure looks like, what the primary navigation is, how content flows from top-level pages to deep pages. This is the site’s skeleton, and getting it right at this stage saves weeks of rework later.
Content planning happens in parallel. Every page needs a purpose, an audience, a message, and a call to action. Every piece of content on the site should be earning its place. Skipping this phase produces sites that have pages nobody knows what to do with — the CEO’s biography, the value-proposition page nobody visits, the services page that hasn’t been updated in three years. Deliberate content planning prevents that.
The deliverables from this phase are a sitemap, a content plan, and (often) content wireframes that show what each page contains before any visual design happens. Clients sometimes push back on wireframes because they want to see “the design.” The wireframes exist precisely so the visual design can focus on visuals rather than trying to figure out what content goes where.
Phase 3: Visual design
With the structure locked, visual design begins. The design phase produces the actual look and feel of the site — the color system, the typography, the imagery style, the page layouts, the interactive elements. Design is done in mockups (Figma is common) before any code gets written, because iteration in mockups is dramatically faster than iteration in code.
Design is where “WordPress design” and “WordPress development” overlap most, and where the difference between them matters most. Design decisions constrain development decisions — a design that requires complex custom interactions will require more development. A design that stays within the platform’s native capabilities will build faster and cost less. Good design considers both what looks right and what will build well. We’ve gone deeper on this in The Relationship Between UX and Infrastructure.
Typical design phase runs three to eight weeks depending on scope. Two rounds of design revision is standard. Unlimited revisions almost always end badly — either the project never finishes or the designer starts cutting corners to stay within budget.
Phase 4: WordPress development
This is the phase most people think of as “the project,” but it’s actually the middle third, not the whole thing. Development takes the approved design and builds it in WordPress: custom theme development or configuration of a builder like Divi, custom post types for structured content, plugin integrations, forms, third-party service connections, custom functionality specific to the business.
Modern WordPress development on well-built builders (Divi 5 in particular, which we’ve written about in Divi 5 stopped being a page builder and became a development platform) is genuinely faster than it used to be — the platform handles the mechanical work, and development effort goes into the parts that actually differ from a template. This is one of the reasons a boutique studio can compete with much larger agencies on delivery speed without cutting quality.
Development happens on a staging environment — a copy of the live site that isn’t publicly accessible. Everything gets built and tested there before touching the production site. Development phase runs four to twelve weeks for most business sites; longer for sites with substantial custom functionality or integrations.
Phase 5: Content migration and integration
Often the longest phase and the one most likely to run over budget. If there’s an existing site, content has to move from the old site to the new site — pages, blog posts, images, media, comments, redirects for old URLs. Every integration has to be wired up: the CRM, the email marketing platform, the analytics stack, payment processing if there’s e-commerce, any third-party services the business relies on.
Content migration is deceptively simple. Sites with a few dozen pages and a straightforward structure move cleanly. Sites with hundreds of posts, custom fields, complex media, or legacy URL patterns take significantly longer. Underestimating this phase is one of the most common ways WordPress builds run late.
Phase 6: Testing and quality assurance
Before launch, everything gets tested: the site loads on real devices and browsers, forms submit correctly and route to the right places, integrations fire the right data, page speed is acceptable, SEO settings are correct, redirects work, analytics are tracking. Content is proofread. Broken links are found. Missing images are replaced.
Testing catches the problems that would otherwise become launch-day problems — and launch-day problems are dramatically more expensive than pre-launch problems. A week of testing prevents a month of firefighting.
Phase 7: Launch
Launch is the moment the new site replaces the old site on the live URL. Done well, this is anticlimactic — DNS changes, the new site becomes live, existing traffic keeps flowing. Done badly, this is when SEO rankings drop, forms stop working, emails don’t get delivered, and the marketing team has a bad week.
Launch involves a specific sequence: final content review, redirect verification, DNS changes, cache invalidation, monitoring for the first 24-48 hours, and a rollback plan in case something serious surfaces. We’ve written about the security posture that keeps sites resilient in the WordPress development pillar — much of the same discipline applies to how launches get handled.
Phase 8: Post-launch and ongoing
Development doesn’t end at launch. The first weeks after launch reveal issues that weren’t visible in testing — content that needs adjusting, small bugs that only appear at real-world traffic volumes, integrations that need tuning. Post-launch attention is part of the build, not an afterthought.
Beyond immediate post-launch, ongoing maintenance is the difference between a site that stays healthy for years and one that decays into another rebuild in two years. WordPress core updates, plugin updates, security patches, backup verification, performance monitoring, and small ongoing changes — this is why maintenance is strategic, not optional.
How long does the whole process take?
For a small business WordPress site with straightforward requirements: eight to twelve weeks total. For a mid-market site with real integrations and custom functionality: three to six months. For enterprise or multi-location builds: six to twelve months. Anyone who quotes a two-week WordPress build for anything beyond a template installation is either using a template or setting up a project that will disappoint everyone involved.
The single biggest predictor of timeline isn’t the size of the site — it’s how prepared the client is when discovery starts. Clients who have their content ready, decisions made, and stakeholders aligned move dramatically faster than clients who don’t. Preparation is the leverage point.
What to look for in a WordPress development partner
A good WordPress development partner will describe a process similar to the one above, ask real discovery questions before quoting, be specific about what’s included and what’s excluded, and be willing to tell you when the project you’re asking for isn’t the project you actually need.
A partner to avoid is one who skips discovery, quotes based on an assumption rather than a conversation, promises specific outcomes they can’t guarantee, or treats the build as a one-time transaction rather than the start of a relationship. We covered this in more depth in How to Hire a WordPress Developer: A Buyer’s Guide for 2026.
If you’re planning a WordPress build and trying to figure out whether the process a specific vendor is proposing is the right one for your situation, tell us what you’re working on. We’ll give you a straight read on whether the process makes sense — including the honest version where the partner you’re already talking to is the right fit.
