Your development agency isn't working out. What now?

Deadlines have moved twice. You are not sure what was delivered last month. Questions get answered slowly and in a way that does not quite answer them. You are wondering whether this is a rough patch or a failing engagement.

Most of this is recoverable. One thing is not, so it goes first.

Before you say anything: secure the accounts

Do this today, before raising any concern. Not because anyone is likely to act badly, but because the cost of being wrong is enormous and the cost of checking is an hour.

1. Confirm you own the code repository. Not that you have access to it — that the organisation or account is in your name and you can remove other people from it.
2. Confirm you own the cloud and hosting accounts. Billing in your name, root credentials you hold. If infrastructure sits inside the agency's account, this is the single most urgent thing on the list.
3. Confirm you own the domain registration, the DNS, and any third-party service — payments, email, analytics — created for your product.
4. Take a complete backup, including a database dump, and verify it restores somewhere else. An untested backup is a belief.
5. Write down what you do not have. Credentials held only by them, undocumented deployment steps, services registered to their email addresses.

Is it actually failing?

Separate the symptoms that mean something from the ones that feel bad but are normal. Software projects are genuinely uncertain, and a late week is not a failure.

The right-hand column shares a theme: you cannot see the state of your own project. That is the thing that matters, far more than any individual missed date. If you cannot open a URL and use what you are paying for, no explanation substitutes.

The conversation worth having first

Switching is expensive. A direct conversation is cheap, and a surprising share of failing engagements are a process problem rather than a competence problem. Ask for three specific things:

• Working software on a live URL, weekly. Not screenshots, not a demo call. Something you can open yourself. Most relationships that recover, recover here.
• A written list of what remains, with dates. Vagueness about the remaining work is the strongest predictor that nobody knows.
• The name of whoever is actually writing the code, and whether that has changed since you started. It frequently has, and that often explains everything else.

Give it two or three weeks. If those three things do not materialise, you have your answer, and you have it with evidence rather than a feeling.

If you are switching, get an audit before you commit

The instinct is to find a new agency and ask them to carry on. The better first step is a short, paid, independent assessment of what actually exists — commissioned from someone who is not bidding to do the rebuild.

You want to know: does it run, what is genuinely finished, what is the state of the data model, is there anything dangerous, and how much of it is worth keeping. Our audit work is exactly this, and inheriting a codebase nobody documented describes what the process involves.

This matters commercially, not just technically. Without it, you are choosing between two claims: the outgoing agency's "it is nearly done" and the incoming agency's "this all has to be rebuilt". Both are self-interested. An assessment that is neither gives you the only number you can plan with.

Leaving without losing the work

1. Check the contract for notice and IP terms before giving notice, including anything tying payment to a final handover.
2. Settle what is genuinely owed. A disputed final invoice is the usual reason handovers turn difficult, and the leverage is rarely worth it.
3. Ask for a written handover: how to run it locally, how it deploys, where everything lives, what is half-finished and what is known to be broken.
4. Get an hour of recorded walkthrough with whoever wrote the code. This is worth more than any document and is easy to ask for while the relationship is still civil.
5. Rotate every credential once the handover is complete. Not an accusation — ordinary practice, and the step people skip.
6. Keep the relationship intact. The industry is small, you may need a question answered in three months, and nothing is gained by the alternative.

Choosing the next one, differently

Whatever went wrong is now information. Three things are worth making explicit in the next arrangement:

• Your name on everything from the first commit. Repository, cloud, domain, third-party services. This is non-negotiable and costs nothing.
• Working software weekly, on a URL you can open. The single best early-warning system there is.
• The named engineers, and whether they can be swapped without your agreement. Being handed to a different team mid-project explains a large share of engagements that quietly stop working.

The questions to ask before you sign covers the rest of that conversation, and how to choose a software development company covers comparing the candidates.

What we do

We pick up other people's projects regularly, and the first thing we do is tell you honestly what is there — including when the answer is that it is in better shape than you feared and needs finishing rather than replacing. That outcome is more common than the alternative, and we would rather say it than sell a rebuild.

If a rebuild genuinely is the answer, rebuild or refactor sets out how that decision should be made.

Frequently asked questions