What to Actually Ask Before Hiring an Outside Engineering Partner

By the time a company calls us to fix a project another firm delivered, the pattern is almost always the same: the vendor selection process focused on the wrong signals. A polished portfolio, a compelling sales deck, a rate that fit the budget. None of those predict whether the team behind them can actually deliver a maintainable system on time.

We've been the second call — the team brought in to rescue or rebuild — often enough to know exactly where the original vetting process broke down. It's rarely a skills gap. It's a due diligence gap. The questions that would have surfaced the risk were never asked.

1. 1Who owns the code, in writing, from day one? Not "at project completion" — from the first commit. Ambiguous IP and repository ownership is the single most common source of painful, expensive disputes at handover.
2. 2What does your architecture decision record look like? A serious partner documents why they chose a database, a framework, a service boundary — not just what they built. If they can't produce this for a past project, they aren't going to produce it for yours.
3. 3What happens if our point of contact leaves your company mid-project? If the answer is vague, you're relying on one person's memory instead of an institutional process.
4. 4Can we talk to a client whose project ended, not one who is still actively engaged? A reference from an active client tells you about the sales relationship. A reference from a completed project tells you about the handover.
5. 5What's your actual test coverage philosophy, and can you show it, not describe it? Ask for a sample of tests from a comparable past project, not a slide about their QA process.

• A quote that's dramatically lower than every competing bid, with no explanation of where the margin is coming from — usually it's coming from documentation, testing, or senior oversight, all of which surface later as your problem.
• Reluctance to commit to a fixed architecture review milestone before full-speed development begins.
• A team structure where you never learn the names or seniority of the actual engineers writing your code, only the account manager.
• No willingness to walk you through how they'd approach the handover before the contract is signed — handover thinking that starts on day one produces a fundamentally different codebase than handover thinking that starts in the final sprint.

Before your next RFP, write down what you'd need to see, in writing, to be confident a stranger on your own team could pick up this codebase in two years and understand it without a single call to the original vendor. Then use that list — not the pitch deck — to score every proposal you receive.

As a custom software development company that's been on both sides of this — the original build and the rescue call — our view is simple: the vetting conversation you have before signing is worth more than any clause you add after.