Red Flags When Hiring External Development Teams

Most external development engagements that fail were diagnosable before the contract was signed. The evidence is in four places: how the team handles risk during scoping, what questions they ask, how the estimate is qualified, and whether the people presenting will be the people building.

Unqualified agreement during scoping

A vendor who agrees with every requirement, timeline, and assumption is selling rather than assessing.

Anyone with genuine experience in the domain can name two or three things that will need clarification before an estimate is reliable, and one or two that commonly go wrong. Naming them is not a weak sales position; it is the evidence that the work has been evaluated. A vendor who names none has either not analyzed the project or has decided the analysis would cost them the deal.

What a substantive response sounds like: identification of a specific integration as the likely schedule risk, a question about which of two conflicting requirements takes precedence, or a statement that a portion of the estimate is unreliable until a specific unknown is resolved.

Scoping and delivery staffed separately

Agencies with a strong pre-sale function and a distinct delivery organization are structurally arranged to separate the conversation from the execution.

The consequence is specific: the architect who ran discovery has moved to the next opportunity before work starts, and the constraints they identified reach the delivery team as documentation rather than as context. Rejected approaches get proposed again. Unwritten constraints are discovered during implementation.

The test is direct. Ask to speak with the engineers who will do the work before signing. A firm that cannot arrange that, or that offers a delivery lead who will not be hands-on, has told you how the engagement will run.

Estimate quality

A well-constructed estimate states its assumptions, and the presence of that structure is more informative than the number.

What should be present:

• Explicit assumptions about environment, access, data quality, and dependencies
• Separation of understood work from discovery work, with the discovery portion identified as a range rather than a point
• Named risks with their schedule impact if they materialize
• What information was unavailable at estimating time and how it would change the number

A confident single figure with none of these qualifications was constructed to win the engagement. It will be revised, and the revision will arrive as a change order after the work has started.

The questions they ask

The scoping questions are a direct measure of relevant experience. Teams that have delivered this kind of work ask about the operational reality, not just the requirements.

Questions that indicate experience:

• What the deployment process is, and who can execute it
• What test coverage exists
• Why the previous attempt failed, if there was one
• Who has authority to decide scope questions, and how fast
• What the data looks like in production, as opposed to in the schema
• What other systems consume the outputs

A team that accepts a requirements document and returns a price has either not done this or does not believe the questions improve their odds. Both are informative.

Engagement structure and exit

Two structural questions should be resolved before signing, because both determine cost after problems appear.

Escalation and dispute resolution. Establish what happens when the delivered work does not match the intent. If the path runs through a project manager mediating between client and engineers, every misalignment carries days of latency. On complex work, the speed at which a specification gap is surfaced and resolved is the dominant factor in whether the outcome matches the intent.

The end state. Ask what the engagement looks like at completion and what the internal team requires to maintain the result. A defensible answer includes a documentation deliverable, a knowledge transfer period, and the client owning the repository, the deployment pipeline, and the infrastructure accounts throughout.

A vendor structured to become a permanent dependency has arranged the relationship around their revenue rather than the client's outcome. That arrangement is visible in the contract terms — who holds the accounts, who owns the code, and what handover is contractually required.