What are the first signs a web project is going off track?

In week three, watch for no merged pull requests beyond scaffolding, no visible UI in a staging URL, and daily stand-ups that report activity rather than completed user stories. The clearest signal is a backlog whose done items keep failing acceptance because the definition of done was never agreed.

What should actually be delivered by week three of a web project?

A runnable vertical slice or at least clickable wireframes connected to a data source, not design mockups alone. For a typical build, you should see a repository with regular commits, a staging environment, and a prioritised backlog where the first user journey is demonstrable end to end.

How many missed milestones mean a project is failing?

Two consecutive missed weekly milestones with no re-baselined plan is a strong warning. A single slip can be normal, but by week three the team should have replanned the remaining work. Verify with a burndown or cumulative flow chart showing whether scope is being added faster than it is completed.

What does scope creep look like in the first three weeks?

New pages, fields or integrations appear in each review without anything being removed or deferred. A practical check is the backlog growth rate: if open items increase while closed items stay flat, the project is expanding. Compare sprint scope changes in the project tracker, not in meeting notes.

How do you tell poor code quality is emerging by week three?

Look for large, unreviewed commits, no lint or test step in CI, and a build that only works on one developer's machine. Run git log with the stat option and check for files changed repeatedly. A missing or failing CI pipeline by week three means defects are being discovered by hand, which does not scale.

Is no staging environment by week three a warning sign?

Yes, for any project with a backend or CMS. Without a shared staging URL, every review depends on screenshots or someone's local machine, so integration bugs stay invisible. A minimal staging deploy often takes under a day; its absence suggests the deployment path itself has not been built or tested.

How do you verify a prototype actually meets requirements in week three?

Test the one agreed user journey against written acceptance criteria, not against the demo script. If the path fails on empty data, slow networks or a second user role, the prototype is a mock-up. Record each failure as a ticket and confirm the fix by re-running the same steps in staging.

What communication patterns signal a failing web project?

Status updates that replace decisions — we're making progress instead of this story is deployed — and questions asked twice because written decisions are not kept. A useful test is whether the last review's action items appear in the tracker with owners and dates. If not, accountability is already drifting.

When should you stop or pause a web project in week three?

Pause when the core assumption has changed — the target user, the integration, or the data model — and no replan has happened. Stopping means freezing new work, documenting what exists, and deciding whether to reset scope. It is cheaper than funding a build that is already heading in the wrong direction.

How do you recover a web project that is off track by week three?

Cut the scope to one end-to-end user journey, set a definition of done, and deploy whatever exists to staging that week. Then re-plan remaining work in small, demonstrable increments. Back up the repository and any environment configuration before restructuring branches or access. Verify recovery by a passing demo against written acceptance criteria.

Web Project Warning Signs: Catch Drift by Week Three

Signs a web project is going wrong in week three

Three weeks into a web build, the honest web project warning signs are usually visible: requirements still moving, no running build to click, design feedback loops with no decisions, and a team that has stopped asking hard questions. Catching them now costs a fraction of what week ten will — if you know what to look for.

Key Takeaways

Week three is when planning debt becomes visible; a project that still feels "almost ready to build" is often already behind.
The earliest web project warning signs are moving requirements, no staging link, and design reviews that reopen closed decisions.
Daily commit history and a clickable staging URL are the two most reliable "is this real?" checks you can run in a call.
Scope creep by week three is rarely the client's fault alone — it usually means requirements were never frozen in writing.
Fix cost rises steeply after week three; an afternoon of rework now can become two weeks of rework at week eight.
If you can count three or more warning signs, pause new feature talk and run the verification list in this article.
A short, uncomfortable review in week three is always cheaper than a rescue in week ten.

A healthy week-three checkpoint has five verifiable stages: frozen scope, signed wireframes, daily commits, passing tests and a scheduled demo.

What does "going wrong in week three" actually mean?

A project going wrong in week three rarely crashes. It drifts. The plan still sounds right, but the artefacts you would expect by now — approved screens, a staging URL, daily code commits — are thin or missing. Most web builds should have left planning and entered building by day 21. If they have not, budget is being spent on ambiguity instead of delivery.

