1. Define what you actually need
Before contacting anyone, write down your goals, must-have features, target timeline, budget range and the tech constraints you already have. A clear brief lets you compare companies on the same basis and filters out poor fits fast.
2. Examine the portfolio and references
Look for work similar in complexity and domain to yours, not just a pretty showreel. Ask for references and actually call them - ask about reliability, communication and what went wrong and how it was handled.
3. Assess technical and domain expertise
Confirm depth in the stack your product needs and experience in your industry. Strong partners advise on architecture, security and scalability up front rather than just taking orders.
4. Test communication and process
How quickly and clearly a company responds during the sales process predicts the engagement. Ask how they run projects: sprints, demos, reporting, and your time-zone overlap. You want frequent visibility, not a black box.
5. Understand pricing, contracts and IP
Get transparent pricing and an engagement model that fits (fixed-price, dedicated team or staff augmentation). Confirm you own the IP, and read the terms on change requests, warranties and exit. See our cost guide and engagement models.
6. Watch for red flags
- Quotes that seem too cheap, with vague scope
- No references or relevant case studies
- Slow, unclear communication before you've even signed
- Reluctance to assign IP or sign an NDA
- Over-promising on timeline without discovery
- No access to the code repository until the project is finished
- Nobody can tell you which developers will actually work on your project
A simple scoring checklist
Score each shortlisted company from 1 to 5 on the criteria below, give extra weight to the ones that matter most for your project, and compare the totals side by side. Writing scores down stops the most charismatic sales call from winning by default.
- Relevant work - comparable complexity, domain and scale
- Technical depth - sensible answers on architecture, security and testing
- Process - how sprints, demos, estimates and change requests work
- Communication - clarity, speed and honesty during the sales process
- Commercials - transparent pricing, IP ownership, NDA and exit terms
- Team stability - who works on your project and how handover is handled if someone leaves
Questions to ask in the first call
- Who exactly will work on my project, and can I speak to them before signing?
- How do you estimate, and what happens when an estimate turns out to be wrong?
- What will I see each week - demos, reports, access to the backlog?
- How is code reviewed, tested and deployed, and who has access to it?
- What would you push back on in my brief?
The last question is the most revealing. A company that agrees with everything has either not read your brief closely or is not planning to challenge you once work starts.
Check references and code quality, not just case studies
Case studies are curated; references and code are not. When you call a reference, ask what the team was like three months in, how they handled a missed estimate, and whether the client would hire them again for the same kind of work.
If you are not technical, ask to see sample code from a past project (with that client's permission) or commission a small paid pilot, and have an independent developer review it. Look for readable structure, automated tests, a meaningful commit history, documentation and a repeatable deployment process. A team that cannot show these on request is unlikely to produce them for you.
Contract essentials: IP, NDA and exit
Make sure the contract states that you own the source code and all intellectual property, assigned on payment rather than at some undefined future date. Sign an NDA before sharing sensitive details, and tie payments to milestones you can verify with working software.
Plan the exit on day one. You should hold or have access to the repository, cloud accounts, domains and credentials, and the contract should describe handover documentation and notice periods. If you could not switch vendors next month without losing your product, the contract is not finished. At PixoBots the client owns the code and IP and we sign an NDA before kickoff - whoever you choose, insist on the same.
What to ask now that AI helps write code
Many development teams now use AI coding assistants, which can speed up delivery. It also changes what you should ask: the question is no longer whether a company uses AI, but how it keeps AI-written code under control.
- Who reviews AI-generated code before it is merged, and is that review required for every change?
- How is AI-written code tested, and who writes or checks the tests?
- Is any of my code or data sent to third-party AI services, and can that be restricted?
- How do you keep security and licensing problems in generated code out of my product?
Good answers name a human reviewer, automated tests and security checks for every change. Vague answers - or a claim that AI does the work on its own - are a new red flag.
Ready to talk?
If you'd like a partner that scores well on all six, tell us about your project - we'll respond within 24 hours, or browse how to hire our experts.