How to Manage a Web Development Project as the Client (2026 Guide)

Every guide on web project management is written for developers, agencies, or project managers. This one is written for the client — the business owner or marketing lead who hired an agency and is now responsible for making the relationship work. What you do during the project matters as much as who you hired.

Managing a web development project as a client involves four core responsibilities

• providing clear, timely feedback at each milestone.
• managing scope additions through formal change requests rather than casual conversations.
• maintaining a single point of contact on your side.
• and monitoring project health through regular status reviews rather than micromanaging the team's daily work.

The most common client-side failure is making decisions by committee and communicating conflicting requirements to the agency at different times.

There are thousands of articles about how agencies should manage client relationships. Almost none about how clients should manage the agency relationship.

Yet the client's behaviour during a project — how they give feedback, how they handle milestone reviews, how they manage internal stakeholders, how they respond to scope requests — is one of the strongest predictors of project success. Bad clients produce bad projects even with good agencies. Good clients produce good projects even when the agency is imperfect.

Nobody teaches you how to be a good client. Your agency wants your money. Your team wants the project done. Your stakeholders want results. And you are in the middle, managing a technical project you may not fully understand, with a team you have just met, on a timeline that probably already feels tight.

This guide fills the gap. It covers everything you need to do on your side of a web development engagement — from kickoff through delivery — to maximise the chance of a successful outcome.

---

Why Your Behaviour as a Client Determines Project Success

Most post-mortems on failed web projects blame the agency. Sometimes that blame is deserved. Often, the root cause is more complicated.

Agencies are not the only party with responsibilities in a development engagement. Clients contribute to project failure through patterns that are rarely acknowledged because it is uncomfortable to tell a paying client they are making the project harder:

Decision-making by committee. Design goes to six stakeholders for feedback. Each has a different opinion. The agency receives contradictory feedback and either tries to satisfy all of it (producing a compromised result nobody likes) or asks for clarification (creating delay while internal alignment is sorted out). This is one of the most common causes of extended timelines.

Feedback that describes preferences rather than problems. "I don't like how this looks" gives a developer nothing to act on. "The hero section is not communicating our primary value proposition — customers who see this page will not know within 3 seconds what we do or why it matters to them" is actionable feedback that the team can address specifically.

Scope additions framed as small requests. "While you are at it, could you also add a booking system?" framed in a casual email during development is either a change order or it is absorbed into the project at the cost of something else. Either outcome is worse than formally requesting the addition before it becomes an informal expectation.

Disappearing during the project. Clients who are hard to reach during development slow everything down. Approvals take two weeks instead of two days. Questions that need answers to unblock development sit in an inbox. Timelines slip — and the client is surprised when the project is delivered late.

Being too available in the wrong way. The opposite problem: clients who bypass the project manager to send direct messages to developers, attend every stand-up meeting, and want daily progress updates. This fragments the development team's focus, creates multiple instruction channels (which one takes priority?), and generates anxiety without generating progress.

The client's job during a project is specific and bounded: provide clear requirements upfront, give timely and actionable feedback at defined milestones, make decisions quickly when asked, and manage internal alignment so the agency receives one consistent voice.

💡 Key Takeaway: Being a good client is a learnable skill with specific behaviours that help or harm project outcomes. The most important skills are: giving structured feedback, managing scope formally, maintaining a single point of contact, and making decisions promptly.

---

What Clients Should Prepare Before a Web Development Project Starts

The first week after signing is often wasted. Both parties are excited. The agency starts gathering information. The client starts having second thoughts about scope items. Decisions that should have been made before the contract get made during kickoff — which means the discovery phase starts with unresolved questions.

Do these things before the kickoff meeting:

Appoint a single point of contact. Design by committee kills projects. Identify one person on your team who has decision-making authority for the project — not someone who needs to escalate every decision to leadership, but someone who can review design options and say yes or no. Too many contact persons and decision-makers will slow down the project considerably. If multiple stakeholders need input, your point of contact is responsible for gathering it and presenting a single consolidated position to the agency.

