My app project is over budget and behind schedule — what should I do?
Your app build is over budget and late. A non-technical founder's triage: stop the bleeding, diagnose the cause, and decide whether to rescue or rebuild.
First stabilize, then diagnose, then decide — in that order. Freeze scope, secure the source code and the Apple and Google accounts, and tie further payments to verifiable milestones. Only after an honest technical read of what exists should you choose to continue with the current team, rescope, or replace them. Most failed rescues fail because the owner reversed that order and acted on frustration.
Why do app projects go over budget and late?
Most overruns come from unclear scope, shifting requirements, and weak oversight, not slow coding. The Standish Group's CHAOS research attributes the majority of software failures to requirements and management, not technical skill. When a non-technical owner cannot referee scope, small changes compound quietly until the timeline and budget are both gone.
The usual pattern is undramatic. A feature is added here, a design is changed there, an integration turns out harder than the vendor assumed, and nobody holds the line on scope. Because the owner cannot judge what is reasonable, each change sounds small. Standish has long reported that large projects run over budget far more often than small ones, which is why tight scope and staged milestones matter most exactly when a build is struggling.
What should you do first when a build is failing?
Stabilize before anything else: freeze new scope, secure your source code, repository, and Apple and Google developer accounts, and move remaining payments to milestone releases. These three actions stop further loss, protect your assets, and preserve every option — without escalating into a fight you are not yet ready to have.
- Freeze scope. No new features until the situation is understood; new scope on a failing build accelerates the bleed.
- Secure assets. Confirm you hold the code repository, the Apple and Google accounts, and any TestFlight and infrastructure access.
- Gate payments. Release money only against a working, demonstrable milestone from here forward.
Should you fix the current build or start over?
Fix when the architecture is sound and the code is recoverable; rebuild only when the foundation is fundamentally broken. That judgment requires a technical assessment of the existing code, not frustration. Rebuilding feels clean and decisive, but it discards recoverable work and restarts the clock, so it should be the evidence-based choice, never the emotional one.
| Situation | Lean toward rescue | Lean toward rebuild |
|---|---|---|
| Architecture | Sound, extensible | Fundamentally wrong |
| Code quality | Readable, testable | Undocumented, fragile |
| Progress | Most features usable | Little works end to end |
| Team | Capable, mismanaged scope | Out of their depth |
| Cost to finish | Less than restarting | More than a clean build |
Beware the sunk-cost reflex in both directions: neither "we have spent too much to stop" nor "throw it all away" is a strategy. The recoverable value sits in the existing code and the team's knowledge, and only an independent technical review can price it honestly against the cost of starting fresh.
How do you handle the vendor without making it worse?
Handle the vendor calmly and in writing: document current status, ask for a realistic plan to a defined milestone, and keep the relationship intact until you have an independent assessment. Firing a team before diagnosis can forfeit months of context and code. Many builds recover once scope is frozen and priorities are set, with the same people finishing the job.
An adversarial move too early is expensive. If the problem was scope and oversight rather than competence, a new vendor inherits the same unclear requirements and repeats the failure, now from a cold start. The productive posture is firm but not hostile: get a written status and plan, secure your assets, and bring in a neutral advisor who can tell you whether the team can realistically deliver.
How do you prevent the next overrun?
Prevent the next overrun by fixing scope and sequence up front, staging payments against milestones, and getting the plan reviewed before work resumes. The same discipline that rescues a failing build prevents the next one: a clear roadmap, verifiable milestones, and an independent set of eyes on the decisions a non-technical owner cannot referee alone.
Whether you continue, rescope, or restart, the fix is the same shape. A short, fixed-scope Mobile Product Roadmap re-establishes what to build, in what order, and against which milestones, so the money you spend from here forward buys progress instead of more delay.
Key Takeaways
- Stabilize, diagnose, then decide — reversing that order is how an overrun becomes a total loss.
- First moves: freeze scope, secure code and store accounts, and switch to milestone payments.
- Most overruns trace to unclear scope and weak oversight, not slow coding, per Standish CHAOS research.
- Fix a recoverable build; rebuild only when the architecture is fundamentally broken, judged by assessment not frustration.
- Do not fire the vendor before an independent diagnosis; scope fixes often let the same team finish.
- A clear roadmap with verifiable milestones both rescues the current build and prevents the next overrun.
FAQ
- Should I fire my app developer if the project is late?
- Not before you diagnose the cause. Firing a vendor mid-build can lose months and knowledge if the problem was unclear scope, not competence. First secure code and accounts, get an independent assessment, then decide. Sometimes the same team finishes fine once scope and priorities are fixed.
- Is it cheaper to fix the current build or start over?
- Usually fixing is cheaper if the architecture is sound and the code is recoverable; rebuilding wins only when the foundation is fundamentally broken. The honest answer needs a technical assessment of the existing code. Deciding on frustration alone, without that review, is how founders pay twice.
- Why do app projects go over budget so often?
- Most overruns come from unclear scope, changing requirements, and weak oversight rather than slow coding. The Standish Group's CHAOS research links the majority of failures to requirements and management issues. When a non-technical owner cannot referee scope, small changes compound into large delays and cost.
- How do I stop an app project from bleeding money right now?
- Freeze new scope, secure your source code, repository, and Apple and Google accounts, and switch payments to verifiable milestones. These three moves stop further loss without escalating conflict, and they preserve your options while you get an independent read on whether to continue, rescope, or replace the team.
Giacomo Balli is an independent mobile product advisor in San Francisco who has stepped into stalled and over-budget builds across many industries. He helps non-technical owners stabilize a failing project and decide, with evidence, whether to rescue or rebuild.
Disclosure: Giacomo Balli provides independent advisory services and does not resell development work, take equity, or earn vendor commissions. Guidance is general and not a substitute for a project-specific assessment.