Your software project is going badly. Is it them, or is it you?
You are eight months into something that was quoted at five. It half works. Every conversation about the delay ends with a reason that is not quite anybody's fault. And you are now trying to decide whether changing supplier fixes this or simply costs you another eight months, while being unable to read a line of the code you have paid for.
Almost everything written on this subject comes from companies who would like to be your next supplier, so it is worth saying at the outset: sometimes the answer is that your supplier is competent and the problem is on your side of the table. That section is in here too. If you skip to it and recognise yourself, we have done you more good than a sales call would.
Why you cannot tell from where you are standing
The difficulty is not that you lack information. It is that every symptom you can see has at least two explanations, and the cause sits on the other side of a wall you cannot climb.
Late might be optimistic estimating. It might equally be the six things you asked for in month three that nobody re-quoted. Buggy might be careless engineering, or it might be the deadline you insisted on, met the only way it could be. Quiet might be a supplier avoiding you, or a supplier with their head down doing the work.
A struggling supplier knows this and will reach for the second explanation every time. What makes it genuinely hard is that they are sometimes right.
Four things that are their problem, whatever else is true
These do not require you to judge code quality, and no reasonable explanation covers them.
You cannot get at your own code. Not a question of who owns it, which is a contract matter. The question is whether you could hand another company access this afternoon. If the answer involves 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 other decision you make.
Nobody can tell you what is left. Not in days, necessarily, but in a list you understand. A supplier who knows where they are can describe what remains in plain terms. One who cannot is usually not concealing the answer. They do not have it.
The same fault keeps coming back. Once is a bug. Twice is bad luck. Three times means it is being patched where it shows rather than fixed where it breaks, and that pattern gets more expensive every month it continues.
You find out about problems yourself. When your staff or your customers tell you the system is down before your supplier does, that is not a technical failing, it is an absence of monitoring and an absence of the habit of telling you. Both are choices.
Three things that are usually yours
Worth reading before you make a decision, because changing supplier does not fix any of them and you will take all three with you.
The scope grew and nobody wrote it down. This is the commonest cause of a project that feels late without anyone being able to say why. Each addition was small and reasonable, none 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 waited on you. Development stops dead on questions only you can answer, and a week waiting for an answer is a week gone from a schedule that assumed a day. Suppliers are often bad at saying this clearly, so it accumulates silently and surfaces as lateness with no obvious cause.
You changed your mind about something fundamental. Legitimate, and sometimes the right call. But if the thing you changed was structural, the work already done on top of it was not wasted by the supplier, it was made obsolete by the decision. Those are different, and only one of them is grounds for leaving.
What you can check this week, without hiring anyone
Four questions. None need a technical answer from you, and all four can be asked of your current supplier in good faith. A supplier doing a good job will answer them within an afternoon and think nothing of it.
Where does the code live, and can I 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 me round? If exactly one person can explain how your system works, that is a fact about your risk regardless of whose fault it is, and it does not improve by waiting.
How does a change get from finished to live? You are not assessing the answer's sophistication. You are finding out whether there is one, and whether it depends on a particular person being available and calm.
What happens if it breaks on a Sunday? Who is told, how, and by whom. If the answer is that you would ring somebody's mobile and hope, you have found something worth fixing before you have found a culprit.
If the system is 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, and that time is real and you pay for it. Where the code is reachable and the thing runs, it is usually weeks rather than months. Where access has to be recovered the hard way, it is longer, which is why the first question above matters more than the rest.
What you keep is more than people expect: the code, the data, and the business rules inside them, which are the slow, expensive part and are not thrown away by a change of supplier. What you lose is the knowledge in the outgoing team's heads, and that loss is real but recoverable, because the code is the one description of the system that cannot be out of date.
The trap to avoid is the money already spent. It is gone whichever way you decide, and it is not an argument for staying. The only question worth asking is what the next amount buys, and from whom.
What we would tell you on the phone
We take on systems in this state regularly, and the first conversation is usually not about us. It is the four questions above, asked about your situation, and often the answers 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, and that remains the right advice more often than a company in our position finds comfortable.
When it is genuinely time to move, the work is well understood. Project rescue is a fixed-price assessment first, so you get a straight answer on what is salvageable before committing to anything larger. And if your supplier has stopped replying altogether rather than 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 yes. 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. A supplier refusing to help is an obstacle rather than a wall.
Should we tell them we are getting a second opinion?
A commercial judgement rather than a technical one, and it depends on whether you want the relationship to survive. Worth knowing that everything a second opinion needs first can be asked of your supplier directly and in good faith. A supplier 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 weeks is the most expensive mistake available. A system that half works still contains the business rules you paid to have worked out, and those are the slow part. The usual outcome is a takeover, a period of stabilising, and then a decision about modernising made calmly with the facts visible.
How do we avoid this happening with the next one?
Hold the accounts yourself, so the repository, hosting and domain are in your company's name and a supplier is given access rather than owning it. Describe work in outcomes you can check rather than tasks you cannot. And agree at the start what a monthly update contains, so silence becomes visible early rather than at the point it has become a crisis.