Every business owner who's been through a serious website build, an infrastructure overhaul, or an AI integration project knows the feeling. The kickoff is energetic. The middle moves fast. There's a moment, maybe halfway through, where it really feels like you're going to ship on time.
And then it drags. Three months become five. Five become eight. The remaining 20% of the work seems to take 80% of the time, and nobody on either side can quite explain why.
This isn't bad luck. It isn't a bad agency, necessarily. It's a pattern — and once you see it, you can stop walking into it. Here's what's actually happening, and how to set up a project so it doesn't get stuck in the same place every time.
"Done" Was Never Actually Defined
Most project contracts list deliverables. Almost none list acceptance criteria. The agency thinks they're 90% there because every line item on the statement of work has been touched. The client thinks the project is half-finished because the experience doesn't yet match what's in their head.
Both sides are right. Neither side is wrong. They're just working from different definitions of "done," and nobody wrote one down at the start.
The fix is unglamorous: before any work begins, write down — in plain language — what the finished thing actually looks like. Not "responsive design" but "the homepage loads in under two seconds on a phone over 4G." Not "blog functionality" but "the marketing team can publish a post with a featured image and a category in under five minutes, without help from a developer." Specifics. Examples. Test cases.
If you can't describe what done looks like, you're not ready to start.
The Boring 20% Is Where the Unknowns Live
The first 80% of any web or infrastructure project is the visible stuff. The pages everyone wants to see. The dashboard the executives will demo to their board. The new design system. The shiny AI feature that prompted the whole project. It moves quickly because it's well-defined and everyone is excited about it.
The last 20% is the unglamorous work that nobody photographs and nobody puts in a case study. Edge cases. Form error states. Accessibility. Real performance under real traffic. Browser quirks. The 301 redirects from the old site so existing search rankings don't evaporate. Analytics wiring. Cookie banners. The staging-to-production handoff. The DNS cutover. The integration that worked perfectly in dev and falls over the first time it sees real customer data.
None of this is hard, individually. All of it takes time. And none of it can be skipped — at least not without paying for it later.
The fix is to plan the boring 20% from day one, not as a surprise at the end. Build it into the timeline. Build it into the budget. Treat it as a phase, not a cleanup.
Content Arrived Late, Or Never
If your project is stalled and the agency is sitting on lorem ipsum and stock photos, the build isn't actually behind. You are.
This is one of the most common reasons projects miss launch dates, and it's the one nobody wants to name out loud. The agency built the site. The client is supposed to deliver real copy, real product data, real photography, real bios — and it didn't show up. Or it showed up two months late. Or it showed up incomplete and needs another round.
The fix is to lock content delivery to project milestones from the kickoff. Real copy by week four. Final imagery by week six. Product data fully migrated by week eight. If those dates slip, the launch date slips, and everyone agrees in advance that's how it works. The worst version of this conversation is the one that happens at the end, after weeks of unclear blame.
Stakeholders Showed Up Late
There's a particular kind of stall that happens at week ten of a twelve-week project. The CMO who wasn't in a single review meeting suddenly has opinions about the navigation. The compliance team — who nobody thought to loop in — flags a privacy concern that requires structural changes. The CEO sees the staging site for the first time and decides the homepage doesn't feel like the brand.
These aren't bad-faith requests. They're often legitimate. But they arrive at the worst possible moment, when changes are most expensive and the timeline has the least slack.
The fix is to pull stakeholders in early — even the ones who don't seem like they should care. A thirty-minute review at week three is cheap. A request to restructure the site at week ten is not. If a senior person is going to weigh in eventually, it's better to find out what they think when there's still time to do something about it.
Scope Creep Wearing a "Small Ask" Disguise
Every late-stage request feels small in isolation. "Can we add a blog?" "Can we hook up Mailchimp?" "Can the contact form route differently based on inquiry type?" "Can we add a second language?" Any one of them could probably be absorbed. Together, they add a month — and the launch date never moves to reflect it.
The fix is to treat scope changes as actual changes, not favors. Each new request gets a number — hours, dollars, days added to the timeline. The client sees that number before approving. They can choose to add it. They can choose to defer it to a v2 phase. What they can't do is silently bolt it onto the existing scope and expect the original launch date to hold.
What This Looks Like When It Works
Projects that don't stall aren't projects with no surprises. They're projects where the surprises are absorbed gracefully because the structure was built to handle them.
Done is defined in writing. The unglamorous work is in the plan. Content has hard deadlines. Stakeholders are pulled in early. Scope changes are priced and dated.
None of this is exciting. All of it is the difference between a project that ships and a project that quietly slides into next quarter and then the one after that. The final 20% is where good partners separate themselves from average ones — not because they work harder at the end, but because they planned for the end at the beginning.
If your project feels stalled, the answer usually isn't "push through." The answer is to pause, look at which of the five patterns above you've fallen into, and address it directly. The 20% that's left isn't going to finish itself — and it's never going to be finished by working faster on the 80% that's already done.
