10 Questions Every CTO Should Ask a Dev Agency in the First Call (2026 Edition)
Most dev agency calls are won on presentation, not substance. These 10 questions cut through the deck and reveal whether the agency can actually deliver. Most will struggle with at least 4 of them.
Why Most Dev Agency Calls Tell You Nothing Useful
A well-run dev agency discovery call is a sales performance. The deck is polished. The case studies are curated. The communication is fluid. By the end of the call you feel good about the team.
None of that tells you whether they can deliver. It tells you they are good at sales calls.
After 13 years and 1,300+ projects we have been on both sides of this conversation. We have been the agency being evaluated and we have helped clients build evaluation frameworks for choosing their vendor. The questions in this article are the ones that consistently reveal actual capability, not presentation capability. Many of them pair naturally with our 15-point agency vetting checklist which covers deeper pre-call due diligence.
Use these 10 questions in your next dev agency discovery call. Take notes on the specificity of the answers. Vague answers to specific questions are a signal. Confident, detailed, verifiable answers are a signal. The difference becomes clear very quickly.
- Print or save these questions before your next dev agency discovery call.
- Ask each question in your own words. Do not read them verbatim from a list.
- Listen for specificity. Good answers include numbers, names, and verifiable details.
- Listen for hedging. Phrases like 'it depends', 'typically we' and 'generally speaking' without specifics are evasion, not nuance.
- Ask follow-up questions. The follow-up reveals whether the initial answer was genuinely known or quickly constructed.
Questions 1 to 5: Technical Capability and Process
Question 1: Show me the last code review comment you left on a client PR. |
Why it matters: Code review quality is the most reliable signal of technical standards available in a discovery call. A senior engineer who reviews code well leaves specific, referenced, educational comments. A team that does not review code seriously cannot produce this. The request for a real example removes the ability to describe a hypothetical process. |
Strong answer sounds like: Specific PR comment with technical reasoning, a reference to a coding convention, and a constructive suggestion. Something like: 'Service logic belongs in the service class, not the controller. Here is why this matters at scale for this codebase...' |
Red flag: They describe their code review process instead of showing it. 'We have a thorough review process' without a concrete example means the process is aspirational or inconsistent. |
Question 2: What was the last Laravel version upgrade you completed for a client, and what did it involve? |
Why it matters: This reveals whether the team is actively working on production Laravel applications or selling capability they have not recently exercised. A team that cannot describe a specific, recent upgrade engagement is either fabricating their Laravel experience or has not done this work in a meaningful timeframe. |
Strong answer sounds like: A specific version pair (e.g., 9 to 11), a named engagement context, specific challenges (deprecation of certain helpers, changes to middleware registration, updated service provider patterns), and the timeline. Real answers have specifics. Fabricated answers stay vague. |
Red flag: A general statement that they handle Laravel upgrades without a specific recent example. Or a confident claim that upgrades are simple that reveals they have not recently encountered the complexity of a real upgrade on an active production application. |
Question 3: What is your onboarding process for a new engagement and what do you need from us before Day 1? |
Why it matters: Agencies with mature delivery processes have a documented onboarding checklist with specific client-side requirements. Agencies without one are inventing the process as they go. This question reveals delivery maturity faster than almost any other. The answer also tells you how much work you will need to do on your side to enable the engagement. |
Strong answer sounds like: A specific list of pre-Day-1 requirements: repository access, codebase README, architecture overview, sprint tool access, communication channel setup. A described onboarding sequence with a named timeline (48-hour first PR, end-of-week-1 check-in). Bonus: a written onboarding guide they can share. |
Red flag: We will figure it out together once we start. Or a vague description of a kickoff call with no specifics. This means the engagement will spend its first week doing setup work that should have been done before Day 1. |
Question 4: What is your sprint delivery rate and how do you measure it? |
Why it matters: Any agency that talks about delivery without tracking delivery metrics is managing by feel, not by data. A 95% sprint delivery rate means something specific and verifiable. 'We always meet deadlines' means nothing. This question distinguishes agencies that measure their performance from those that market their performance. |
Strong answer sounds like: A specific percentage, a description of how it is calculated (committed scope vs delivered scope), and an honest acknowledgement of what causes it to drop occasionally (scope changes, client-side blockers). Acquaint Softtech maintains a 95% sprint delivery rate across active engagements. |
Red flag: We always deliver on time. Or: our clients are always happy with our delivery. These are marketing statements. The absence of a specific metric means the agency does not track its delivery performance and therefore cannot improve it. |
Question 5: How does your team handle a blocker that requires a decision from the client side? |
Why it matters: Blocker resolution speed is one of the 8 factors most strongly correlated with engagement success or failure. An agency's answer to this question reveals their process discipline and their expectation management. A good answer includes a specific escalation path, a defined response expectation, and a proactive communication stance. |
Strong answer sounds like: We surface blockers in writing at the point we identify them, not at the next standup. We document the specific decision required and the impact on the sprint if it is not resolved within X hours. We have an agreed response SLA with our clients at the start of every engagement. |
Red flag: We send an email. Or: we wait for the daily standup. Either answer means blockers accumulate silently and the sprint fails without warning. Slow blocker resolution is the single most common cause of milestone slippage in engagements that started well. |
Questions 6 to 10: Quality, Culture, and Long-Term Fit
Question 6: Are you an Official Laravel Partner and can you verify it right now? |
Why it matters: This is the fastest independent quality signal available for a Laravel agency. Official Laravel Partner status is granted by Laravel LLC, verified by the core team, and publicly searchable at partners.laravel.com. If the agency claims partnership but cannot verify it immediately, they do not hold it. Self-declared expertise is worth what it costs to claim. |
Strong answer sounds like: Yes, and here is our listing: partners.laravel.com/partners/[name]. Look us up right now. Verifiable in 30 seconds. Acquaint Softtech's listing: partners.laravel.com/partners/acquaint-softtech |
Red flag: We are Laravel-certified. Or: we are official Laravel developers. These are self-declared claims, not the same as Official Laravel Partner status. If they cannot direct you to their listing on partners.laravel.com, they are not a verified Official Partner. |
Question 7: What percentage of your developers are full-time employees versus contractors or marketplace hires? |
Why it matters: A team of full-time in-house developers builds shared expertise, consistent code review standards, and institutional knowledge. A team assembled from freelancers per project delivers inconsistent quality, fragmented knowledge, and higher turnover risk. This question cuts directly to the structural difference between a genuine delivery organisation and a staffing broker with a nice website. |
Strong answer sounds like: 100% full-time in-house employees. No freelancers. No contractors. All developers work together, review each other's code, and build shared standards. Acquaint Softtech maintains 70+ full-time in-house engineers with zero freelancers on any client engagement. |
Red flag: Most of our team are full-time but we bring in specialists when needed. This means the specialists have no shared quality baseline with the core team and no institutional knowledge of your codebase. The engagement quality is inconsistent by design. |
Question 8: Tell me about a project that went wrong and what you did about it. |
Why it matters: Every agency with 13+ years of delivery history has had projects that did not go according to plan. An agency that cannot or will not discuss this has either had no experience worth discussing or is concealing something. The answer reveals how the agency handles adversity, how they communicate problems to clients, and whether they take responsibility or deflect it. |
Strong answer sounds like: A specific engagement with a named problem (missed milestone, technical debt that slowed the project, a scope misalignment that required renegotiation), what was done to address it, and what process change resulted from it. Honest, specific, owned. |
Red flag: We have always delivered for our clients. Or a carefully hedged story where the problem was entirely the client's fault. Perfect delivery records are a red flag, not a credential. They indicate either very short delivery history or selective disclosure. |
Question 9: What is your process when a developer assigned to our project is not performing? |
Why it matters: This question is the one most agencies hope you do not ask. It reveals whether the agency has a genuine quality management process and a replacement mechanism or whether they will manage the situation diplomatically until you raise it as a client complaint. The answer also tells you how much risk you carry if the first developer assignment is not right. |
Strong answer sounds like: We have a performance review process that identifies issues within the first two sprints. If a developer is not the right fit, we initiate replacement within 48 hours at no additional cost to the client. We have done this in engagements and it has strengthened the client relationship, not damaged it. We can give you a specific example if you want one. |
Red flag: We have never had a performance problem with any of our developers. Or a vague commitment to resolve issues if they arise. The absence of a specific replacement process means you are taking the performance risk, not the agency. |
Question 10: What will the developer who works on our project actually know about our business and codebase on Day 1? |
Why it matters: This question exposes the gap between what an agency promises in the sales call and what the developer assigned to the engagement actually knows when they start. Great agencies brief their developers from scoping call notes before Day 1. Most agencies leave the developer to figure it out from the repository. |
Strong answer sounds like: The assigned developer will have reviewed your company overview, your current tech stack, your active sprint context, and the key architectural decisions in your codebase before their first standup. We brief developers from our scoping notes and send a developer profile document to the client before Day 1. The onboarding is already running on our side when you have not even started yours. |
Red flag: The developer will get up to speed quickly. Or: we have a thorough onboarding process. Both are vague. The right answer is specific about what the developer knows and when they know it, before the engagement starts. |
Quick Reference: Strong vs Concerning Answers at a Glance
Use this table during or after your discovery call to score the agency's responses. Three or more concerning answers in the top 5 questions is a disqualifying signal.
Question | Strong Answer | Answer That Should Concern You |
Show me a real code review comment | Specific, referenced, educational | Describes process without showing it |
Last Laravel upgrade you completed | Specific version, client, challenge, timeline | General claim without recent specifics |
Onboarding process before Day 1 | Documented checklist, specific timeline | We figure it out together at kickoff |
Sprint delivery rate | Specific percentage + measurement method | We always deliver on time |
Blocker resolution process | Written escalation, defined SLA | We mention it in the next standup |
Official Laravel Partner verification | Directs you to partners.laravel.com now | Claims certification without verification |
Developer employment structure | 100% full-time in-house, no freelancers | Mix of employees and contractors/freelancers |
A project that went wrong | Specific, owned, with a process change | We have always delivered perfectly |
Non-performing developer process | Named replacement process, 48-hour timeline | Vague commitment to resolve if needed |
What dev knows on Day 1 | Specific briefing from scoping notes | The developer will get up to speed |
How Acquaint Softtech Answers All 10
We wrote these questions. It is only fair that we answer them publicly. This section gives you our specific answers before you even pick up the phone. Verify each one before or after the call.
Q1: Code review evidence | We maintain a Laravel coding standards document referenced in every PR review. Our review comments cite the standards document, identify the specific issue, and provide a constructive suggestion. We can share anonymised examples from recent engagements on request. |
Q2: Most recent Laravel upgrade | We run 50+ active Laravel upgrade engagements annually. We were ready for Laravel 12 from launch. Our team handles everything from minor version bumps to major structural migrations including service provider refactoring, middleware registration changes, and deprecated helper replacement. |
Q3: Onboarding process before Day 1 | We send the client a pre-onboarding guide before Day 1 covering what we need from them and what they will receive from us. The developer receives a briefing from our scoping notes. First PR target is 48 hours. We run a Week 1 check-in call with both the developer and client at no additional cost. |
Q4: Sprint delivery rate | 95% across active engagements. We calculate it as committed sprint scope completed before review. It drops when clients introduce informal scope changes mid-sprint, which is why we have a formal change request process. |
Q5: Blocker resolution | Developers surface blockers in writing at the point of identification, not at the next standup. We set a 4-hour response SLA with clients during the overlap window at the start of every engagement. Unresolved blockers are escalated to us and we contact the client directly if the SLA is missed. |
Q6: Official Laravel Partner | Yes. Verified at partners.laravel.com/partners/acquaint-softtech. Also Official Bagisto Partner and Statamic Partner. Also listed on Laravel News: laravel-news.com/partner/acquaint-softtech. Verify now before the call. |
Q7: Developer employment structure | 100% full-time in-house employees. 70+ engineers. Zero freelancers on any client engagement. Our developers work together, review each other's code, and build shared standards across the team. |
Q8: A project that went wrong | We have had engagements where a scope misalignment in Sprint 1 required a reset conversation in Sprint 3. We address these directly with the client, redefine the sprint scope formally, and implement a change request process going forward. We can describe specific examples on request. |
Q9: Developer replacement process | If a developer is not the right fit within the first two sprints, we initiate replacement within 48 hours at no additional cost. The replacement developer receives a full briefing from the exiting developer before handover. We have done this. It has not damaged a single client relationship. |
Q10: What the developer knows on Day 1 | The developer knows: your company overview, your product and tech stack, your active sprint context, and the key decisions in your codebase. We brief developers from our scoping call notes. We send you a developer profile document before Day 1 including their background and relevant experience. |
The Call Is the Start, Not the Finish
These 10 questions will not tell you everything you need to know about a dev agency. They will tell you whether the agency is worth continuing to evaluate. An agency that cannot answer 3 or more of these questions with specifics is an agency that does not have the delivery infrastructure to back up their proposal.
Use these questions alongside our Official Laravel Partner verification guide for a complete vendor evaluation picture. If you want to run Acquaint Softtech through these questions in a live call, we welcome it. We built the checklist. We can answer everything on it.
Read verified client reviews on clutch | Official Laravel Partner | Laravel News Partner
FAQ's
-
What is the most important question to ask a dev agency in the first call?
Question 9 (the developer replacement process) is the one most agencies cannot answer specifically and the one most CTOs forget to ask. It is the question that tells you how much delivery risk you are carrying. An agency without a named replacement process and a defined timeline means you are the one absorbing the risk if the developer is not right. Question 6 (Official Laravel Partner verification) is the fastest single-question quality filter because it is immediately verifiable and eliminates a large category of agencies with one 30-second check.
-
How many of these questions should a good agency be able to answer?
All 10 with specifics. An agency that hedges on more than 2 of these questions is either underprepared for a serious evaluation call or lacks the process infrastructure to answer confidently. One or two questions may require follow-up data that they send after the call. That is acceptable. Vague answers on questions like sprint delivery rate, developer employment structure, and the replacement process are not acceptable because these require no client-specific data.
-
How do I evaluate answers for specificity vs vagueness?
A specific answer includes at least one of: a named number (95% sprint delivery rate), a named process step (we surface blockers in writing within 2 hours), a verifiable credential (partners.laravel.com/partners/[name]), or a named outcome from a past engagement. A vague answer stays in the general category: we always deliver on time, we have a thorough process, our clients are always satisfied. If you cannot verify or operationalise the answer, it is vague.
-
Should I ask these questions in this order?
The order matters somewhat. Starting with a technical demonstration request (Question 1) sets the tone that this is a capability evaluation, not a sales conversation. Ending with what the developer will know on Day 1 (Question 10) closes the loop on the full engagement lifecycle. Questions 3 to 5 cover process and Questions 6 to 9 cover structural credibility. You can adjust the order but covering all 10 areas is more important than the sequence.
-
Can I send these questions to the agency before the call?
Yes, with one caveat. Sending questions in advance gives the agency time to prepare good-sounding answers. The call follow-up question is where the real signal emerges. If an agency answers Question 2 with a specific upgrade example before the call but cannot answer a follow-up like 'what were the specific deprecations you had to address in that upgrade?' during the call, the pre-call answer was researched rather than experienced.
We’re Acquaint Softtech, your technology growth partner. Whether you're building a SaaS product, modernizing enterprise software, or hiring vetted remote developers, we’re built for flexibility and speed. Our official partnerships with Laravel, Statamic, and Bagisto reflect our commitment to excellence, not limitation. We work across stacks, time zones, and industries to bring your tech vision to life.
Table of Contents
Get Started with Acquaint Softtech
- 13+ Years Delivering Software Excellence
- 1300+ Projects Delivered With Precision
- Official Laravel & Laravel News Partner
- Official Statamic Partner