What to Do When Your Development Agency Ran Over Budget and Didn't Finish

Incomplete agency projects fail in a consistent pattern: the data model and core logic are largely built, and the integration and production-readiness layer is not. That pattern determines what recovery costs, and it is usually a better starting position than the status reports suggest.

The structural cause

Agency delivery separates the senior expertise sold during scoping from the people writing the code, and the resulting information loss compounds over the engagement.

Work routes through a project manager, a lead developer, one or more junior developers doing most of the implementation, and a QA pass at the end. The senior architect appeared during the sales process and at occasional reviews. The developers building the system are frequently newer, allocated across several accounts, and encountering the requirements for the first time.

This is the economics of the model rather than negligence, and its consequences are predictable:

• Ambiguous requirements resolved by whoever was implementing them that week, without escalation
• Edge cases missed because the developer building a feature did not know how it would be used
• Decisions surfacing only after they are built in, because the communication layer is a project manager who was not in the technical conversation
• Foundational architecture decided in month two by someone who has since rotated off the account

What the codebase contains

The recurring finding: further along than it feels, less complete than reported.

"Feature complete" in agency reporting generally means the happy path works in a demo environment. It does not establish that error handling exists, that edge cases are handled, that performance holds under production load, or that the deployment process is documented. The work that converts a demo into a production system is roughly half the total effort and is frequently absent from the original estimate.

Completion is distributed unevenly, in a predictable shape:

• Most complete: data model, core domain logic, primary user interface screens
• Partially complete: validation, error handling, administrative functions
• Least complete: third-party integrations, payment processing, reporting, authentication and authorization edge cases, deployment automation, monitoring

The concentration at integration points has a cause. Integrations require coordination with an external party, they surface problems that need decisions, and they are the work most easily deferred when a schedule is under pressure.

Institutional context is gone. The developer who built the payment integration is on another account. The project manager who understood the requirements is on the next engagement. What remains is the code, a ticket backlog of uncertain accuracy, and less documentation than expected.

The assessment, before any commitment

An independent read of the codebase precedes any estimate to finish. The final agency status report is not that read.

The assessment produces five specific outputs:

• What genuinely works, verified by running it against real data rather than by reading tickets
• What is partially built, with a percentage and a statement of what remains for each item
• What has not been started, reconciled against the original scope
• Which architectural decisions are sound and which must be reversed, with the cost of reversal for each
• A component-level salvage recommendation: what to keep, what to rebuild

Expect one to two weeks. The output is a scoped remaining-work list, a defensible estimate, and the list of structural issues to resolve before additional code is written on top.

Most of the time, most of it is salvageable. The typical situation is not that nothing was built. It is that the foundation was built and the budget ran out before the integration and delivery layer.

Why a single senior developer changes the economics

Replacing an agency with one experienced developer rather than another agency changes two variables: context retention and decision latency.

• One person holds the full system context. Decisions and implementation happen the same day, with no handoff and no requirement translation.
• Ramp-up is one person's ramp-up. Onboarding a team onto an unfamiliar, partially complete codebase costs more than onboarding an individual, and produces a shallower understanding per person.
• Accountability has one address. There is no interval during which the answer to what went wrong is being assembled.

This matters most in the phase that remains, because the remaining work is the hardest work: components tightly coupled to early decisions, integrations that require understanding the entire system, and edge cases that require judgment about intended behavior. That is the work least suited to distribution across junior developers, and it is exactly what was left.

The recovery structure

Two phases, with a decision point between them.

Stabilization. Understand the codebase, produce the assessment above, and resolve the architectural problems that would undermine delivery. Ends with a fixed-scope estimate rather than with code.

Delivery. Fixed scope, defined milestones, a deployable product at completion. The objective is a production system serving the core requirements that the internal team can maintain, not the fully realized version of the original vision. Scope discipline here is what prevents a second budget from ending the same way.

The two weeks spent understanding the codebase before writing additional code is the difference between finishing and arriving back at this position with a second budget spent.