Gather all your assets. Logo files (SVG and PNG), brand guidelines, photography, existing content, access credentials for any systems that need integrating. Agencies cannot start design without brand assets. Integrations cannot be scoped without API access credentials. An asset gathering exercise the week after signing prevents delays that the agency gets blamed for.

Set internal expectations. Tell your team what is happening, what they will be asked to contribute, and when. If content needs to be written by your team before the development phase, they need to know now — not three weeks into the project when the developer is waiting for copy.

Create a decision log. A shared document (Google Doc works) where decisions made during the project are recorded with dates and decision-makers. This prevents "but I thought we agreed..." disputes and provides a reference when scope questions arise.

Read your contract. Specifically: what are the deliverables, the milestones, the payment triggers, and the change order process? You will need this knowledge during the project. Discovering the change order process when you are first encountering it under pressure is not the right time.

---

The Kickoff Meeting: What to Establish From Day One

The kickoff meeting sets the working relationship for the entire project. What gets established here — communication cadence, escalation paths, decision-making process — tends to persist. What does not get established here tends never to get established.

What to cover in kickoff:

Communication cadence. How frequently will you receive project updates? In what format? Who sends them? What is the expected response time for client messages? Agree this explicitly. A project that starts with weekly written status reports and clear response time expectations runs significantly more smoothly than one where communication is ad-hoc.

The decision-making process. How will decisions be made? Who has sign-off authority on design? On technical choices? On scope changes? When is a decision escalated? When is it made at the project level without escalation?

The change order process. If you want to add something to the project, what happens? Who do you contact? What information is needed? What is the timeline for a change order response? Agreeing this at kickoff makes change requests significantly less contentious when they arise mid-project.

Milestone schedule. What are the deliverable milestones, when are they, and what is the client's role at each? Knowing upfront that you will receive design mockups for review in week 4 gives you time to prepare your internal review process.

Access and tools. What tools will the team use for project management and communication? Do you have access? Who on your team needs access? Agree on a single primary communication channel — email, Slack, or a project management tool — rather than multiple channels that fragment the conversation.

What not to do in kickoff: Do not use the kickoff meeting to re-open scope discussions that were resolved in the brief. Do not bring additional stakeholders without telling the agency in advance. Do not use the meeting to list new requirements that were not in the brief — note them separately as potential change requests.

---

Phase 1: Discovery and Design — Your Highest-Leverage Phase

The discovery and design phase is where your input has the highest leverage and the lowest cost. A change in direction during discovery costs hours. The same change during development costs days or weeks. The same change post-launch costs most.

Your role in this phase:

Be available for workshops and interviews. Discovery involves gathering requirements that may not have been fully captured in the brief. Make the right people available — the people closest to customers, the people who understand the business processes the site needs to support, the people who will use the CMS. Their time in discovery is an investment that prevents expensive clarifications later.

Review wireframes before visual design begins. Wireframes are structural — they show layout and content placement without visual polish. This is the cheapest point to change direction. If the homepage structure does not communicate what you need it to, a wireframe change is a conversation. A visual design change requires the designer to revisit their work. A development change requires the developer to revisit theirs.

Do not skip wireframe review. The most common client-side mistake in the design phase is looking at wireframes and thinking "I will see how it looks when it has proper design." What you are reviewing in a wireframe is not how it looks — it is whether the structure, hierarchy, and flow make sense for your users. Approving a wireframe structure that does not work, because you were waiting to see it visually, creates expensive rework when the visual design lands on a broken foundation.

---

How to Review Designs When You Are Not a Designer

Design review is where the most subjective and least useful client feedback occurs. "I don't like it" and "make it pop" are real feedback patterns that real developers and designers encounter — and cannot act on.

The goal of a design review is not to express whether you personally like the aesthetic. The goal is to evaluate whether the design serves its functional purpose for your users.

The four questions to ask in every design review:

1. Does this communicate what we need to communicate? A homepage hero section should communicate your core value proposition to a cold visitor in under 5 seconds. Does it? Not "does it look good" — does it communicate the right message to the right person?

2. Can a user accomplish their goal? For every primary user journey, can a user follow the path from entry to conversion without confusion? Is the call to action visible, specific, and compelling? Are there friction points that would cause a user to leave?

