Skip to content
All writing
2 min read

Choosing an IT partner without getting burned

Most vendor selection goes wrong before the contract is signed. Here are the questions that actually predict how a build will go.

  • Consulting
  • Vendors

Picking a software partner is mostly an exercise in reading signals under uncertainty. You cannot see the code that does not exist yet, so you are really evaluating how a team thinks. After a decade of both sides of this table, these are the checks that correlate with projects that ship.

Ask to see a real repository, not a portfolio

Portfolios are curated. A repository is not. Ask to walk through one real project — commit history, pull request discussions, how issues were tracked. You are looking for:

  • Commits that are small and describe why, not just what.
  • Pull requests with actual review comments, not rubber stamps.
  • Tests that exist and run in CI.

If a team cannot show you any of this, they either do not work this way or cannot share it. Both are worth knowing early.

Push on the boring parts

Anyone can demo a happy path. The questions that separate teams are about the unglamorous 20 percent:

  1. How do you handle database migrations in production?
  2. What happens when a deploy goes wrong at 2am?
  3. Who owns the incident, and how do you write it up afterward?

Confident, specific answers here mean the team has run software in production, not just handed it over.

Watch how they scope

A partner who says yes to everything is telling you they have not thought about tradeoffs. The teams worth hiring will cut scope in the first conversation. They will say things like "we would ship the reporting module in phase two" or "that integration is a week you probably do not need yet." Scoping down is a sign of respect for your budget.

Ownership is a contract term, not a vibe

Get the answer in writing: you own the code, the infrastructure accounts, and the data. No hostage situations, no proprietary runtime you can only host with them. If leaving is expensive by design, that is the design.

The one-day rule

Send a real technical question by email and see how long the reply takes and how it reads. We answer within one business day, and the answer is a paragraph, not a calendar link. How a team communicates before you pay them is the best preview of how they communicate after.

More writing

Have a project that needs this kind of thinking?