7 Signs Your Technical Partner Will Fail Delivery

Most companies don't choose the wrong technical partner because they weren't careful. They choose the wrong one because the signs of failure are almost never visible in the proposal.

They appear in the first weeks of the project, when changing direction is already costly and the relationship is already complicated.

I've spent 15 years on both sides of this. Leading engineering teams, managing technical partnerships, building products from zero. The patterns are consistent. None of them are hidden. They are visible before you sign, if you know what to look for.

These are the seven I've seen most often.

The first conversation with a technical partner should involve more questions than answers. If a vendor spends the majority of an introductory call explaining their capabilities and process rather than asking about your actual problem, that is the first signal.

A good technical partner is trying to understand whether they can actually help you, not whether they can sell you. Those are different motivations, and they produce different behaviours. One asks: "What does this process look like today when it breaks?" The other says: "We've built over 200 projects in this space."

The specific questions a partner asks in the first two conversations reveal their real orientation. Are they asking about your existing systems, your team's technical capacity, your definition of a successful outcome? Or are they primarily interested in scope and timeline so they can put together a number?

Enthusiasm is not a red flag. But enthusiasm without curiosity usually means the vendor has already decided what they're going to build before they understand what you actually need. That is how projects end up technically complete and commercially useless.

A proposal that comes back with a single, clean number ("€45,000, twelve weeks") with no dependencies, no caveats, and no explanation of what would need to be true for that estimate to hold, is not a confident estimate. It is a guess packaged as certainty.

Honest technical estimates sound different. They sound like: "Based on what we understand today, this is between ten and fourteen weeks, and here are the three factors that would push it towards the longer end." That kind of estimate is harder to sell. It also has a significantly better chance of being accurate.

The reason clean estimates persist is that clients often reward them. A confident single number feels more reassuring in a proposal than a range with conditions. So vendors learn to present what wins proposals rather than what reflects reality. Research from the Harvard Business Review on project management consistently shows that large technology projects run over time and budget precisely because initial estimates were made without adequate understanding of scope and complexity.

When evaluating proposals, ask the vendor to walk you through the assumptions behind their estimate. Ask specifically: what would have to be true for this to come in at the lower end? What are the risks that push it higher? How they answer that question tells you more about their process than the number itself.

Most software projects don't happen in isolation. There are existing systems, databases, APIs, internal tools, and workflows that the new solution will need to connect to, replace, or work alongside. A vendor who doesn't ask about those systems in the early stages of scoping hasn't thought about integration, or is hoping you haven't either.

Integration is where most technical projects become complicated. It's where hidden dependencies surface, where timelines expand, and where architectural decisions made early become expensive to reverse. A vendor who jumps straight to building the new thing without mapping what it needs to connect to is optimising for starting, not for finishing.

This is a recurring problem in custom software development projects across sectors: a new system gets built in isolation and then can't connect to the client's existing tools, or data migration wasn't scoped because nobody asked what the existing data actually looked like.

The question to ask any prospective technical partner before signing is simple: "What do you need to understand about our current systems before you can scope this accurately?" If they already have everything they need at the proposal stage, without having asked, they are either very lucky or not thinking carefully about the actual work.

Testimonials are easy to collect. Portfolio pages with screenshots of interfaces look impressive. What is harder to produce, and therefore much more meaningful, is a case study that describes the problem, the technical approach, the trade-offs made, and the measurable outcome.

"We helped this company improve their operations" is not a case study. "Manual reconciliation dropped from thirty hours per week to four, after building a structured integration between three core systems, and here's why we chose that architecture over the alternatives" is a case study.

The specificity of how a vendor talks about past work reveals how they think about current work. If they can't explain the reasoning behind past decisions, they are unlikely to explain their reasoning to you during your project. And if they can't point to real metrics, even approximate ones with appropriate anonymisation, it may be because the outcomes weren't worth measuring.

How to test this before signing: ask the vendor to walk you through one project they're particularly proud of. Not a testimonial, a conversation. Ask them: what was the original brief, and how did it change during the project? What was the hardest technical decision, and why did you make it that way? What would you do differently if you did it again? What did the client do differently after the project was delivered?

A vendor with genuine experience of delivering outcomes answers these questions with specificity and without hesitation. They remember the project because it was real, because they were accountable for it, and because they learned something from it. A vendor who has delivered code but not outcomes will give you vague answers about client satisfaction and smooth delivery. The difference between those two conversations is significant, and it is visible before you sign.

This doesn't mean every vendor needs a full published case study for every project. But it does mean they should be able to have a substantive conversation about a project they're proud of: what the challenge was, how they approached it, what didn't work, and what the client was able to do differently afterwards.

Fixed-scope contracts with no mechanism for managing change are a structural mismatch with the reality of software development. Requirements evolve. Integrations reveal complexity that wasn't visible during scoping. Priorities shift as the project progresses and the client understands more clearly what they're building.