3. Is anything factually wrong or missing? Content errors, missing required elements, wrong information. These are factual problems with clear resolutions.

4. Does this reflect our brand? Not "does this look like what I imagined" but "is this consistent with our brand guidelines and appropriate for our positioning in the market?"

What to avoid saying in design feedback:

• "I'm not sure about the colours" → Say instead: "The primary action button doesn't have enough contrast to stand out on this background — it may not be obvious to users as the main call to action"
• "It looks a bit plain" → Say instead: "The homepage doesn't communicate the depth of our expertise — I'd like to see the data point about X more prominently featured"
• "My CEO doesn't like it" → This is not feedback. It is a stakeholder management problem. The CEO's preference needs to be translated into a specific, actionable requirement.

Consolidate feedback before sending. Gather input from all relevant stakeholders before submitting feedback. An agency that receives feedback from the marketing lead on Monday and conflicting feedback from the CEO on Thursday has to choose which to act on — and either choice creates a problem. Your point of contact is responsible for consolidating all internal feedback into a single document before it goes to the agency.

💡 Key Takeaway: Design feedback should describe what is not working functionally — what the design fails to communicate, what user goal it fails to serve, what requirement it fails to meet. Aesthetic preference is subjective and non-actionable. Functional criticism is specific and fixable.

Need an independent second opinion on what your agency is building? We help clients review requirements, milestone quality, and pre-launch risk before problems become expensive.

Phase 2: Development — What to Do (and Not Do) While It Is Being Built

The development phase is the one where clients most often feel out of control — because they cannot see what is happening. The agency is writing code. You are waiting. The temptation is to fill the uncertainty with micromanagement.

What to do during development:

Review status updates properly. Read the weekly status report. Note any items flagged as at risk or delayed. Ask for clarification on anything that is unclear. If a milestone is slipping, address it immediately rather than hoping it corrects itself.

Prepare your content. If your team is responsible for supplying copy, images, or data before the content build phase, use development time to prepare it. Delays in content delivery from the client are the single most common cause of developer wait time — and are almost always invisible in post-project retrospectives where only agency performance is examined.

Prepare your team for UAT. User acceptance testing (covered in full below) requires real time from real users on your team. Identify who will participate, block their calendars, and brief them on what UAT involves before the testing period arrives.

What not to do during development:

Do not contact developers directly. Unless explicitly agreed, communication goes through the project manager. A developer who receives a direct message from a client asking "can we also add X" is now managing an instruction that may or may not be sanctioned by their project manager. Direct client-to-developer communication creates scope confusion and accountability gaps.

Do not request live demos of partial builds. Developers working in partial builds are showing you incomplete functionality in a staging environment. Feedback based on this — "the colours look wrong" when CSS hasn't been applied — generates noise rather than signal. Review at agreed milestones, not ad hoc.

Do not add new requirements through casual channels. "While you're at it" requests sent by email or messaging without going through the formal change order process are not in scope. They may be acknowledged, they may be acted on informally, or they may be forgotten — none of which is a good outcome. Use the change order process.

---

Milestone Reviews: How to Approve Work Properly

Milestone reviews are formal acceptance checkpoints. When you approve a milestone, you are confirming that the deliverable meets the agreed requirements and that development can proceed to the next phase. This matters because: work after a milestone approval is based on that approval. If you approve design and later want to change it during development, that is a change order.

How to conduct a milestone review:

Step 1: Review against the brief and scope of work, not against your current preferences. The question is not "do I like this?" but "does this meet what we agreed to build?" Your brief and the agency's scope of work document are your reference materials.

Step 2: Test it yourself before gathering stakeholder feedback. Go through the deliverable as a user would. Complete the primary user journeys. Note anything that does not work or does not match the agreed requirements.

Step 3: Gather consolidated stakeholder feedback. Give stakeholders 48–72 hours to review. Collect their feedback. Consolidate it into a single list, resolving conflicts where they exist. Do not send unconsolidated stakeholder feedback to the agency.

Step 4: Classify your feedback. Before sending:

