Your software project is going badly. Is it them, or is it you?
You are eight months into something quoted at five. It half works. Every conversation about the delay ends with a reason that is not quite anybody's fault. Now you have to decide whether changing supplier fixes this or costs you another eight months, and you have to decide it without being able to read a line of the code you paid for.
Nearly everything written about this comes from companies who would like to be your next supplier. So here is the part they leave out: sometimes your supplier is competent and the problem is on your side of the table. That section is below. If you read it and recognise yourself, this page has done you more good than a sales call would.
Why you cannot tell from where you stand
The trouble is not that you lack information. It is that every symptom you can see has two explanations, and the cause sits behind a wall you cannot climb.
Late might be optimistic estimating. It might be the six things you asked for in month three that nobody re-quoted. Buggy might mean careless engineering, or it might mean the deadline you insisted on was met the only way it could be. Silence might be a supplier avoiding you, or a supplier with their head down.
A struggling supplier knows this and reaches for the second explanation every time. The hard part is that they are sometimes right.
Four things that are their problem, whatever else is true
None of these ask you to judge code quality, and no reasonable explanation covers them.
Start with access to your own code. Not who owns it, which is a contract question, but whether you could hand another company the keys this afternoon. If that means asking permission from the people you are unhappy with, you do not have a supplier problem yet. You have a hostage problem, and it will shape every decision that follows.
Next, what is left to do. Not a date, necessarily, but a list you can follow. A supplier who knows where they are can tell you what remains in plain language. One who cannot is usually not keeping it from you. They do not know either.
Then there is the fault that keeps returning. Once is a bug. Twice is bad luck. By the third time it is being patched where it shows instead of fixed where it breaks, and that gets more expensive every month it goes on.
Last, who tells you when something breaks. If your staff or your customers get there before your supplier does, nothing technical has failed. What is missing is monitoring and the habit of picking up the phone, and somebody chose both.
Three things that are usually yours
Read these before you decide anything, because changing supplier fixes none of them and you will carry all three to the next one.
Scope creep with no paper trail is the commonest reason a project feels late while nobody can say why. Each addition was small and sensible, none of them was re-quoted, and the original date stayed in everyone's head as though nothing had changed. If your supplier can produce a list of things you asked for after the quote, read it before you decide.
Decisions that waited on you are the second. Development stops dead on questions only you can answer, and a week waiting is a week gone from a plan that assumed a day. Suppliers are often poor at saying this out loud, so it builds up quietly and arrives later as lateness with no visible cause.
The third is changing your mind about something structural. Sometimes that is the right call. But if what you changed sat underneath everything else, the work built on top of it was not wasted by your supplier. It was made obsolete by your decision, and only one of those is grounds for leaving.
What you can check this week, without hiring anyone
Four questions. None of them need a technical answer from you, and all four can be put to your current supplier in good faith. One doing a good job will answer them in an afternoon and think nothing of it.
Where does the code live, and can you log in? Ask to be added to the repository as an owner. The answer tells you where you stand whatever else happens.
Can somebody who did not build it show you round? If exactly one person can explain how your system works, that is a fact about your exposure regardless of whose fault it is, and waiting does not improve it.
How does a change get from finished to live? You are not marking the answer for sophistication. You are finding out whether there is one, and whether it depends on a particular person being available and unflustered.
What happens if it breaks on a Sunday? Who gets told, how, and by whom. If the answer is that you would ring somebody's mobile and hope, you have found something to fix before you have found anyone to blame.
For a system more than a few years old, our legacy system health check asks ten questions in the same spirit and scores what comes back.
What changing actually costs
Anyone who tells you a takeover is free is selling. A new team has to learn a system somebody else designed, that time is real, and you pay for it. Where the code is reachable and the thing runs, it tends to be weeks. Where access has to be recovered the hard way it is longer, which is why the first of those four questions matters more than the other three.
You keep more than people expect. The code, the data, and the business rules inside them, which are the slow and expensive part and do not disappear when a supplier does. What you lose is whatever lives in the outgoing team's heads. That loss is real but recoverable, because the code is the one description of the system that cannot be out of date.
Watch out for the money already spent. It has gone whichever way you decide, and it is not an argument for staying. The only question that pays you anything is what the next amount buys, and from whom.
What we would tell you on the phone
We take on systems in this state often, and the first conversation is usually not about us. It is those four questions, asked about your situation, and the answers frequently point somewhere other than a change of supplier. Sometimes the fix is a monthly report that makes progress visible. Sometimes it is writing down the scope that grew. We have told people to stay where they are and renegotiate, which is better advice more often than a company in our position finds comfortable.
When it is time to move, the work is well understood. Project rescue starts with a fixed-price assessment, so you get a straight answer on what can be saved before committing to anything bigger. And if your supplier has stopped replying altogether instead of merely disappointing you, that is a different situation with a more urgent first week.
Common questions
Can a new company take over without our current supplier's cooperation?
Usually. What is needed is access to the running system and its hosting, and ideally the code, which for most web systems can be recovered from the server it runs on. Cooperation makes a takeover faster and cheaper, and most outgoing suppliers do cooperate, because a clean exit protects their reputation. One who refuses is an obstacle, not a wall.
Should we tell them we are getting a second opinion?
A commercial judgement more than a technical one, and it turns on whether you want the relationship to survive. Everything a second opinion needs first can be asked of your supplier directly and in good faith. One doing a good job answers those questions in an afternoon, and asking costs you nothing.
Will we have to start again from scratch?
Almost never, and deciding to rebuild in the first few weeks is the most expensive mistake available here. A system that half works still holds the business rules you paid to have worked out, and those are the slow part. The usual path is a takeover, a spell of stabilising, then a calm decision about modernising with the facts in front of you.
How do we avoid this happening with the next one?
Hold the accounts yourself, so the repository, the hosting and the domain are in your company's name and a supplier is given access instead of owning it. Describe work in outcomes you can check instead of tasks you cannot. And agree at the start what a monthly update contains, so silence shows up early instead of at the point it has become a crisis.