Healthy week three has a shape. The requirements document is frozen, wireframes are signed, a developer is committing code most days, and there is a clickable build on a staging URL. When those things are absent, you are not looking at a slow start; you are looking at a project that has not actually begun the build. The gap between "still planning" and "quietly stuck" is where most failed web projects spend their final weeks.

The reason this matters commercially is that week three is still cheap to fix. A decision made now might cost an afternoon. The same decision at week eight can mean re-opening the data model, rebuilding two screens and re-testing everything. You are not just paying for the correction; you are paying for the wrong build first.

Why is week three the point where projects usually break?

Week three is where kickoff momentum meets the first real dependencies: content, API access, design sign-off, server credentials. Weeks one and two hide problems behind enthusiasm and "we're just setting up". By day 21, unanswered questions start blocking work, and the team either surfaces them or goes quiet. The break is rarely technical; it is almost always a decision bottleneck.

Every web project has a planning-to-build handoff. In week one, you write the brief. In week two, you approve wireframes and set up environments. By week three, code should be landing in the repository daily. If the repository is quiet, something upstream is blocked. Usually it is one of three things: nobody can sign off the design, the content is not ready, or the scope keeps shifting under the developer's feet.

A common mistake we see is treating week three as "still early". It is not. On a twelve-week build, week three is a quarter of the way through. Every day spent re-litigating the brief is a day the build is not happening. The projects that go wrong are rarely the ones with hard technical problems; they are the ones where decisions simply did not get made.

What are the concrete web project warning signs?

The most reliable web project warning signs are specific and measurable: requirements still being reinterpreted in every call, no clickable build by day 21, design reviews that reopen closed decisions, updates full of activity but no output, and one person holding the whole thread. Each is a signal you can check in a thirty-minute meeting, not a vague feeling.

Warning sign	What it looks like	What it usually means
Brief keeps changing	New pages, fields or flows appear in every call	Scope was never frozen; each change quietly extends the build
No staging link	"We're just finishing setup" for two weeks straight	Build may be blocked on setup, or it has not truly started
Design loops back	Same screen reviewed three times, no sign-off	No single decision-maker has the authority to close it
Only good news	"Productive week" but no artefacts to show	Risk is being hidden; nobody is surfacing blockers
Key person silent	The one person who knows the code or design stops replying	Single point of failure; there is no bus factor
Questions deflected	"Don't worry, we have it handled"	Risk is being managed away, not made visible

Individually, any one of these can be innocent. A single changed field is not scope creep. But when three or more signs appear together, you are no longer looking at normal early-stage noise. You are looking at a project where the build has not really started, the scope is not really fixed, and the risk is not really visible. That combination is how scope creep quietly turns a fixed build into an open-ended engagement.

The easiest one to check is the staging link. If you cannot click something by the end of week three, ask why. "We're finishing setup" is a reasonable answer in week one and a red flag in week three. Environment setup for a standard web build — a repository, a database, a deploy — is a day of work, not three weeks. If it is taking longer, the delay is probably not technical.

The common week-three warning signs mapped to the underlying problem each one usually hides.

When should you intervene, and when is it just early-stage noise?

Some week-three churn is normal: a logo tweak, a content reword, a small layout change. That is noise. Intervene when churn touches scope, data model, or sign-off authority, or when you have not seen a running build. The test is whether the change costs a conversation or a rebuild. Conversations are cheap; rebuilds are not.

The line is easier to draw than most people think. If a change fits inside the screens you have already approved, it is probably noise. If it adds a new page, a new user role, or a new integration, it is scope. The problem is not that scope changes; it is that scope changes without anyone updating the plan, the timeline or the budget. By week three, that unacknowledged drift is usually already visible in the requirements document — if one exists.

A practical rule: if you would not put the new request in writing and sign it, do not let it into the build. Verbal additions are how projects die quietly. Every "just one more small thing" is a line item someone is not tracking.

How do you verify a project is actually on track?

Verification in week three means asking for evidence, not reassurance. Ask for the staging URL and click it during the call. Open the repository and look at the last seven days of commits. Check whether the requirements document is frozen. List every open decision and name the person who can close it. Reassurance is not a deliverable.