• Must fix before approval: items that do not meet agreed requirements
• Should fix within this phase: significant issues that would benefit from addressing before moving on
• Nice to have: improvements that are not in scope but worth flagging as potential change orders
• Observations only: noting something for information, not requesting a change

Step 5: Send consolidated, classified feedback with a clear next step. "We have reviewed the design milestone and have the following feedback. Items 1–4 are required changes before we can approve. Items 5–7 are suggested improvements. We can approve the milestone once items 1–4 are addressed."

When to approve despite reservations: If the deliverable meets the agreed scope and requirements, approve it — even if your aesthetic preferences differ. Withholding approval on a deliverable that meets its specification because you would prefer a different creative direction is a scope change, not a quality issue. If you want a different creative direction, that is a change order conversation.

---

How to Give Feedback That Developers Can Act On

Feedback quality is one of the highest-leverage skills in client-side project management. Good feedback closes review cycles in one round. Poor feedback creates multiple rounds of "we fixed it, is this what you meant?" — each consuming time and eroding the relationship.

The structure of actionable feedback:

What: Specifically what element or feature are you referring to? Problem: What specifically does not work, and why? Context: What user, what goal, what scenario? Desired outcome: What should the correct version do or say? (If you know)

Example — poor feedback: "The homepage doesn't feel right. Can we rework it?"

Example — actionable feedback: "Homepage, hero section: A cold visitor arriving from a Google search for 'financial services consultancy London' will not understand from the current hero what we do or who we work with. The headline 'Transforming Business' does not communicate our specialisation or our client profile. I'd like the hero headline to reference our sector focus (financial services) and our primary value proposition (compliance expertise that reduces regulatory risk). Suggested direction: 'Regulatory Compliance Consulting for UK Financial Services Firms.'"

The second version tells the designer exactly what the problem is, why it is a problem, and what a better direction looks like. It can be acted on in a single revision cycle.

Format for feedback submission: Use a numbered list. One issue per number. Include the page name and element being referenced. Do not embed feedback in a paragraph of prose — it gets lost and is hard to track.

Response time expectations: Agencies delivering milestone reviews expect client feedback within an agreed window — typically 3–5 business days. Delayed feedback delays the project. If you cannot review within the agreed window, communicate proactively: "We need an additional 3 days for internal review — our project manager will confirm the new feedback deadline."

---

Scope Creep: Recognising It, Managing It, Preventing It

Scope creep is the gradual addition of work beyond the original agreed scope — typically through reasonable-sounding requests that individually seem minor but collectively add weeks and significant cost to a project. It is the most common source of over-budget, over-timeline web projects.

What scope creep looks like:

The casual addition: "While you're at it, could you also add a newsletter signup popup?" Mentioned in a meeting, not formally requested, not change-ordered. Developer adds it. Client assumes it is included. Invoice arrives with it as a line item. Dispute follows.

The feature expansion: "The contact form should also let users book appointments." This is a different feature from a contact form — it requires calendar integration, booking logic, conflict resolution, and automated confirmation emails. It was not in scope. It was not priced.

The design change after development: "We've been looking at the homepage and we'd like to change the hero section." After the homepage is built in code. A design change at this stage requires both design and development rework — significantly more expensive than making the same change at the design review stage.

The missing requirement discovery: "Oh, the site also needs to work in French." Multilingual support is a significant development feature that affects the CMS architecture, URL structure, and potentially the design. It was not in the brief. It should have been.

How to manage scope changes formally:

Every addition to scope — however small — should go through a change request process:

1. Submit the change request in writing to your project manager
2. Receive a written estimate of cost, timeline impact, and effect on other deliverables
3. Make a formal decision to approve or decline
4. If approved, receive a written change order that amends the original contract

This process is not bureaucracy — it is the mechanism that keeps both parties informed and protected. An agency that adds scope informally without change orders is doing you a favour in the moment and creating a billing dispute later. An agency that insists on formal change orders for everything is doing their job properly.

The scope change you should not make mid-project:

Significant direction changes — changing the primary target audience, changing the core purpose of the site, changing the underlying technology platform — rarely make sense mid-project. The right time for these decisions is in discovery. The cost of making them mid-development is almost always higher than pausing, re-scoping, and restarting the affected phases.

💡 Key Takeaway: Scope changes are not inherently bad — products and businesses evolve, and briefs are never perfect. The problem is not changing scope; it is changing scope informally without tracking the cost. Use the change order process every time, even for small additions.

---

Red Flags During Delivery (Not Just at Hiring)

The hiring red flags covered in our agency hiring guide for what to do. apply before you sign. These are the signals that appear during delivery — warning that the project is in trouble before the trouble becomes a crisis.

Red flag: Milestone slippage without proactive communication One missed milestone with a clear explanation and a credible revised plan is recoverable. A pattern of missed milestones — where the agency waits for you to ask rather than proactively flagging the slip — indicates a team that is either overwhelmed or hoping you will not notice. Address it directly and in writing at the first occurrence.

Red flag: Vague or absent status reports Weekly status reports that say "development is progressing well" without specifying what was completed, what is in progress, and what is coming next are concealing rather than communicating. A status report should give you a specific picture of where the project stands against the plan.

Red flag: Feedback rounds multiplying If the same design elements are being revised for a third or fourth round without resolution, something is structurally wrong — either the feedback is not actionable, the creative direction was not agreed at the start, or there is a misalignment in interpretation that needs a direct conversation rather than another revision round.

Red flag: Developers asking fundamental questions late in the project Basic questions about data structure, user flows, or integration requirements that should have been resolved in discovery appearing in week eight of development indicate that the discovery phase was insufficient. These questions signal that what is being built may not match what was agreed.

Red flag: "It will all make sense when it's finished" An agency that is resistant to showing work in progress, that defers all review to final delivery, or that dismisses your questions with this phrase is not building transparency into the relationship. You are entitled to staged review of work in progress. Resistance to this is a red flag.

What to do when a red flag appears:

Address it directly in writing at the first occurrence. "I've noticed that the last two milestones have slipped without proactive communication. I'd like to understand the current status against the project plan and what is being done to recover the timeline." Keep the tone professional and factual. Note the response. If the pattern continues, escalate — first to the agency's senior leadership, then if necessary through your contract's dispute resolution process.

---

When to Push Back vs. When to Defer to the Experts

One of the most consistently difficult judgments for non-technical clients is knowing when to challenge an agency's recommendation and when to trust their expertise.

Defer to the experts when:

They recommend a different technical approach than you specified. If your brief specified WordPress and the agency recommends Webflow for your specific use case, with a clear rationale — defer. Technical platform decisions are within their expertise. If their reasoning is clear and specific to your situation, they may be right.

They flag a timeline as unrealistic. If you have requested a 10-week delivery for a scope that the agency has estimated at 18 weeks, their estimate is more likely to reflect the reality than your preference. Pushing for the shorter timeline without reducing scope produces a rushed, poor-quality build.

They recommend against a feature you want. An agency that tells you a requested feature will not serve your users, or will create technical debt that makes the system harder to maintain, is exercising the expertise you hired them for. This is not obstruction — it is professional judgment. Engage with their reasoning before dismissing it.

Push back when:

Their recommendation is not explained. "We recommend X" without a rationale specific to your situation is a vendor preference, not a recommendation. Ask for the specific reasoning. A good agency can always explain why.

The change benefits them more than you. An agency recommending a platform they specialize in, a technology their team prefers, or a scope expansion that increases their revenue deserves scrutiny. Their interests and your interests are not always aligned.

The deliverable does not match the agreed scope. If what is delivered does not match what was specified in the scope of work, you are not pushing back — you are enforcing your contract. Be specific, cite the relevant scope document section, and request resolution.

The quality is clearly below professional standard. Broken functionality, significant design deviations from approved mockups, or performance that falls materially below agreed targets are legitimate quality issues that warrant formal feedback and remediation requests.

---

Managing Internal Stakeholders During the Project

One of the most consistently underestimated client-side challenges is managing internal stakeholders — the leadership team, the department heads, the board member who "has some ideas about the website."

