Why Your Last Development Agency Failed You - And How to Not Repeat It

A founder told us last year that he had spent a significant sum and eight months with an agency, and had nothing he could use. He said it the way people do when they are half-expecting to be judged for it.

He should not have been. This happens constantly, to capable people, and most of the reasons are structural rather than a failure of judgement on the buyer's side.

If it has happened to you, the useful question is not who was at fault. It is which specific mechanism broke, so that choosing a software development agency next time is a decision made with better instruments.

Here are the five causes we see most, and what to demand instead.

1. Nobody agreed what "done" meant

The most common cause, and the most preventable.

The proposal said "user management module." You pictured something with roles, permissions, an invitation flow, and an audit trail. They pictured a login screen and a users table. Both readings are defensible. Neither was written down.

Three months later you are looking at something that technically matches the proposal and does not remotely match your expectation, and the conversation becomes a negotiation about words rather than about software.

What to demand instead: acceptance criteria per feature, written before work begins, in plain language describing what a user can do when it is finished. Not technical specifications — behaviour. "An administrator can invite a colleague by email, choose their role, and revoke access later." Short, concrete, and checkable by someone non-technical. The user story format is a perfectly good template for this, and its main virtue is that it forces the conversation to be about outcomes rather than components.

If a prospective partner resists writing these, that resistance is the entire signal. Good teams find them clarifying, because ambiguity costs them too.

2. The senior people you met were never coming

You had two excellent conversations with a thoughtful technical lead. You signed. That person appeared briefly at kickoff and was never seen again, and your project ran with people considerably more junior.

This is a known pattern with a known name in the industry, and it is why the earlier conversations felt so much better than the project did.

To be fair: junior engineers with proper supervision produce good software, and no agency staffs every project with its most senior people. The problem is not seniority. It is the mismatch between what you were shown and what you received.

What to demand instead: named individuals in the contract, with their role and the percentage of their time committed. A clause requiring notice and approval before substitution. And a technical conversation, before signing, with the person who will actually lead the work — not the one who closes the deal.

3. Nothing was ever written down about how it works

You received a repository. Inside is code, no documentation, no architecture notes, no record of why anything was built the way it was.

Now every new developer who touches it has to reconstruct the reasoning from scratch, and every estimate they give you is inflated to cover the risk of what they do not understand. That is a permanent tax you will pay for the life of the system.

The deeper problem is that undocumented systems are often undocumented deliberately. A system only the original team understands is a system you cannot leave.

What to demand instead: documentation as a deliverable with its own acceptance, not a promise. Specifically: how to run it locally, how it deploys, what the main components do, what external services it depends on, and what decisions were made and why. A short document per area is enough. Ask for it incrementally rather than at the end, because documentation promised at the end is documentation that does not exist.

4. You never saw anything running

Status was reported as progress percentages, or as screenshots, or as a demo on their machine that you could not touch.

Every one of those can be true and still hide a project in trouble. A feature can be ninety percent complete for two months. A screenshot shows a screen, not a working system.

What to demand instead: a deployed environment, at a URL you can open, updated at least every two weeks, where you can use the thing yourself. This one requirement prevents more disasters than anything else on this list, because it makes drift visible early and it is very difficult to fake.

If a partner cannot give you a running environment within the first month, ask what is preventing it. The answer is genuinely informative.

This is not merely a client-comfort measure. The research collected in the DORA State of DevOps programme has consistently found that teams which deploy frequently and in small increments also produce more reliable software. A partner who cannot deploy to somewhere you can see is usually a partner who is not deploying often at all, and that tends to correlate with everything else.

If you are in the middle of one of these right now

If you recognise your current project here, the position is usually more recoverable than it feels — but the sooner you look at it honestly, the more options remain.

If you want an independent read on where a project actually stands, we are happy to assess it and tell you plainly whether it is salvageable, what it would take, and whether continuing with your current partner is the right call. Sometimes it is.

5. There was no exit plan, because that was the point

The relationship ended, or you wanted it to, and then you discovered how hard leaving was. Code in their repository. Infrastructure in their cloud account. The domain registered to them. Design files nobody could locate. No handover documentation.

Some of this is deliberate. Much of it is simply the accumulated result of nobody insisting otherwise at the start, when it would have cost nothing.

What to demand instead: own everything from day one. Your repository, your cloud accounts, your domain, your design files, your third-party services, with the agency granted access rather than holding it. Write a defined handover into the contract at the outset — what gets delivered, in what form, over how many days. Negotiating an exit while you still like each other is straightforward. Negotiating one afterwards is not.

The pattern underneath all five

Read them together and one thing connects them: each is a place where a specific, cheap, up-front agreement was skipped, and the cost appeared months later.

None of the five are technical problems. They are all contractual and procedural, which means they are all within your control as a buyer, even without technical knowledge. That is the encouraging part.

It is also worth saying that agencies are not uniquely prone to this. In-house teams produce undocumented systems and key-person dependency too. The difference is that an agency relationship ends, and endings expose everything that was never agreed.

What to do before you sign again

A short list, all of which cost nothing during negotiation and a great deal afterwards:

• Acceptance criteria per feature, in plain language, before work starts
• Named people in the contract, with approval required for substitution
• Your accounts, your repository, your domain, from day one
• A running environment you can open, updated at least fortnightly
• Documentation as a deliverable, produced incrementally
• A written handover process, agreed at the start
• A paid trial period on real work before committing to the full engagement

That last one deserves emphasis. Two weeks of actual paid work tells you more than every reference and portfolio combined, and almost nobody does it. It is the closest thing to a guarantee available in this market.

Deciding whether to recover or restart

If you are sitting on a half-finished project from a relationship that ended, there is one more decision to make, and it is worth making deliberately rather than emotionally.

The instinct after a bad experience is to throw everything away and start clean. Sometimes that is right. Often it is expensive grief.

What we look at when assessing these: can the application be run locally by someone new within a day, does the data model make sense even if the code around it does not, and is there any part that clearly works and is well-separated. If two of those three are true, recovery is usually cheaper than a restart, even when the code is unpleasant.

What tips it toward starting again: no ability to build or deploy it at all, a data model that does not match the business, or a dependency on a platform that is no longer supported. Those are structural, and polishing around them does not help.

Get the assessment from someone with no stake in the answer. A partner who will earn more from a rebuild is not the right person to tell you whether you need one.

Trust is built in the first month, not promised in the proposal

The uncomfortable truth about choosing a software development agency is that proposals are a poor signal. Everyone's deck is good. Everyone's portfolio shows successful work. Everyone says the right things about communication and quality.

What actually differentiates is observable within a month: do they write things down, do they show you working software, do they push back when your scope is unclear, and do they hand you the keys without being asked.

You do not need to be technical to check any of those. You just need to know to look — which, after one bad experience, you now do. That is the one genuine benefit of a project that went wrong, and it is worth quite a lot going forward.

If you are starting again after a difficult experience and want a partner who will put the boring protections in writing before anything else, book a free consultation call or email nitheesh@playxoft.com. Bring the list above. We are happy to be held to it.