The launch was planned for the first of the month. Two weeks before, your agency says they need "a few more weeks." You agree. On the new date, they need a few more. Now you have a sales demo booked, an investor update to write, and no idea whether the product is three weeks or three months away.
The short answer: a single slip is normal and tells you little. What matters is why it slipped, whether the agency saw it coming, and whether the new date is built from evidence or hope. Diagnose the cause before you react. Pushing harder, adding people, or firing the agency each fix a different problem, and choosing the wrong one makes the slip worse.
One slip is not the problem. The pattern is.
Software estimates are uncertain, and every honest engineer knows it. A project that lands within a couple of weeks of a three-month plan is a well-run project. What should worry you is not lateness itself but these patterns:
- Late surprise. The slip was announced days before the deadline, not weeks. Either the agency did not know where it stood, or it did not tell you.
- Repeated small slips. Each new date moves by "just two weeks." This usually means the agency is re-estimating only the next step instead of the whole remaining scope.
- No new information. The explanation is vague: "more complex than expected," with no specifics about what.
- Shrinking demos. Fewer working things shown each week, more slides and status updates. Our post on agency status report theater covers this signal.
If you see two or more of these, you do not have a scheduling problem. You have a visibility problem.
The four usual causes
Scope grew and nobody repriced it
The most common cause, and often partly yours. Small requests in weekly calls, a "quick" extra screen, a changed workflow after a customer conversation. Each is reasonable. Together they add weeks. If that is what happened, the fix is to freeze scope for the launch, list everything added since the plan, and decide what moves to after launch. Our post on agency change orders explains how to keep this visible.
"Done" was never defined
The agency thinks a feature is done when the code is written. You think it is done when it works for a real user on real data. The gap between those two is where weeks disappear. Write acceptance criteria for what remains. See agency acceptance criteria for a format that works.
A real technical surprise
Sometimes something genuinely hard turned up: a third-party API that does not behave as documented, a performance problem with real data, a security requirement nobody planned for. This is legitimate. The test is whether the agency can explain it specifically and show a credible plan, not just more time.
Staffing changed
The senior developer moved to another client, and someone newer took over. Ask directly who is on your project this week compared with the start. If the team changed and you were not told, that is a trust issue as much as a schedule issue.
What to do this week
Ask for a full re-estimate, not a new date. Every remaining item, with an estimate and a confidence level. A new date without that breakdown is a guess.
Cut scope to protect the date that matters. If the demo or launch is fixed, decide what can ship without. Usually it is more than you think. Teams rarely regret launching a smaller product on time.
Shorten the feedback loop. Move to a working demo every week, on a staging environment you can use yourself. Visible progress is the best early warning system you have.
Do not add people. Adding developers to a late project usually slows it down at first, because the existing team has to onboard them. Our post on adding engineers to a late project explains why.
When the slip means it is time to change agencies
Firing an agency mid-build is expensive and slow, so it should be a decision, not a reaction. It is worth serious consideration when the agency cannot produce a credible re-estimate, when slips keep arriving as late surprises after you have asked for earlier warning, or when the code itself turns out to be in poor shape. If you reach that point, do it in a deliberate order. Our guide on firing a dev agency mid-build covers the sequence, starting with securing your code and accounts.
Where outside judgment helps
The hardest part for a non-technical founder is telling a legitimate technical surprise from a team that is lost. Both sound the same in a status call. A fractional CTO can read the repository, sit in on one planning session, and tell you within days whether the new date is real. See pricing for how short engagements work, or book a call before you agree to the next new date.
Frequently asked questions
Is it normal for a software agency to miss a deadline?
A modest slip is normal, because software estimates are uncertain. Repeated slips, late surprises, and vague explanations are not normal and point to problems with scope control, visibility, or the team.
Should I add more developers to catch up?
Usually not. New people need onboarding from the existing team, which tends to slow a late project in the short term. Cutting scope is almost always faster.
How do I know if the new date is realistic?
Ask for a re-estimate of every remaining item with confidence levels, and compare it with what the agency has actually delivered per week so far. If the new plan assumes they will suddenly move much faster, it is not realistic.
When should I fire an agency for missing deadlines?
When they cannot give a credible re-estimate, keep surprising you late after you asked for early warning, or the code quality is poor. Secure your code and accounts before you act.