The single point of contact principle protects your project. Every stakeholder who has direct access to the agency is another instruction channel — another source of contradictory requirements, scope additions, and changed directions. Your project manager on the client side gathers input from all internal stakeholders and presents a single consolidated position to the agency.

Managing leadership expectations:

Senior leaders often engage late in a project and arrive with fresh perspectives on decisions that were made weeks ago. The decision log (set up before kickoff) is your tool here: it documents what was decided, when, and by whom. "We discussed this at the kickoff meeting and decided to proceed with X because Y" is a more productive response to late-stage leadership input than re-opening a decision that has already been built around.

Managing the "I have an idea" problem:

New ideas for the website will emerge throughout the project. This is normal. The problem is when new ideas enter the project informally without scope assessment. Create a backlog for ideas that emerge during the project — capture them, assess them at natural decision points (phase transitions, milestone reviews), and route the ones that are genuinely valuable through the change order process. Ideas that are not in scope stay in the backlog for the next phase.

What to tell stakeholders who want to give the agency direct feedback:

"All feedback goes through [name], our project point of contact. If you have specific input, please send it to [name] by [date] and it will be included in the consolidated feedback document we send to the agency. Direct feedback to the agency team creates confusion about which instructions to follow."

---

User Acceptance Testing: Your Most Important Job Before Launch

User acceptance testing (UAT) is the period before launch when your team tests the delivered product against the agreed requirements — confirming it is ready to go live. It is the most important client-side responsibility in the entire project, and the one most commonly rushed, skimped on, or delegated to a single person without adequate time.

What UAT is: A systematic test of every user journey, every integration, and every functional requirement against the agreed scope. Conducted by people on the client side who understand the business requirements — not just the agency's QA team, who tested against their own specification.

What UAT is not: A time to request new features, redesign elements you have already approved, or revisit decisions made in earlier phases. UAT is about validating that what was agreed was built — not about getting a second design review.

How to run a UAT period effectively:

Prepare your test scenarios in advance. Before UAT starts, write out the key things you need to test — one test scenario per primary user journey. For each scenario: who is the user, what are they trying to do, what are the steps, and what is the expected outcome?

Include edge cases. What happens when a user submits a form with invalid data? What happens when a payment fails? What happens when a user tries to access a page they do not have permission for? These states were specified in your brief and need to be tested.

Assign specific testers to specific scenarios. UAT works better when individual testers have clearly assigned scenarios rather than everyone testing everything. Cover all primary user journeys across the test team.

Document findings formally. Every issue found in UAT should be recorded with: the test scenario and step where the issue occurred, expected behaviour, actual behaviour, screenshot or recording, and a severity classification (critical, major, minor). Informal "it doesn't work on my phone" reports are not actionable UAT documentation.

Set a UAT timeline and stick to it. A 5–7 business day UAT period is standard for most projects. Define the start and end dates. Define what happens if critical issues are found (the timeline extends, the launch is delayed). Define what constitutes "ready to launch" — typically all critical issues resolved, all major issues either resolved or accepted with a documented workaround.

Your role in UAT as a client is not optional. An agency cannot substitute its own testing for client UAT. They do not know your business requirements the way you do. They test against their specification. You test against your business reality. Both perspectives are necessary.

💡 Key Takeaway: UAT is the client's primary quality gate before launch. A rushed UAT period is a decision to discover issues in production — where they cost more to fix and damage user trust. Allow proper time, prepare proper test scenarios, and document findings formally.

---

How Often Should Clients Review Progress?

Weekly.

Most web development projects work best when clients receive weekly written progress updates and review work formally at milestone checkpoints.

A useful weekly update should clearly show:

• what was completed
• what is currently in progress
• what is at risk
• what the client needs to approve next

---

Frequently Asked Questions

How do I manage a web development project if I don't have technical knowledge?

Non-technical clients manage web projects successfully by focusing on outcomes rather than implementation — describing what users need to be able to do, not how the system should be built. Communicate requirements in terms of user journeys and business goals. Evaluate deliverables against whether they meet those goals. Defer to the agency on technical implementation choices, but hold them accountable for the outcomes agreed in the scope of work. Technical knowledge helps but is not required to be an effective client.