Ask for the staging URL and open it while the team watches. A build you cannot click is not a build.
Open the Git history and look at the last seven days of commits. Activity without commits is planning, not building.
Check that the requirements document is frozen — no unapproved changes since kickoff.
List every open decision and name the single person who can close each one.
Ask "what is the riskiest thing right now?" and see whether you get a specific answer or a deflection.

git log --since="7 days ago" --oneline

That command is the bluntest health check there is. If the output is a handful of meaningful commits — "add login flow", "wire cart to API", "fix responsive nav" — the build is moving. If it is empty, or full of "update readme", the project is still in setup. You can read commit history through GitHub's documentation on repositories and activity if you are not used to looking at it.

Run this check with the team in the room, not as a surprise audit. The point is not to catch anyone out; it is to make the actual state visible so you can fix it together. Projects rarely fail because one person is bad at their job. They fail because the real state stays hidden until it is expensive.

What happens if you ignore the warning signs?

Ignoring week-three warning signs does not cause a loud crash. It causes a slow slide: week four becomes "we just need one more sprint", week six becomes a rescope, and week nine becomes a rebuild or a stalled project. You keep paying for activity while the actual deliverable drifts. By the time everyone can see it, the cheap fixes are gone.

The failure mode is compounding. An unresolved decision in week three blocks a developer in week four. The developer builds around the gap, which creates rework. The rework surfaces in week six as a screen that does not match the approved wireframe. Now you are paying to fix both the original gap and the workaround. This is how a twelve-week project becomes a nine-month one without anyone ever declaring a crisis.

The other cost is trust. When a client watches a project drift for weeks, they stop believing the next update. They start asking for daily reports, then they start withholding sign-off, then they start looking for another team. Changing developers mid-project is disruptive and expensive, and most of the time it could have been avoided with one hard conversation in week three. That is why we wrote what actually happens when you change web developers mid-project.

What does it cost to fix a project that went wrong?

The cost of fixing a drifting project is qualitative, not a fixed number: it is rework hours, the double cost of paying for the wrong build plus the correction, the delay to launch, and the risk that trust erodes. What matters is the ratio: a change in week three takes an afternoon; the same change at week eight can mean re-testing the whole application.

The fix cost of a drifting web project climbs steeply after week three as rework moves from a conversation to a rebuild.

The drivers are easy to list. Rework is the big one: every hour spent building the wrong thing is paid for twice, once to build it and once to remove it. Delay is the second: every week the project slips is a week the business is not getting the portal, the store, or the internal system it is already depending on. The third driver is harder to measure but often the most expensive: the loss of confidence that forces extra meetings, extra reports and eventually a change of team.

None of this needs a price tag to be actionable. You can see the cost curve in the timeline above: the same fix that is a conversation in week one is a rebuild by week six. The cheapest intervention is almost always the earliest one, which is why the real cost of a delayed web project is usually paid in rework, not in the delay itself.

Which common mistakes make week three worse?

The biggest mistakes are treating silence as progress, avoiding the uncomfortable call, approving "just a small addition" without updating the plan, and letting the loudest stakeholder keep changing the brief. Each one delays the moment the real problem gets named, and naming it is the only thing that starts the fix.

Silence is the most seductive one. A quiet week feels like nothing is wrong, but in a build phase, quiet usually means blocked. Developers do not stop committing code because everything is fine; they stop because they are waiting on a decision or building around a gap. If you have not heard a problem in two weeks, you are not being told the truth.

The fix for most of these is the same: a short, structured review with the actual builders in the room. Not the account lead, not the project manager — the person writing the code and the person signing the screens. Ask the five verification questions above, write down the answers, and do not leave until every open decision has an owner.

What does a drifted project actually look like in practice?

A business commissions a customer portal. Week one is a kickoff and a requirements document. Week two shows two screens and gets feedback: "make it more modern". By week three there is still no staging link, the developer says "setting up database and auth", and the requirements document has fourteen new items nobody signed. That is the drift pattern in one paragraph.

Nothing in that scenario is dramatic. No one has quit, nothing has crashed, no deadline has been missed — yet. But all five warning signs are present: moving requirements, no clickable build, design loops, activity without output, and a single developer holding the whole thread. If the business acts now, the fix is two days: freeze the scope, assign a sign-off owner, get a build running. If it waits until week eight, the fix is a rescope, a data model change and a rebuild of the screens that were already "approved".

