Short answer
Verify every claim at its source, meet the engineers who will do the work rather than the sales team, run a short paid trial, and read the contract for IP assignment, notice periods and data protection. Then check security practices and real working-hour overlap. A vendor that cannot pass these checks quickly will be harder to work with later.
1. Verify every claim at its source
Ratings, awards and client logos are easy to put on a website. Follow each one to its source: a review platform badge should link to a live profile with dated reviews, a client logo should come with a case study and, ideally, a reference you can call. Check that the numbers agree across the vendor’s own pages; inconsistent project counts or team sizes are a warning sign.
2. Meet the engineers, not only the sales team
Ask to speak with the engineers or the tech lead who would join your project, before you sign. Ask them to walk you through something they built: the architecture, a trade-off they made, a production incident they handled. You will learn more in thirty minutes than from any portfolio.
3. Run a short paid trial
A one- or two-week paid pilot on a real but contained task shows code quality, communication and estimation accuracy. Pay for it: free trials attract vendors who make up the cost elsewhere, and you want to see the team that will actually work for you.
4. Look at how they write and review code
Ask how the team works day to day and look for specifics rather than buzzwords.
- Code lives in your repositories from the first day, not handed over at the end.
- Every change goes through review and automated tests in CI.
- There is a written definition of done and a release process.
- Documentation and architecture decisions are recorded where you can read them.
5. Read the contract for the four clauses that matter
Most disputes come from a few clauses. Check them before price.
- IP assignment: all code and documentation assigned to you, signed before work starts.
- Termination: notice periods you can live with and a handover obligation.
- Data protection: a data processing agreement and, for teams outside your jurisdiction, a valid transfer mechanism.
- Replacement: what happens if an engineer leaves, and how fast they are replaced.
6. Check security practices
Ask how access is granted and revoked, whether engineers use managed devices, how secrets are stored and how production data is kept out of test environments. A vendor that works inside your accounts and access controls is easier to audit than one that copies your code and data into its own systems.
7. Count the real working-hour overlap
Time zones matter more than vendors admit. Count the hours where both teams are actually at work, not the theoretical overlap, and check whether it holds when clocks change. Three or more shared hours a day is comfortable for most teams; less than two needs a deliberate process for handovers.
8. Ask about the bad project
Ask the vendor to describe a project that went wrong and what they changed afterwards. Every experienced team has one. An honest, specific answer is a good sign; a claim that nothing ever goes wrong is not.
| Check | What to ask for | Red flag |
|---|---|---|
| Claims | Links to live review profiles and callable references | Badges with no link, numbers that differ between pages |
| People | A call with the engineers on your project | Only sales staff until after signing |
| Trial | A paid one- to two-week pilot | Refusal, or a free trial by a different team |
| Code | Your repositories, review and CI from day one | Code delivered at the end as a zip file |
| Contract | IP assignment before work, clear notice and handover | IP transferred only on final payment |
| Security | Your accounts, managed devices, no production data in test | Shared logins, data copied to vendor systems |
| Overlap | Shared hours counted in both seasons | “We are flexible” with no numbers |