7 signs your development agency is going to disappoint you
Large IT projects run 45% over budget and deliver 56% less value. The warning signs show up in the first month. Seven of them, and what to do about each.
In this piece
Six weeks into a build, a founder asks for a link. The agency sends a slide: three green bars, one amber, a note that integration work is 80% complete. There is no deployed environment. There has not been one since kickoff. The project is not failing yet. It is already going to.
That gap, between what a buyer is told and what a buyer can open in a browser, is where software money disappears. Research by McKinsey and the University of Oxford across more than 5,400 IT projects found that large IT projects run 45% over budget, 7% over schedule, and deliver 56% less value than predicted, with cost overruns growing about 15% for every additional year a project runs (McKinsey, 2012). Those numbers are the end state. The signals arrive in the first month, and reading them takes no technical background.
Here are seven. Each has a boring, innocent explanation, so one sign is noise. Three at once is a pattern.
1. The people who pitched are not the people building
The senior engineer who answered every architecture question on the sales call has been silent for three weeks. Standups carry new names. When you ask why a decision was made in week two, nobody in the room was there.
This is structural rather than dishonest. The people who are good at scoping are scarce, so they get rotated across pitches. The cost lands on you anyway: velocity drops, the same questions get re-asked, and decisions made before the handover become folklore.
Ask for: the names of everyone who will touch the code, their seniority, and the written notice period before a swap. An agency that cannot answer in one email does not have the team assembled yet.
Innocent explanation: parental leave, illness, a contract that ended. Then ask to see the handover document. If it exists, this is not a sign.
2. You get status, never artifacts
Percentages, RAG colours, a burndown chart. No URL, no commit history, no defect list. "80% done" is a claim, not a measurement, and it is the easiest thing in the world to say for four weeks in a row.
A team that cannot show running software by the end of week two is either not building it or not letting you look. Both are your problem.
Ask for: a deployed environment every week from week two, in whatever state it is in. Broken and ugly is fine. Absent is not. Add the commit log and the open defect count.
Innocent explanation: the first fortnight was genuinely infrastructure, auth, and CI. Then week three produces a link.
3. The estimate arrived before the questions
A full price and a timeline landed within 48 hours of a single call. Nobody asked about your existing data, your compliance obligations, your integration list, or who signs off on a release.
PMI attributes 47% of unsuccessful projects to inaccurate requirements management (PMI, Pulse of the Profession). Requirements do not disappear because nobody gathered them. They surface later as change orders, at the moment you have the least leverage.
Ask for: a written list of what the quote excludes and what assumptions it rests on. A vendor who has thought about your project can produce that in a page. See our note on what a discovery phase should actually deliver.
Innocent explanation: the scope really is small and they have shipped the same thing eleven times. Then the exclusions list will be short and specific.
4. Throughput is climbing and stability is not
Pull requests merge quickly. The bug list is longer every Friday. The same regression came back twice.
DORA's 2025 report on AI-assisted software development, built on nearly 5,000 survey responses, found that higher AI adoption correlates with greater software delivery instability even as individual output rises (DORA, 2025). Code now gets generated faster than review and deployment practice can absorb it. In 2026, a partner shipping too fast to stay correct is a more common failure than a partner shipping too slowly.
Ask for: change failure rate and time to restore service, not story points. Two numbers, monthly, in an email.
Innocent explanation: a hard migration week. Then the defect curve flattens by the following sprint, and somebody predicted it in advance.
5. You find out about scope from the invoice
Scope changing is normal. PMI's survey data puts scope creep at roughly 41% of projects in a given year (PMI). The sign is not that scope moved. It is where you learned about it.
When the first time a change gets priced is on a bill, there is no change control process, and the incentive points away from you: every ambiguity in the brief converts into revenue.
Ask for: a written change process, agreed before it is needed, with rates and an approval threshold under which small things just happen. Our breakdown of SOW and MSA structure covers where this clause belongs.
Innocent explanation: a production emergency that could not wait for a signature. Then it happened once, and somebody called you.
6. Nobody ever says no
Every request gets a yes. No trade-off is named. No sequencing argument is made. Nobody has told you that a feature will cost more than it returns.
A delivery partner with no opinions is either not thinking about your product or planning to bill for the consequences of not thinking about it. The most valuable sentence an agency says is "we would not build that yet, and here is why".
Test it: ask for something expensive and slightly foolish. A native mobile app in month two. A custom analytics pipeline before you have users. See whether anyone pushes back, and how fast.
Innocent explanation: your requests have been reasonable and well sequenced. The test settles it in a day.
7. You cannot see the repository
The code lives in their organisation. Access is coming. The contract lists deliverables but never says who owns the source, and there is no escrow clause.
This one works differently from the other six. It does not predict disappointment. It decides what disappointment costs. Every other problem on this list is recoverable if you hold the code and the deployment credentials. None of them are if you do not.
Ask for: the repository in your organisation from the first commit, with the agency added as collaborators, plus your own cloud accounts. An agency that objects should be able to explain why in one sentence. Our list of contract clauses worth checking goes through the wording.
Innocent explanation: a shared template repo in the first days, migrated to your org at kickoff. Ask for the date.
What to do once you have counted three
The expensive move is the silent restart: hoping the next sprint fixes it while the clock runs. Duration is the variable that compounds cost, and every month you wait makes the overrun worse rather than better.
- Write down what you observed, with dates and no adjectives. "Week 3, 5 and 7: asked for a deployed URL, received a status slide." Facts travel. Frustration does not.
- Send it, and ask for a written response within five working days. How they respond is itself the next data point.
- Agree a two-week corrective window with one demonstrable deliverable. A working environment. The named team back on the call. A change log. Something you can open, not something you can be told.
- If the window closes empty, use the exit clause. Take the repository, the credentials, the documentation, and the backlog. Then run a handover review before you hire the replacement.
How to prevent all seven before you sign
Four items in the paperwork remove most of this risk, and none of them are unusual to ask for.
- Named key personnel in the SOW, with a written notice period before anyone is swapped off your account.
- A deployed environment as a payment milestone inside the first two weeks. This single clause kills sign 2 and most of sign 4.
- Repository and cloud accounts in your organisation from the first commit.
- A written change control process with rates, agreed before the first change request exists.
If you are still at the brief stage, most of this is cheaper to fix upstream: see how to brief a development agency and the mistakes founders make when hiring.
We sit on the other side of this table, and that is the point. These are the questions we expect a buyer to ask, and the ones we would ask if we were the ones buying. Not one of them requires you to read code. They require you to insist that a claim about progress arrives attached to something you can open.
Sources
Frequently asked questions
How soon should a development agency show me working software?+
By the end of the second week, in almost every case. The first fortnight can legitimately go on infrastructure, authentication and deployment pipelines, but that work ends with a deployed environment you can open, even if the only thing in it is a login screen. After week two, ask for a link every week. Make the first deployed environment a payment milestone in the contract, which turns a request into an obligation. Percentage-complete reporting with no environment behind it is the single most reliable early warning in this list.
Is it normal for an agency to change the developers on my project?+
Some rotation is normal over a long engagement. People leave, take parental leave, or move between accounts as workloads shift. What is not normal is finding out after the fact, or discovering that the senior who scoped the work never intended to build it. The fix is contractual rather than confrontational: name key personnel in the statement of work, agree a notice period of five to ten working days before anyone is swapped, and require a written handover document. If an agency resists naming people, it usually means the team is not staffed yet and will be assembled from whoever is free at kickoff.
What if the agency will not give me access to the code?+
Treat it as urgent, not as a formality. Without the repository and the deployment credentials you cannot get a second opinion, cannot hire a replacement without a rebuild, and cannot verify any claim about progress. Ask in writing, citing the intellectual property clause in your contract. If the contract is silent on ownership, that gap is the real problem and a lawyer should look at it before the next payment goes out. Going forward, put the repository in your own organisation from the first commit and add the agency as collaborators. It costs nothing at the start and is close to impossible to retrofit during a dispute.
Can I change agency mid-project without losing the work?+
Yes, if you own three things: the repository, the cloud accounts, and enough documentation for a new team to run the project locally. With those, a competent replacement usually needs two to four weeks to become productive, and most of that time goes on reading rather than rewriting. Without them, you are commissioning a rebuild and paying twice. Before you switch, budget for a paid handover period with the outgoing team and write down every undocumented decision while people are still willing to answer. The handover is worth more than the last invoice you are tempted to withhold.
Related services
Studio
Start a project.
We write about what we build. Tell us what you want to build.