The majority of web project disputes don’t start with bad work. They start with misaligned expectations that nobody bothered to surface and resolve before the project began. The client assumed revisions were unlimited. The agency assumed content would arrive in week one. The client expected to be consulted on every decision. The agency expected faster approvals. None of this is documented. All of it creates friction.
Setting realistic expectations with a web agency is mostly a pre-project exercise. The conversations that happen before you sign determine whether the project runs smoothly or becomes a source of ongoing conflict.
What “Expectations” Actually Means in a Web Project
Expectations cover more than timeline and budget. They cover:
- Scope: what specifically is being built, and what isn’t
- Process: how decisions get made, how feedback is handled, who approves what
- Communication: how often updates happen, through what channels, who the contacts are
- Client obligations: what you need to provide, when, and in what format
- Revisions: how many rounds are included, what happens if you need more
- Post-launch: what is supported, for how long, and at what cost
- Ownership: who owns the code, the accounts, the content
Most contracts cover budget and timeline. Fewer cover process, communication, and client obligations in meaningful detail. The gaps in those areas are where projects go wrong.
Your Own Clarity Is a Prerequisite
You can’t give an agency clear expectations if you don’t have them yourself. Before any agency conversation, know:
What problem are you solving? Not “we want a new website” — a new website is the solution. What is the problem? “Our current site doesn’t convert visitors from paid traffic, and we’re losing $4,000/month to that gap” is a problem. “We want something modern” is a preference. Problems are more useful than preferences because they give the agency something to measure against.
Who has final sign-off authority on your side? Projects slow down and go sideways when decision-making is distributed across three or four stakeholders with different opinions and no clear hierarchy. Name the person who has final approval before the project starts. Build your process around that person.
What does success look like at launch — and at six months post-launch? “We want a beautiful site” is not success criteria. “We want a site that converts at 3% or better from paid traffic and loads under 2 seconds on mobile” is. Without defined success criteria, any outcome can be rationalized as acceptable.
What’s the realistic content situation? Most businesses underestimate how much time content gathering takes. How many pages are you building? Who writes the copy — you or the agency? Do you have photography, or does that need to be sourced? Do you have logo files in vector format? Getting honest about your content situation before signing prevents the most common cause of project delays.
What to Establish With the Agency Before Signing
Communication cadence
How often will you hear from them? Through what channels? Who on the agency side is your primary contact, and is that person a project manager or the actual developer?
Weekly written status updates during active development is a reasonable standard. Monthly check-ins during lighter phases. An escalation contact for urgent issues. Get this in writing, not as a promise in a pitch meeting.
Revision definition
What counts as a revision? Most agencies include “reasonable revisions” in their scope — and “reasonable” is doing enormous work in that sentence. A revision should be defined as: changes within the agreed scope of each phase that don’t require new work or new functionality. Changes that add features or substantially alter the direction of a phase are change orders.
If the contract doesn’t define this, ask for a definition before signing.
Content deadline and consequence
If you’re providing content, when does it need to be delivered? What happens to the timeline if it’s late? “The timeline assumes content delivered by [specific date]. Delivery after that date will push the schedule by one week for each week of delay” is specific and fair. “Please send content when you can” is a setup for conflict.
What’s specifically out of scope
This is underused but valuable. A scope document that says what IS included is useful. A scope document that also says “not included: e-commerce functionality, live chat integration, multilingual content, custom account portals” is more useful. Explicit exclusions prevent the conversation where a client says “I thought that was included” and the agency says “that was never in scope.”
Post-launch support definition
What happens if something breaks in the two weeks after launch? Is there a support window? At what cost? Do you have a direct line to the developer for that period? Many agencies disappear after launch unless you’re on a retainer. Know this before you sign.
Imagine a spa whose new site launches with a beautiful design and a broken booking integration that nobody notices for a few days. If the contract has no defined post-launch support window, the owner gets routed to a support queue while online appointments stay down. That is why a post-launch support clause belongs in every agency contract.
How to Communicate During the Project
Even with clear expectations set upfront, projects require active communication management.
Write things down. Don’t give feedback verbally or by phone and expect it to be acted on accurately. Follow up every conversation with a written summary: “Per our call today, we agreed to X, Y, and Z. Please confirm.” This creates a record and forces clarity.
Give consolidated feedback. The most inefficient pattern in web project feedback is piecemeal delivery — sending twelve separate emails with one comment each. Collect all feedback on a design or build phase, consolidate it into a single document, and deliver it at once. This respects the agency’s workflow and speeds your project.
Be specific about what you dislike. “I don’t like the header” is not actionable. “The header feels too heavy — I’d like to explore a version with more whitespace between the logo and the navigation” is. The more specific your feedback, the less time is spent on revisions that miss what you actually meant.
Distinguish preferences from requirements. “I prefer a lighter color palette” is different from “the brand standards require we don’t use dark mode.” Agencies need to know which feedback is optional and which isn’t, or they treat all feedback as equally urgent — which slows everything down.
Say a client sends dozens of separate feedback comments on a design presentation over a few days, mixing style preferences with functional requirements with “just curious” questions. The agency then spends its time interpreting and prioritizing the feedback rather than building. A structured feedback template that separates required changes from preferred changes avoids that.
What Realistic Expectations Look Like for Common Project Types
Custom brochure site (6–15 pages): 6–10 week timeline with client content. Two to three design revision rounds. Weekly updates during development. Post-launch bug support window of 2–4 weeks.
Custom e-commerce site: 8–14 weeks with stable product catalog and content. More revision cycles expected — e-commerce builds have more functional decisions to make. Integration testing adds time. Post-launch monitoring period of 30 days is reasonable to ask for.
Site redesign: Timeline depends heavily on content decisions. If content is being rewritten simultaneously with design, add 3–4 weeks. URL mapping and redirect setup should be explicitly scoped as included.
The Agency’s Obligations in Expectation-Setting
This isn’t entirely on you. An agency that has built many sites knows where the risk points are, and they should surface them proactively.
An agency doing its job in the pre-project phase will tell you:
- “Content delivery is the most common source of delay on projects like yours — here’s what we need and when”
- “This feature you mentioned casually is actually a significant build — let’s make sure you want to scope it in”
- “Our revision process works like this — here’s what’s included and what would be an add-on”
If an agency isn’t raising any of these things before you sign, they either haven’t thought through the risks on your project, or they have and they’re choosing not to mention them because it might complicate the sale.
Our studio starts every engagement with a scoping conversation that is explicit and written. Every client knows what’s included, what’s excluded, and what happens in each phase before work begins. Talk to us to see how that works in practice, or explore custom WordPress development.
Frequently Asked Questions
How much detail should be in a web project contract? More than most standard contracts include. Scope, timeline, revision definition, client obligations, payment terms, post-launch support, and ownership should all be explicitly addressed. A four-page contract is suspicious for a $15,000 project — not because length equals quality, but because most four-page contracts leave important things to assumption.
What if the agency doesn’t want to commit to specific deliverables? That’s a red flag. Vague deliverables in a contract protect the agency, not you. “A fully functional website” is not a specific deliverable. “A 12-page WordPress website with the features listed in Attachment A, passing PageSpeed 85+ on mobile” is. Push for specificity or consider whether the agency is right for you.
How do I handle it when expectations aren’t being met mid-project? Address it directly and in writing. “The last two updates were two weeks late — I’d like to understand what’s causing the delays and get a revised schedule.” Frame it as a process conversation, not an accusation. If the agency responds defensively rather than with a concrete plan, that’s meaningful information about how the rest of the project will go.
Should I ask to see the project management tool or task board? Yes, if the agency uses one and is open to it. Visibility into a Trello board, Asana project, or equivalent gives you a real-time sense of progress without requiring constant status calls. Not every agency works this way, but transparency into process is a reasonable request.
What if I change my mind about something mid-project? Changes mid-project are inevitable and normal. The key is handling them through the agreed change order process rather than expecting them to be absorbed without impact. A change order should describe the addition, the time impact, and the cost impact. Agree to it in writing before work begins on the change.
Is it possible to set too many expectations upfront? Not really. More clarity is almost always better than less. The risk is being so rigid that the agency has no flexibility to make good judgment calls within the project. A balance: be very specific about outcomes and constraints, and give the agency latitude on the approach to achieving those outcomes.