Introduction:
The questions you ask a product engineering company before signing a contract are the most important investment you can make in the success of your product. Most evaluations lean too heavily on portfolio presentations and proposals — formats every competent sales team can optimise. The questions that reveal actual capability are the ones designed to surface information that cannot be rehearsed: how they handle complexity they did not anticipate, what they do when something goes wrong, and whether their commitment to quality survives delivery pressure.
"The product engineering companies worth working with are the ones who answer your hardest questions before you finish asking them. Evasion about process, delivery behaviour under pressure, or IP terms is showing you exactly how they will behave when those things matter most."
Questions About Discovery and Problem Understanding
• "Walk me through your discovery process — what does it involve, how long does it take, and what does it produce?" — Genuine discovery capability is described with specific outputs: validated problem statement, prototype, scoped requirements. Vague answers reveal that discovery is a sales word, not a practice.
• "Can you give me an example of a discovery that resulted in a recommendation not to build what the client originally asked for?" — The best product engineering companies can tell this story. It reveals whether their discovery process can produce a "do not build this" outcome — the highest-value finding discovery can produce.
• "How do you handle a situation where your technical assessment reveals the problem is more complex than the original scope suggested?" — Reveals change management discipline. The answer should describe a structured escalation process, not a choice between absorbing scope silently or presenting a surprise invoice.
• "Who from your team participates in the discovery phase — and are they the same people who will do the engineering?" — Discovery conducted by sales people, handed off to a different team for execution, produces alignment failures.
Questions About Engineering Standards
• "What is your automated test coverage requirement and how do you enforce it?" — A specific answer (e.g., 70% coverage enforced by CI pipeline) reveals genuine discipline. "We aim for high coverage" does not.
• "Who does code review and what are the criteria for approval?" — Look for: every PR reviewed by at least one senior engineer; specific review criteria; a culture where rejection is normal, not awkward.
• "Walk me through your CI/CD pipeline — what checks run on every commit?" — Should include: unit tests, integration tests, linting, security scanning, accessibility checks. A pipeline that only runs a basic build is not providing meaningful quality gates.
• "What is your approach to technical debt — how do you track and address it?" — Best answers describe a formal register, sprint allocation (10–20% of capacity), and escalation process when debt affects velocity.
• "Which AI coding tools do your engineers use, and what is your AI governance policy for client code?" — A 2026-essential question. Firms using AI tools without a written data protection policy are handling client code carelessly.
Questions About Delivery and Accountability
• "Can you walk me through a project that missed its timeline — what happened, how did you communicate it, and what changed as a result?" — The most revealing delivery question. Cannot tell this story honestly = significant red flag.
• "What does your sprint review look like — who attends, what is demonstrated, and how is feedback incorporated?" — Should describe live working software demonstrations, regular client decision-maker attendance, and documented feedback process.
• "How do you define and enforce your Definition of Done?" — Every competent engineering team has a written DoD. Ask to see it.
• "What business outcome metrics do you agree with clients before development begins?" — The best companies frame work in outcomes (activation rate, retention) not outputs (features shipped).
Questions About IP, Security, and AI Governance
• "Who owns the code produced in this engagement from day one?" — The correct answer is you. Any answer requiring clarification is a risk.
• "When do we get repository access?" — The correct answer is from the first sprint.
• "What data protection obligations do you take on for code and data we share?" — Look for: signed NDA before information exchange, data processing agreements, subcontractor terms, and AI governance policy.
Codesis Technologies answers every question in this list with documented policies, reference contacts, and contract templates that address all of these concerns:
Reference Questions to Ask Their Clients
• "Did the team communicate problems early, or did you find out when they had become unavoidable?" — The single most revealing reference question.
• "How did they handle scope changes when the system turned out more complex than expected?" — Reveals change management behaviour under real conditions.
• "How smooth was knowledge transfer — how quickly could your team operate independently?" — Reveals post-engagement support quality.
• "What would you do differently in the selection process?" — Often produces the most valuable insight.
• "Would you engage them again for a new product build?" — Binary but revealing.