How often should I expect updates from my agency?

Weekly written status updates are the standard cadence for most projects. The update should specify: what was completed this week, what is in progress, what is planned for next week, and any items that are at risk or blocked. For longer or more complex projects, bi-weekly milestone reviews in addition to weekly updates are appropriate. If your agency is not sending weekly updates unprompted, request them formally.

What should I do if the project is running over the agreed timeline?

First, request a written explanation of the cause and a revised plan for delivery. One timeline slip with a clear cause and a credible recovery plan is recoverable. Assess whether the slip was caused by factors on the agency's side (resource issues, underestimation) or on yours (delayed feedback, late content delivery). If the slip was on your side, acknowledge it and resolve it. If it is on the agency's side, agree a revised timeline in writing and monitor closely.

How do I handle it if I disagree with a design decision the agency has made?

First, evaluate whether your disagreement is functional (the design does not achieve the agreed purpose) or aesthetic (you would have made a different creative choice). Functional disagreements are legitimate feedback that the agency should address. Aesthetic preferences, when the design meets the functional requirement, are not feedback they are obligated to act on — changing the creative direction after design approval is a scope change. Be specific about what the design is not achieving and why, not just that you prefer a different approach.

What is a change order and when should I use it?

A change order is a formal, written amendment to the project scope specifying what is being added or changed, what it costs, and how it affects the timeline. You should use a change order process for any addition or modification to the agreed scope — including items that seem small. The cumulative cost of informal scope additions is the most common source of project budget overruns. A well-run agency will insist on change orders for additions. A poorly run one will absorb them informally and invoice for them later.

Is it normal for an agency to push back on my feedback?

Yes — and a good agency pushing back on feedback is a positive signal, not a problem. If an agency challenges your direction with a specific rationale ("we recommend against X because Y for your specific users"), they are exercising the expertise you hired them for. Engage with their reasoning. An agency that agrees with everything and never pushes back is either always right (unlikely) or conflict-averse in a way that will produce a worse outcome.

How many rounds of design feedback is normal?

Two rounds of feedback per design phase is typical. Three is common for complex projects or difficult-to-align stakeholder groups. Four or more rounds indicate either that feedback is not actionable (too vague or contradictory), that the design brief was not specific enough, or that there is a fundamental misalignment in creative direction that needs a direct conversation rather than another revision round.

What should I do if I am unhappy with the quality of work delivered?

Document the specific quality issues — what was agreed, what was delivered, what the gap is. Send formal written feedback referencing the scope of work document. Give the agency a clear opportunity to remediate. If they are unresponsive or the quality issue persists, escalate to the agency's senior leadership. If the issue cannot be resolved through direct engagement, your contract's dispute resolution process is the next step. Keep all communication in writing from the point the quality concern is raised.

What is the most common client mistake that delays a project?

Delayed feedback. Agencies working in development phases are often blocked waiting for client approvals or content that has not arrived. Every day of client-side delay adds a day to the timeline — without appearing in any project report as the agency's responsibility. The most reliable thing you can do to protect your project timeline is respond to review requests within the agreed window, every time.

How do I tell my internal stakeholders the project is progressing well?

With specific milestones, not adjectives. "The project is going well" means nothing your stakeholders can evaluate. "We completed the design phase on schedule last week. Development begins Monday. We are on track for the UAT period starting [date] and the launch target of [date]." Milestone language is specific, verifiable, and maintains stakeholder confidence without generating unrealistic expectations.

When should I be worried about my project?

Worry when: milestones are being missed without proactive communication from the agency; feedback rounds are multiplying without resolution; the agency is avoiding showing work in progress; you are hearing "it will all make sense when it's finished"; or fundamental questions about requirements are emerging late in the project. Any one of these is worth a direct conversation. Multiple at the same time is a project recovery situation. See our Red Flags guide for what to do.

What is UAT and do I need to do it?

User acceptance testing is a structured testing period before launch where your team validates that the delivered product meets the agreed requirements. Yes, you need to do it — and you need to do it properly, not just have one person click around for 30 minutes. UAT is the client's primary quality gate before launch. See the UAT section above for how to run it effectively.

