The questions that separate a good development supplier from one that will make your life difficult

The problem with commissioning custom development is that the result takes months to become visible. By the time you discover the supplier does not work as promised, you are already 4 months into delays, 2 months into scope changes and facing a budget that has grown 40%. These questions are designed to reveal how a supplier actually works before you sign anything.

Any supplier can show an impressive demo, a list of technologies and a client portfolio that sounds good. What you cannot see in a first meeting is whether they have a real change management process, whether they document what they build, whether the code will be maintainable by someone other than the person who wrote it, or whether they will disappear when the first serious bug hits production.

• How do you manage scope changes during the project? (A serious supplier has a defined process, not 'we'll deal with it when it happens')
• How often will I have access to the code in a working staging environment?
• Who is my technical point of contact during the project and what is their parallel workload?
• How do you document the technical decisions you make during development?
• What happens if the project's technical lead leaves the company during development?
• Can you show me the actual QA process from a previous project?

• Is the source code mine from day one or only upon project completion?
• Do you use libraries or components with restrictive licences that limit my future use?
• What technical documentation will you deliver at the end of the project?
• How long do you estimate it would take another team to understand and continue the code without you?
• Do I have access to the code repository with full commit history?

• Vague answers about the change management process ('we adapt to each project')
• Cannot show concrete examples of technical documentation from previous projects
• The technical contact changes between the sales meeting and project kickoff
• No staging environment separate from production
• Defensive reactions to questions about code ownership or audit

• Phases with verifiable milestones and defined acceptance criteria
• Change management process with specified cost and timeline impact
• Code ownership and repository access from the start
• Named technical owner with estimated real availability
• Delivery and transition plan at project completion
• Clearly defined post-launch warranty and support process

Asking these questions during the evaluation phase is not distrust: it is the difference between a project that ends well and one that ends in dispute. Serious suppliers answer in detail. Those who cannot are showing you what working with them will be like.