Problems & fixes · Web and design agencies
Why website projects run over budget and behind schedule
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Most overruns come from unclear scope, late content, too many decision makers and untested assumptions about integrations, not from slow developers. Prevent them by fixing scope in writing, assigning content owners, naming one approver, testing hard technical risks early and agreeing how changes are handled. Expect some change, and plan a contingency rather than treating it as failure.
Who this is for: A client mid-project or planning one who wants to understand the common causes of delay and cost growth and how to prevent them.
What to evaluate
Scope clarity
Vague terms like a simple shop or a few pages hide big differences in effort. Disagreements about what was included are the biggest source of disputes.
How to check: Compare the proposal against a page and feature list, and ask the agency to state exclusions explicitly.
Content readiness
Missing copy, images and product data stop the build and push the launch date. Final content is often the longest task.
How to check: Create a content inventory with owners and dates before design approval.
Decision making
Feedback from many stakeholders, especially after approval, causes rework and conflicting direction.
How to check: Name one decision maker and a consolidated feedback process with deadlines.
Technical unknowns
Integrations with payment, inventory, booking or customer systems often hide complexity that appears only during build.
How to check: Ask the agency to prototype or investigate the riskiest integration at the start.
Change control
Small requests accumulate. Without a process, they erode both timeline and goodwill.
How to check: Agree how change requests are estimated, approved and recorded.
Testing and launch planning
Late testing on real devices and with real data reveals problems when time is shortest, such as redirects, forms and analytics.
How to check: Request a test plan and a launch checklist covering redirects, tracking and rollback.
Comparison
| Cause | Early warning sign | Prevention |
|---|---|---|
| Unclear scope | Proposal uses broad words and few exclusions | Written feature list with acceptance criteria |
| Late content | No content owner named at kickoff | Content plan and deadlines tied to milestones |
| Stakeholder conflict | Different people give opposite feedback | Single approver and consolidated review rounds |
| Integration surprises | Third-party systems not yet accessed | Early technical spike and test accounts |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Scope clarity | |||
| Content readiness | |||
| Decision making | |||
| Technical unknowns | |||
| Change control | |||
| Testing and launch planning | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- What is explicitly out of scope in this proposal?
- How is a change request estimated and approved?
- Which tasks depend on us and what are their deadlines?
- Which integrations are riskiest and when will you test them?
- How many review rounds are included for each stage?
- What does acceptance mean and how do we confirm it?
- Who handles redirects and search visibility when we launch?
- What contingency is built into the schedule?
Typical trade-offs
Fixed price and fixed scope
- Upside
- Predictable budget and clear commitments
- Downside
- Rigid when learning shows that priorities should change
Phased delivery
- Upside
- Early release of core features and lower risk
- Downside
- Possible rework when later phases touch earlier work
Large contingency buffer
- Upside
- Protects both parties from surprise
- Downside
- Can be tempting to consume and requires honest tracking
Common mistakes
- Approving designs without having the real content, then finding that the layout does not accommodate it.
- Allowing every stakeholder to send feedback independently instead of consolidating it.
- Treating the agency's estimate as a promise when your own tasks are late.
- Leaving integration and migration testing to the final week before launch.
- Ignoring redirects from the old site, causing lost search visibility and broken links.
Related questions
Is going over budget normal for website projects?
Some variance is common, usually because scope evolved or dependencies were underestimated. It is not inevitable. Projects with explicit scope, early technical investigation and disciplined change control tend to land closer to plan. Discuss a contingency allowance at the outset and agree how it is used. If an agency suggests no change will ever occur, treat that as a warning sign rather than reassurance, because learning during design and build almost always affects something.
What should I do when the project is already late?
Pause to diagnose rather than add pressure. List outstanding tasks and who owns each, separating agency delays from client delays. Re-confirm priorities and consider launching a smaller core scope first, with later phases following. Ask for a revised plan with dated milestones and be ready to supply content or decisions promptly. Keep records of agreed changes so that any discussion about cost is based on documented facts.
Who is responsible when delays come from missing content?
Typically the party that was meant to supply the content, which is usually the client. Good proposals state this and tie milestones to content delivery, sometimes with provisions for rescheduling the team if materials arrive late. Check your contract for such clauses. Avoid conflict by agreeing a content calendar early and having someone in your organisation accountable for it, with authority to chase colleagues.
How can I verify progress without technical knowledge?
Ask for regular working demonstrations on a staging site rather than status reports alone. Review against the agreed feature list and acceptance criteria, and test on a phone and a desktop yourself. Ask which of the agreed features are complete against the list, not for general impressions. A reputable agency will welcome visible progress and show tickets or task boards so you can follow the work.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Planning and managing web accessibility — W3C Web Accessibility Initiative, retrieved 27 October 2026
- Google Search documentation — Google, retrieved 27 October 2026
Related guides
How to choose · Web and design agencies
How to choose a web design agency for a business website
Pick an agency by matching its process and evidence to your actual goals, not by the look of its showcase. Ask to see projects with a similar business model, find out who will do the work, and check how it handles content, accessibility, search visibility and handover. A clear discovery phase, written scope and ownership of your files matter more than visual flair.
Alternatives · Web and design agencies
Web agency, freelancer or website builder: which route fits
The right route depends on complexity, internal capacity and how often the site will change. Website builders suit simple sites run by the owner. Freelancers suit well-defined, bounded work with a few specialisms. Agencies suit multi-discipline projects with integrations, stakeholders and ongoing development. Compare total effort, continuity risk and flexibility, not only the build cost.
Requirements · Web and design agencies
What a website project brief must contain before you approach agencies
A useful brief states business goals, audience, core features, content responsibilities, existing systems, constraints, timeline and how decisions will be made. It does not need to prescribe design. The aim is to let agencies see the real problem so they quote against the same scope and ask intelligent questions.
Requirements · Consulting
How to scope a consulting engagement properly
A sound scope states the decision or outcome the work supports, the specific deliverables and acceptance tests, the team and time commitments, your responsibilities, assumptions, exclusions, change control and payment triggers. Spend your effort on the exclusions and assumptions, because those are where scope disputes begin.
Problems & fixes · Artificial intelligence
Shadow AI: staff using unapproved tools and what to do about it
Shadow AI arises when approved options are slow, limited or unknown. Prohibition alone seldom works. Combine discovery, a clear policy with examples, an approved alternative that meets real needs, a quick exception route, technical guardrails on sensitive data and training that explains reasons. Treat discovery as information about unmet needs rather than only a disciplinary matter.
Requirements · Outsourcing
Outsourcing contracts and service levels: what to require
A robust outsourcing agreement defines the scope in measurable terms, sets service levels tied to business outcomes, links remedies to performance, protects data and audit rights, manages change and subcontracting, and plans the exit. Service levels fail when they measure what is easy rather than what matters or when remedies are too small to influence behaviour.
Cost factors · Legal services
How lawyers charge: fee structures explained
Lawyers commonly bill by time, by fixed fee for defined work, on a contingent basis tied to outcome in some jurisdictions, or through retainers and subscriptions. The structure shifts risk: time-based billing places uncertainty on you, fixed fees place it on the lawyer. What matters is a written scope, what counts as extra, and how disbursements and third-party costs are handled.
All Web and design agencies guides · All Professional services