A contract that doesn't acknowledge this reality isn't protecting the client. It is setting up a negotiation about every change request, which is where trust erodes and projects slow down. The Standish Group's CHAOS Report, which has tracked software project outcomes for decades, consistently identifies scope creep and unclear requirements as among the top causes of project failure. Fixed-scope contracts don't prevent scope creep. They just make it more expensive to manage when it happens.

What I look for instead is a contract that defines a clear process for scope changes: how they are identified, how they are priced, and how decisions get made. That kind of contract acknowledges reality without giving either party unlimited flexibility. It also signals that the vendor has been through enough projects to know that the brief at the start of a project is never exactly the brief at the end.

How to detect this before signing: ask the vendor directly how they handled a scope change in a recent project. Not hypothetically. In a real project. What triggered the change, how it was communicated, how it was priced, and whether the client was surprised by the outcome. If they can't give a specific answer, or if the answer suggests the client was caught off guard, that tells you how your scope changes will be handled too.

A vendor who has a clear, rehearsed answer to this question has built a process around it. A vendor who hasn't thought about it hasn't been through enough projects to have learned the lesson, or has learned it and chosen not to address it.

This is worth asking about explicitly before signing. How do you handle scope changes? What's the process if we need to adjust direction mid-project? The answer reveals how the vendor thinks about the relationship, whether they see it as a transaction or as a working partnership.

If a vendor agrees with everything you propose, one of two things is true: either your brief is unusually well-formed and your assumptions are all correct, or the vendor is optimising for getting the contract rather than for helping you. The first possibility exists. The second is more common.

Good technical partners push back. Not on everything, and not combatively, but on the things that matter. They tell you when your timeline isn't realistic. They raise concerns about architectural decisions that will create problems later. They ask uncomfortable questions about assumptions you've made. They occasionally recommend a simpler solution than the one you've described, even when that means a smaller engagement.

This kind of pushback is uncomfortable in the short term. It is also what distinguishes a vendor who is accountable for outcomes from one who is accountable only for delivery. Accountability after go-live, not just at handover, is one of the things I think about most when evaluating how we work at Unlocking Tech. A McKinsey study on technology project delivery found that the vendors who produce the best outcomes are those who remain engaged and accountable beyond the delivery milestone, treating the relationship as ongoing rather than transactional.

If you reach the end of a discovery process and the vendor has agreed with everything you've said, ask them directly: what are the three biggest risks in this project? If they can't answer, or if their answer is vague, that's the signal.

The speed of a proposal is inversely correlated with its accuracy. A proposal that arrives the day after an initial conversation, fully scoped and priced, was written before that conversation ended. It reflects assumptions the vendor made before they understood your problem, which means it is, at best, a rough approximation and, at worst, a number designed to win the business rather than deliver the work.

Proper scoping takes time. It requires conversations with the people who will use the system, an understanding of the existing technical environment, and clarity on what success looks like and how it will be measured. A vendor who does all of that in twenty-four hours either has unusual capacity for rapid understanding or hasn't actually done it.

How to detect this before signing: look at what the proposal contains, not just what it costs. A proposal produced without discovery will be heavy on process descriptions and light on specifics about your situation. It will describe the vendor's methodology in detail and say relatively little about your particular constraints, your existing systems, or the risks specific to your project. It will read like a template with your name inserted, because that is what it is.

A proposal produced after genuine discovery looks different. It references specific conversations. It names the constraints that were identified. It explains why certain decisions were made given your particular situation. It may even say: "Based on what we learned, we'd recommend a different approach than the one you initially described, and here's why." That kind of proposal takes longer to produce. It is also significantly more likely to reflect what the project will actually require.

The question worth asking any vendor who sends a fast proposal: "What would change about this proposal if we spent two more hours mapping our existing systems and defining what success looks like?" If the answer is "nothing," the proposal wasn't built on understanding your situation. If the answer involves real specifics, the discovery conversation is worth having before you sign.

This is why we introduced a mandatory technical discovery process before any proposal at Unlocking Tech. Discovery doesn't have to be long. But it has to happen. A vendor who isn't willing to invest time in understanding your problem before proposing a solution isn't the right partner for solving it.

None of these signals require specialist technical knowledge to spot. They are visible in how a vendor communicates, what questions they ask, how they structure their proposals, and what they're willing to say when they disagree with you.

The vendors worth working with ask more than they answer in early conversations. Their estimates come with ranges and dependencies. They ask about your existing systems before they propose new ones. They can talk about past projects with the specificity of people who were accountable for the outcomes. Their contracts acknowledge reality. They push back on things that matter. And they take enough time to understand your problem before telling you what it will cost to solve it.

These are not high standards. They are the minimum conditions for a relationship where both sides are genuinely trying to produce a good outcome.

If you're about to evaluate a technical partner, or if you're midway through a project and something doesn't feel right, the most useful thing you can do is ask the uncomfortable questions directly. Good partners answer them clearly. The ones who don't have already told you what you need to know.

If you'd like a second opinion on a technical brief, a proposal you've received, or a project that's not going the way it should, schedule a diagnostic conversation with our team. The first conversation is always about understanding your situation. No decks, no pitches, no proposal until we've done the work to understand the problem.

Talk to us about your project