This is the pattern behind most of the rescue work we are asked to review. The project was not bad; it was unmanaged. The brief was real, the team was competent, but nobody froze the scope and nobody demanded a running build by a date. By the time we are called in, the client has usually paid for several weeks of activity and has nothing clickable to show. That is preventable, and it starts with the breakdown you agreed at quote stage being treated as the contract, not a suggestion.

Should you fix, restart, or ride it out?

You have three real options when week three shows drift: fix the project in place, restart with a frozen scope, or ride it out and hope. Fixing in place works when the team is competent but unmanaged. Restarting works when the original brief no longer matches what you need. Riding it out works never.

Option	When it makes sense	Main risk
Fix in place	Team is skilled but decisions are not being made	Low — needs daily checkpoints
Restart with new scope	Original brief no longer matches the business need	Medium — lost time, but a clean slate
Ride it out	Never recommended	High — problems compound and trust erodes

Most week-three problems are fixable in place. You do not need a new team; you need a frozen scope, a named decision-maker and a daily checkpoint. A restart is rarer and more disruptive, but sometimes the original brief was written before the business understood what it actually needed — and no amount of polish fixes the wrong foundation. The one option to rule out immediately is riding it out. Hope is not a delivery strategy.

In short, the web project warning signs that matter by week three are all checkable: a frozen scope, signed wireframes, a running staging build and daily commits. If those artefacts are missing, do not wait for the crash. Freeze the scope, name a decision-maker and demand a clickable build within days. The fix is cheaper now than it will ever be again.

People also search for

If week three already looks like the scenario above, the cheapest next step is a short review of where the project actually stands. Our team can help you read the signals, freeze the scope and get the build onto a path you can verify. Contact us for a project health check, or see how we approach website redesigns when a build has drifted.

Frequently asked questions

In week three, watch for no merged pull requests beyond scaffolding, no visible UI in a staging URL, and daily stand-ups that report activity rather than completed user stories. The clearest signal is a backlog whose done items keep failing acceptance because the definition of done was never agreed.
A runnable vertical slice or at least clickable wireframes connected to a data source, not design mockups alone. For a typical build, you should see a repository with regular commits, a staging environment, and a prioritised backlog where the first user journey is demonstrable end to end.
Two consecutive missed weekly milestones with no re-baselined plan is a strong warning. A single slip can be normal, but by week three the team should have replanned the remaining work. Verify with a burndown or cumulative flow chart showing whether scope is being added faster than it is completed.
New pages, fields or integrations appear in each review without anything being removed or deferred. A practical check is the backlog growth rate: if open items increase while closed items stay flat, the project is expanding. Compare sprint scope changes in the project tracker, not in meeting notes.
Look for large, unreviewed commits, no lint or test step in CI, and a build that only works on one developer's machine. Run git log with the stat option and check for files changed repeatedly. A missing or failing CI pipeline by week three means defects are being discovered by hand, which does not scale.
Yes, for any project with a backend or CMS. Without a shared staging URL, every review depends on screenshots or someone's local machine, so integration bugs stay invisible. A minimal staging deploy often takes under a day; its absence suggests the deployment path itself has not been built or tested.
Test the one agreed user journey against written acceptance criteria, not against the demo script. If the path fails on empty data, slow networks or a second user role, the prototype is a mock-up. Record each failure as a ticket and confirm the fix by re-running the same steps in staging.
Status updates that replace decisions — we're making progress instead of this story is deployed — and questions asked twice because written decisions are not kept. A useful test is whether the last review's action items appear in the tracker with owners and dates. If not, accountability is already drifting.
Pause when the core assumption has changed — the target user, the integration, or the data model — and no replan has happened. Stopping means freezing new work, documenting what exists, and deciding whether to reset scope. It is cheaper than funding a build that is already heading in the wrong direction.
Cut the scope to one end-to-end user journey, set a definition of done, and deploy whatever exists to staging that week. Then re-plan remaining work in small, demonstrable increments. Back up the repository and any environment configuration before restructuring branches or access. Verify recovery by a passing demo against written acceptance criteria.