In this guide 6 sections
Ask which named person would fill your role, what happens if that person resigns, and who holds the accounts and repositories on day one. Then ask how a replacement is introduced and billed, which roles the vendor turns down, and whether you may interview the engineer before signing. Vague answers mean a thin bench.
Which named person fills this role?
Do not accept a list of skills. Ask for a name, a current project, the release date that project is aiming at and the date when that person is free to start on yours. Without a name, candidates are sourced after you sign, the bench is smaller than the brochure suggests, and you interview whoever happens to be free that week.
Then ask who else on the bench could fill the same seat, whether it is a React Native developer or a QA lead. A vendor with real depth names backups without hesitating, and a long silence tells you the bench is thinner than the deck. Silence tells you plenty.
Ask whether the person has worked on a codebase like yours, such as a Laravel monolith, a Flutter app or a Node API with a legacy database. A call before you sign settles it.
- Name and years on the stack you use
- Current project and release date
- Date the person can start
- Two backups for the same role
- Willingness to put them on a call before you sign
What happens when someone resigns mid-project?
Every vendor loses people. The plan is what counts. Ask for the notice period the engineer works, the overlap with a replacement and who writes the handover note covering open pull requests, deploy steps and flaky tests.
Request a swap they handled without a gap in delivery, with the sequence of steps and the days between exit and a replacement who could merge code. No client name is needed.
Also ask whether a shadow engineer reads your pull requests and can step in within days, because that overlap keeps a resignation from stalling a release.
Who holds the accounts and credentials?
The repository, cloud console, error tracker, CI secrets and app store listings should live under your company’s accounts, with vendor engineers invited in as members. Never the other way round.
Ask how access is removed when an engineer leaves, and look for a revoked GitHub seat, a rotated CI secret and an access log you can read. Same day is the right answer.
Add the items vendors forget, such as the shared Slack channel, design files in Figma, the staging server login and app signing keys for both stores. Each one needs an owner on your side.
- Git hosting owned by you
- Cloud account owned by you
- Password manager shared vault with your admin
- Laptop and VPN rules for vendor staff
- Written offboarding checklist
How does replacement actually work?
Ask whether you can reject a candidate after interviewing, whether a poor fit can be swapped in the first month and what notice applies. The answer belongs in the contract.
Check who pays for the overlap days while the new engineer learns your codebase, since some vendors absorb them and others bill them in full. Know which before the first swap. Handover days add up fast.
Ask about minimum terms too: the length of the first engagement, the notice to end it and whether you can grow from one engineer to three.
Which roles do they refuse?
A good vendor declines work. Ask which roles they will not staff, such as a sole architect with no review, or a role that needs on-site presence in your city. Refusal shows they know their limits.
Close your call with a request for two references from teams that ran for over a year, ideally on a stack close to yours. Phone both of them today. Ask what went wrong, not what went well, and listen for how the vendor handled the first bad sprint and the first missed release.
Finish with a score. Add up each vendor’s answers, set aside the polish of the pitch and shortlist only the two whose answers were specific and written down.
Vendor question scorecard
The table lists the five questions as rows, with a column for each of the three vendors under comparison and a final column for notes. Each cell holds the answer given, a score from zero to three and a note on proof offered, such as a named engineer or a contract clause. A bottom block totals the scores. It also lists red flags.
Open a blank worksheet to printQuestions owners ask
How many vendors should I compare?
Three is enough. Beyond three, attention spreads thin, calls pile up and you end up comparing slide decks instead of the people who would join your team.
Should I interview the engineers myself?
Yes. Run a technical conversation with the person who will sit in your team, using one real problem such as a failing test or a slow query.
Is a trial period reasonable to ask for?
Yes. A two to four week paid trial with a clean exit clause shows how the engineer works with your tickets and reviews.
What should the contract say about notice and handover?
It should name the notice each side owes, the handover days the vendor covers and when access is cut, so an exit follows written steps instead of an argument. Get it in writing.