Why web projects fail: five mistakes from 14 years of agency practice

The pattern: a big vision meets a small, short-term budget. Because the conversation about it is uncomfortable, it gets postponed until it comes back as a budget overrun.

This is how it typically plays out: a machine builder wants a relaunch, a product configurator, a dealer portal and four languages. The budget visibly covers half of that, but nobody says so in the kickoff. In month three the question returns as an escalation, the configurator gets cut from scope, and the concept work already paid for it is lost. The conversation from week 1 was simply held later, at a higher price.

Open source sharpens the misunderstanding. Drupal costs no licence, so the project looks cheap. Implementation and customisation still cost money, and they are the largest part.

What helps: before the project starts, map every requested feature to a business goal and sort it into must-have or nice-to-have. If the wish list and the budget do not match, one of the two is adjusted before work begins. In agile projects, every sprint planning is the opportunity to keep checking this.

Without a single, empowered project owner on the client side, a committee decides. Committees deliver contradictory feedback on a weekly cadence, and every design question becomes a voting round.

The typical course: marketing, sales and management give separate feedback on the homepage draft, three rounds in three different directions. After six weeks, the same page is still in review. Only when management empowers one person does the decision fall within three days, and the rest of the project picks up that pace.

The problem is rarely a lack of competence among those involved, but the missing authority that resolves conflicting goals: sales wants leads, marketing wants brand, and one draft cannot maximise both at once.

What helps: one person with a mandate. They collect the stakeholders' opinions, but they decide. In our experience, projects with this role move through feedback cycles twice as fast as projects without it.

"We will deliver the copy later" is the most reliable single indicator of launch delays we know. Design and development are done, then everyone waits three months for content.

A typical example: a service provider's website was technically finished in spring, the launch happened in autumn. The departments were supposed to write their section copy "in between", alongside the day-to-day business, with no deadline and no owner. What solved it in the end was a combination of AI first drafts and a single approval round per department, with a fixed deadline. The same construction would have prevented the half-year delay from the start.

What helps: run content as its own workstream with its own owner and its own deadlines, in parallel with development. AI-assisted first drafts speed up that workstream considerably, but they do not replace the expert approval (this is how we work with it ourselves).

No single change is the problem. The problem is twenty small "while we are at it" requests that are never weighed against budget and schedule.

Typical course: an extra slider here, a special view for a landing page there, a "small" export feature for sales. Every wish is kindly agreed to on the call, none is assessed individually. At the end of the project, the effort sits roughly 30 percent above plan, and nobody can say exactly where it came from. After visible change prices were introduced in this project, the number of requests dropped on its own, because suddenly people prioritised.

What helps: every change gets a price in money or time, visible to both sides. That sounds bureaucratic and is the opposite: it makes decisions fast, because the costs are on the table.

Many projects budget up to go-live and not a day further. Then there is nobody for updates, content, analytics and further development. The website starts ageing from day one.

Here too, a typical pattern: a website runs untouched for two years after launch, security updates are postponed, content goes stale. Then a critical security release forces a rush job under time pressure that costs more than two years of regular maintenance combined. Meanwhile, the news page ends in the year of the launch, which every visitor can see.

What helps: plan operations from the start. Maintenance, content care and a quarterly budget for further development belong in the project budget, not in a later negotiation. As a rule of thumb from our support contracts: expect around ten to fifteen percent of the project sum per year for maintenance and moderate further development.

All five mistakes announce themselves early, usually before the first invoice is written. Take these signals seriously, whether you are the client or the agency:

Since AI agents started contributing to development, implementation times and implementation costs have dropped noticeably. That sounds like relief, but it does the opposite: the bottlenecks move entirely to the client side. When the agency delivers in days what used to take weeks, missing decisions (mistake 2) and missing content (mistake 3) become obvious immediately.

An example from one of our recent projects, as an order of magnitude from our own observation: the component library and around 40 page templates stood after a good two weeks, where we would previously have planned two to three months. What slowed us down was something else. We waited nine days for a single design decision, while implementing it afterwards took two. The content for ten pages only arrived after the technical work was done. So the total runtime was no longer determined by development, but by the waiting time for decisions and copy.

Our consequence: today we staff projects more around decision and content processes than around development capacity. And we address the five mistakes openly in the kickoff, because the higher pace has made their costs more visible, not smaller.

Before your next web project, check your own setup first. Five questions are enough:

• 1. Are budget and desired scope reconciled, with a must-have and a nice-to-have list?
• 2. Who is the one empowered person who decides?
• 3. Who delivers which content by when, and is that in the project plan with names and dates?
• 4. How do we handle change requests, and who sees their price?
• 5. Who operates, maintains and measures the website after launch, and with what budget?

With five solid answers, the project is half saved before it begins. Take the list into your next kickoff, or better: into the conversation before it.