How do I give feedback on something I do not understand technically?

Describe what you are trying to achieve rather than specifying the technical implementation. "When a user submits the contact form, I need to receive an email notification immediately" is clear and actionable. "The SMTP settings for the email server need to be configured" is technical specification that belongs to the developer, not the client. Describe the outcome you need. Let the developer determine the implementation.

How do I know if an agency is being honest with me about the project status?

Ask for the project to be described against a plan with specific milestones and percentage-complete estimates. Vague progress descriptions ("things are going well") with no reference to a plan are concealing rather than communicating. A project that is on track should be able to show you: what the agreed milestones are, which are complete, which are in progress, and what the current completion percentage against timeline is. If this picture is not available, that itself is information.

What should I prepare before the launch date?

Your announcement and promotion plan (who you are telling, when, through what channels). Your monitoring setup — analytics, uptime monitoring, and a way to receive user feedback. Your internal team's awareness of the launch and their role in it. Contact details for emergency support in the first week post-launch. A list of the things you are testing on the live site before going public. See our post-launch guide for the complete first-90-days framework.

---

Your Client-Side Project Management Checklist

Implement as HowTo schema on publish.

Before Kickoff

• Single point of contact appointed with decision-making authority
• All brand assets and existing content gathered and ready
• Internal team informed of their responsibilities and timelines
• Decision log document created (shared with agency)
• Contract reviewed — deliverables, milestones, payment triggers, change order process understood

Kickoff

• Communication cadence agreed (weekly status reports minimum)
• Decision-making process agreed and documented
• Change order process agreed and understood by both sides
• Milestone schedule confirmed with client review dates blocked in calendar
• Access to project management tools confirmed for relevant team members
• Single communication channel agreed

Discovery and Design Phase

• Relevant team members available for discovery workshops
• Wireframes reviewed against brief requirements (not aesthetic preference)
• Design reviewed against functional purpose and user journeys
• Feedback consolidated from all stakeholders before sending to agency
• Feedback formatted as numbered list with page, element, problem, and desired outcome
• Design approved in writing before development begins

Development Phase

• Status reports reviewed weekly
• Content delivered to agency by agreed date
• UAT participants identified and calendars blocked
• No direct client-to-developer communication without project manager involvement
• All scope change requests submitted formally, not informally
• All change orders reviewed, priced, and approved in writing before work begins

Milestone Reviews

• Each milestone reviewed against scope of work, not personal preferences
• Feedback classified as: must fix, should fix, nice to have, observation
• Consolidated feedback submitted within agreed window
• Milestone approvals issued in writing

UAT

• Test scenarios prepared in advance for each primary user journey
• Edge cases and error states included in test plan
• Testers assigned to specific scenarios
• UAT findings documented formally (step, expected, actual, severity)
• Critical issues resolved before launch approved
• Launch criteria defined in advance

Launch

• Go-live decision made in writing
• Post-launch monitoring confirmed in place
• Internal team aware of launch date and plan
• First-week support contact confirmed with agency

---

Conclusion

When managing a website project as a client the agency you hired is responsible for building the right thing, building it well, and delivering it on time. You are responsible for telling them clearly what the right thing is, reviewing their work promptly and specifically, managing scope formally, and maintaining internal alignment so they receive one consistent voice.

These responsibilities are not symmetrical in effort — the agency carries the technical execution load. But they are symmetrical in impact. A poorly managed client engagement will produce a worse outcome from a good agency. A well-managed client engagement will produce a better outcome from an average agency.

The behaviours in this guide are learnable. Consolidated feedback, formal scope management, prompt milestone approvals, and a single point of contact are not complex skills. They are habits — and they are the habits that separate projects that work from projects that limp across the line over budget and past deadline.

The most important single change you can make: Appoint one person with decision-making authority and route all client-to-agency communication through them. This single change — more than any other — predicts whether a project will run smoothly or be derailed by internal misalignment.

---

Work With an Agency That Puts Quality First

Related Articles

Explore our more related articles