Red flags when evaluating a software development partner

01You cannot meet the engineers

The single strongest predictor. If a vendor will not let you interview the specific people who will write your code, there is usually a reason: the team is not assigned yet, the people in the room are pre-sales staff who will disappear after signature, or the model is bench-and-swap, where whoever is free gets allocated.

The legitimate version of this objection is that staffing depends on start date, which is fair. The test is whether they will commit to you interviewing and approving the assigned engineers before work begins, and to naming them in the contract. A confident firm agrees readily.

02Testing, CI or code review are priced as extras

When automated testing appears as a separately priced line item, it tells you the default mode of working does not include it. That is not a commercial choice, it is an engineering culture, and you will inherit the consequences in the codebase long after the discount has been forgotten.

The same applies to continuous integration, code review and documentation. These are not features. They are how software gets built without accumulating a maintenance liability. A vendor treating them as optional is quoting you a lower number for a worse asset.

• Testing quoted separately, or described as 'available if required'.
• No CI pipeline in their standard setup.
• Code review presented as a premium practice.
• Documentation offered as a distinct phase at the end.

03Resistance to client-owned repositories and cloud accounts

There is no good engineering reason for a vendor to insist on owning your git repository or your cloud accounts. The reasons offered - internal tooling, security policy, standardised environments - are usually genuine operational preferences, but they consistently produce a situation where leaving is expensive.

Insist on client-owned infrastructure from the first commit. A vendor working inside your repositories and your cloud accounts has full ability to deliver and no ability to hold delivery hostage. Confident firms find this completely unremarkable, and the reaction to the request is itself informative.

04The estimate arrives too fast and too confidently

A firm quoting a precise figure for a substantial build after one conversation is not estimating, it is anchoring. Real estimation requires understanding the existing system, the integration surface and the non-functional requirements, none of which fit in a discovery call.

What you want to hear is a range, the assumptions behind it, and a proposal to reduce uncertainty through paid discovery. That is not evasion - it is what competent estimation sounds like. The confident single number is more comfortable and much more likely to be renegotiated later.

• A fixed price for an ill-defined scope, offered quickly.
• No stated assumptions attached to the number.
• Unwillingness to discuss what would cause the estimate to move.
• Change-request rates far above the base rate - a sign the model expects disputes.

05Softer signals worth weighting

These are individually weak and collectively meaningful. Any one might be circumstantial; three or four together describe a firm you should not sign with.

• Agreeing with every element of your proposed approach.
• Unable to describe an engagement that went badly.
• Case studies with impressive percentages and no verifiable specifics.
• Pressure to sign quickly, or discounts that expire.
• Vague answers on sub-contracting - find out if your work will be passed on.
• No clear answer on what handover and exit look like.