Before hiring a software engineering partner, find out exactly who will write the code, what similar systems they have delivered, how scope and acceptance are defined, and who owns the code from day one. Vague answers to any of these questions are a stronger warning sign than a high price.
Find out who will actually write the code
The people in the sales meeting are often not the people who build your system. Ask for the names, roles and experience of the engineers who will work on the project, and ask to speak with the technical lead before you sign.
Ask whether any work is subcontracted or done by freelancers. Both can work well, but you should know, and the partner should vouch for everyone it brings in. Also ask what happens if a key engineer leaves in the middle of the project, and who pays for the time a replacement needs to get up to speed.
- Who is the technical lead, and how much of their time is on this project?
- Which engineers are employees, and which are subcontractors or freelancers?
- How do you select and check the specialists you bring in?
- What is the process if someone leaves or is not a good fit?
Ask for track record that matches your problem
A long client list proves little if none of it resembles your project. Ask for examples with similar constraints: the same kind of system, comparable traffic or data sensitivity, and a similar regulatory context. Then ask what this team did in each case, not what the whole client program achieved.
Be precise about whose experience you are buying. Some firms present the individual track record of their engineers, which is legitimate if it is stated honestly. Ask when the company was founded, which work was done under its own contracts, and whether you can speak with a past client.
Get scope, milestones and acceptance in writing
Many disputes come from scope that was never written down precisely. A good proposal names the deliverables, breaks the work into milestones, and defines how each milestone is accepted, for example tests that pass, a demo on a staging environment, or documentation delivered.
Ask how change requests are handled and priced, and what the commercial model is. Fixed price suits well-defined work, while time and materials suits discovery and evolving requirements. Either way, you should see the assumptions behind the estimate.
Settle code ownership and the handover before you start
The contract should state that you own the code and related intellectual property, and when ownership transfers. Ask for repositories, cloud accounts and domains to be created in your organization from the first day, with the partner invited as a collaborator, so you never depend on them for access.
Plan the handover at the start, not at the end. Ask what you will receive: documentation, architecture decision records, runbooks for operations, and working sessions with your own team. Check which third-party and open source licenses the project will use, because they come with obligations.
Agree on how you will see progress
You should never have to ask whether the project is on track. Agree on a fixed rhythm, such as a weekly demo of working software and a short written status that covers progress, risks and decisions needed from you.
Ask for direct access to the issue tracker and the repository, and for one named contact who answers for delivery. Clarify how problems are escalated and how quickly you can expect a response.
Test their security practices, not their badges
Ask how engineers access your systems and data, how secrets are stored, how code is reviewed before it ships and how dependencies are checked for known vulnerabilities. Concrete answers matter more than a slide with logos.
If the partner will process personal data on your behalf, you need a data processing agreement that meets GDPR requirements. If a vendor claims a certification, ask for the certificate and its scope, and confirm it covers the team and services you are buying.
Red flags that should stop the conversation
One warning sign can have an explanation. Several together usually mean the project will be harder than it needs to be.
- They cannot name the engineers who will do the work.
- Case studies show outcomes but not what this team actually did.
- The estimate arrives before anyone has asked detailed questions about your system.
- Repositories and cloud accounts stay under the partner's control.
- Milestones have no written acceptance criteria.
- Security questions get general reassurance instead of specific practices.
Key takeaways
- Meet the technical lead and learn who will write the code before you sign.
- Judge track record by how closely it matches your constraints and by what the team itself did.
- Written milestones with clear acceptance criteria prevent many scope disputes.
- Keep repositories and cloud accounts in your own organization from the first day.
- Ask for specific security practices and evidence for any certification a vendor claims.
FAQ
How many partners should I talk to before choosing one?
Enough to compare real differences in approach, which for most projects means a few. Give each one the same brief and the same questions, so the answers are comparable.
Should I choose a fixed-price or a time-and-materials contract?
Fixed price suits work you can specify in detail before it starts. Time and materials suits discovery, evolving requirements and ongoing development, provided you get transparent reporting and regular demos.
What should a first call with a potential partner cover?
Your goal, constraints, timeline and existing systems, and their questions back to you. A partner that asks detailed questions about your system on the first call is usually one that will estimate it honestly. At SDK Enterprises, that first call is a 30-minute conversation in French or English.