A website project workflow moves through seven stages: discovery, scoping, proposal, contract, design and build, change requests, and launch with handoff. Each stage produces one deliverable, gets one formal approval, and only starts once the stage before it is signed off. Skip a gate to save time and you don’t save time, you just move the argument to a later, more expensive point in the project.
Most agencies don’t lose money on website projects because they’re bad at design or development. They lose money because the project has no real sequence, just steps everyone remembers differently. A client thinks the proposal locked in the pages; the designer thinks the kickoff call did. Nobody wrote down who approved what, so when the project runs long, there’s no record to point to, just two people who each thought they were right.
I’ve run this workflow, or fixed it after someone else’s version fell apart, across 15+ years and 1,500+ clients. It isn’t complicated: seven stages, each with one deliverable and one named approver, closed out before the next begins. That’s the website project workflow, the same web design project process for agencies who don’t want to reinvent it every time. Below is the full sequence, with a link to the deep-dive post for any stage that needs one.
Stage 1: Discovery and the client questionnaire
Discovery turns a sales conversation into facts you can build from: what the site needs to do, who it’s for, and what has to connect to what. The deliverable is a written record of those answers, not a memory of the kickoff call. The client approves it by confirming the answers, ideally in writing, before anyone opens a design file.
The mistake that costs agencies most here is skipping structured discovery and going straight from a sales pitch to a mockup. Whatever the client said in that call becomes the unspoken spec, and every gap between what they said and what they meant surfaces mid-build, when it’s expensive to fix. A short, consistent set of discovery questions closes that gap early. We built a full web design questionnaire for this stage, and its answers feed everything after it.
Stage 2: Scoping the project and writing the scope of work
Scoping turns discovery answers into a written scope of work: the specific pages, templates, integrations, and content responsibilities the project includes, plus what it explicitly does not. The deliverable is that document. The client approves the scope itself, separately from the price, because a vague scope is where a website project plan template stops helping and a real argument starts.
The mistake that costs the most here is treating scoping as a formality instead of a document. “A modern site with a blog” gets nodded at in a meeting and never written down, so six weeks in, nobody can point to what was agreed. A scope that names every page and exclusion is what protects the price you quote later. We cover the questions, the deliverables list, and a full worked example in a dedicated guide on how to scope a website project. This post owns the sequence and gates; that one owns the method.
Stage 3: The proposal that turns scope into a decision
The proposal attaches a price, a timeline, and the terms the client is agreeing to before anything is signed. The deliverable is the priced proposal document. The client approves it by accepting it, the moment the project becomes a real commitment instead of a pitch.
The mistake that costs agencies most here is a proposal that doesn’t mirror the scope exactly. If it implies more than the scope actually lists, whether by loose wording or an old template nobody rechecked, you’ve just sold something you didn’t quote, and the client will remember the proposal’s language when a dispute comes up. We wrote the full breakdown, plus a copy-paste example, in our guide on the web design proposal.
Stage 4: The contract that makes it binding
The contract is where the proposal’s terms become enforceable: payment schedule, revision limits, intellectual property, kill fees, what happens if either side stalls. The deliverable is a signed agreement. Both parties approve it, and that signature, not a verbal yes, is what should trigger the first invoice and the start of real work.
The mistake that costs the most here is starting work before the contract is signed because the client “seemed ready.” That momentum doesn’t pay you back when the client stalls on payment or asks for unlimited revisions with nothing in writing to stop them. The contract protects you when things go wrong, not when things go right. We laid out the clauses that actually matter, with a copy-paste skeleton, in our guide on the web design contract.
Stage 5: Design and build on staging, with real approvals
This is the longest stage, and the one with no dedicated post, because the sequence here is simple even though the work isn’t: design comes first, gets approved, then development happens on a staging environment the client can never mistake for the live site. The deliverable is a staging build that matches the approved design. Approval happens twice, once on the design before development starts, and once on the finished staging build before launch.
The mistake that costs the most is letting development start against a design nobody formally approved, or letting a client “just tweak a few things” on staging without tracking whether that’s inside the original scope. Both create a moving target that never gets signed off, and a project that never gets signed off never gets fully paid. If your agency doesn’t want to staff the build, this is the one stage you can hand to a partner without your client ever knowing, the entire premise behind white-label WordPress services.
Stage 6: Handling change requests during the build
A change request is any work a client asks for that isn’t on the approved scope of work. The deliverable, when one comes up, is a short written change order: what’s being asked, the added time or cost, and a yes before anyone touches it. The client approves it separately from the original contract, and that approval is what keeps added work from quietly becoming unpaid work.
The mistake that costs agencies most across this whole workflow happens here: handling requests informally over email or chat instead of a documented process. That’s not a difficult-client problem, it’s the default outcome of skipping this stage. We wrote the exact steps in our change request process guide, and if it’s already cost you margin, our post on taking control of scope creep covers why agencies let it happen.
Stage 7: Launch, handoff, and ongoing care
Launch is the stage everyone remembers and few agencies actually finish properly. The deliverable is a live site plus a short go-live checklist (redirects, forms, analytics, backups), plus handoff documentation the client or their next vendor can actually use. The client approves launch itself, then separately decides what happens after that, which is the part most agencies leave undefined.
The mistake that costs the most here is treating launch as the finish line instead of a new phase. The first bug that shows up two weeks later becomes an unplanned, unpaid favor because nobody set up ongoing care before the project closed. Handoff needs a clear next step, whether that’s your own retainer or a white-label care plan you resell, and our breakdown of WordPress maintenance plans covers what belongs there.
What does the full website development workflow look like at a glance?
Here’s the same seven stages side by side: deliverable, approval gate, and the failure that shows up most when a stage gets rushed.
| Stage | Deliverable | Approval gate | Common failure |
|---|---|---|---|
| 1. Discovery | Completed client questionnaire | Client confirms answers are accurate | Skipping straight from sales call to design |
| 2. Scoping | Written scope of work | Client approves the scope itself | Scope agreed verbally, never written down |
| 3. Proposal | Priced proposal document | Client accepts the proposal | Proposal implies more than the scope lists |
| 4. Contract | Signed agreement | Both parties sign | Work starts before the contract is signed |
| 5. Design and build | Approved design, then a matching staging build | Design approved, then staging build approved | Development starts against an unapproved design |
| 6. Change requests | Written change order (as needed) | Client approves cost and time before work starts | Requests handled informally in email or chat |
| 7. Launch and handoff | Live site, go-live checklist, handoff docs | Client approves launch, then chooses next-phase care | No ongoing care plan set before the project closes |
Source: stage sequence based on 15+ years running website projects for agencies. The change-request failure rate: 52% of projects experienced scope creep in the past 12 months, up from 43% five years earlier, per Project Management Institute, Pulse of the Profession, 2018.
- A website project workflow has seven stages, and each one needs its own deliverable and its own named approver, not a shared assumption that everyone’s on the same page.
- Skipping a gate to save time doesn’t save time. It just moves the disagreement to a later, more expensive stage of the project.
- More than half of projects run into scope creep, per PMI, which is why change requests need a written process, not an email thread.
- Launch isn’t the finish line. The handoff needs a defined next phase of care, or the first post-launch bug becomes an unpaid favor.
Stage 5 is the one stage in this workflow you can hand off without your client ever knowing. If you’d rather keep design and sales in-house and let a senior team build on staging under your brand, send us the project details and we’ll come back with a fixed quote, usually within two business hours.
To turn this workflow into dates for a proposal, including client review time, use our website timeline calculator.
For everything that belongs in stage seven, accounts, documentation, backups, and the support window, use our website handoff checklist.
Frequently asked questions
What are the stages of a website project workflow?
Seven: discovery, scoping, proposal, contract, design and build on staging, change requests as needed, and launch with handoff. Each stage produces its own deliverable and needs its own approval before the next one starts.
Do I need a separate scope of work if I already send a proposal?
Yes. The scope of work names the pages, templates, and exclusions in specific detail; the proposal attaches a price and timeline to that already-approved scope. Skipping the scope and going straight to a proposal is how a proposal ends up implying more than was actually agreed.
Who should approve each stage of a website project?
The client approves discovery answers, the scope, the proposal, and the design and staging build. Both the agency and client sign the contract. Keeping approvals with the client, in writing, at each gate is what gives you something to point to if the project’s memory gets fuzzy later.
What’s the difference between a change request and normal revisions?
Revisions are adjustments to something already on the approved scope, usually covered by the rounds named in your contract. A change request is anything not on that scope. Once a request falls outside scope, it needs its own written approval for cost and time before anyone starts on it.
What happens after a website project launches?
Launch should end with a short go-live check, handoff documentation, and a defined next phase, usually an ongoing maintenance or care plan. Without that next phase set before the project closes, the first post-launch issue tends to land back on the agency as unplanned, unpaid work.
Get a free consultation and a fixed quote, usually within one business day, delivered under your agency's brand.