All help guides

What to Do When Your Software Agency Is Not Delivering

How an established business can separate normal project friction from a failing agency engagement and recover without creating more chaos.

Who this is for

Owners and operators paying an agency for a website, application, integration, or automation that keeps slipping, changing shape, or failing acceptance.

You need to protect business continuity and sunk work while making a fair, evidence-based decision. The answer is not automatically to fire the agency or tolerate another vague reset.

A drifting agency delivery path being reset through an evidence and acceptance gate.
Reset the engagement around one testable outcome. Evidence and access determine whether the work should continue—not another percentage-complete report.

The short answer

Replace status theater with a small acceptance test. Reconstruct the agreement, ask for a deployable snapshot and access, define one measurable milestone, then decide whether to continue, reduce scope, or transition.

What to do in the first hour

  1. 1.Collect the signed scope, change requests, invoices, timeline, demonstrations, acceptance criteria, and a list of every promised account or deliverable.
  2. 2.Write a one-page variance: what the business expected, what exists in a testable environment, what blocks use, and what decision is due next.
  3. 3.Ask for read access to the repository, project board, hosting, analytics, database schema, and current deployment. Access is not an accusation; it is basic buyer control.
  4. 4.Avoid adding new features while delivery is disputed. New scope makes accountability harder to establish.

Diagnose before you buy another solution

A late project is not necessarily a failed project. Look for working increments, candid risk disclosure, stable ownership, and an ability to demonstrate completed outcomes without a slide deck.

A failing engagement usually shows repeated re-estimation, demos that cannot be used, hidden dependencies, rotating staff, vague percentage-complete claims, and no reliable path from test to production.

Ask an independent technical reviewer to inspect a snapshot and compare it with the agreed outcomes. They should distinguish missing work, defective work, misunderstood scope, and buyer-side decisions that are genuinely blocking progress.

A practical recovery plan

01

Reset around one acceptance milestone

Choose one valuable end-to-end workflow: for example, a customer submits a request, staff receive it, the record appears in the CRM, and the customer gets confirmation. Define test data and pass/fail evidence. Give the agency a reasonable opportunity to demonstrate it.

02

Make ownership visible

Name one accountable person on each side. Record open decisions, blockers, owners, and dates in a shared log. Weekly reports should say what became usable, what failed, what changed, and what needs a decision—not how many hours were busy.

03

Secure a transition package

Before terminating, obtain the latest code, database/export, environment inventory, design files, credentials map, vendor contacts, deployment instructions, known issues, and license obligations. Verify that another professional can open the materials.

04

Choose continue, narrow, or exit

Continue if the agency can produce working increments and the economics still make sense. Narrow the scope if complexity is the main problem. Exit if control is withheld, evidence repeatedly conflicts with reports, or safety is being compromised.

05

Contract for outcomes next time

Use short milestones tied to demonstrable acceptance, company-owned accounts, repository access from day one, explicit change control, named senior ownership, and a handoff obligation. Retain enough payment to make completion and transition matter.

Questions to ask before approving more work

  • Show me the current deployable version and the exact workflow that passes today.
  • Which original outcomes are complete, partially complete, removed, or waiting on us?
  • What changed since the last estimate and what evidence supports the new one?
  • Can another qualified developer build and deploy from the company repository today?
  • What would a clean transition require if we decide not to continue?

Red flags

  • Source access is treated as a final-payment bargaining chip despite your contract granting ownership.
  • Every missed milestone creates a new discovery phase rather than a working increment.
  • Only the sales or account person can speak to the project; the technical owner is absent.
  • Production changes have no release record, backup, or rollback plan.
  • The agency pressures you to approve completion based only on a recorded demo.

When to bring in specialist help

Consult counsel before withholding contracted payments, using disputed intellectual property, or making public accusations. Bring in security specialists if privileged access cannot be accounted for or production data may be exposed.