Questions to Ask a Software Development Agency Before You Hire Them

Use the selection process to understand how an agency scopes work, estimates effort, communicates changes, and makes technical decisions. Ask for examples that support its answers.

These are the questions worth asking, and what good answers look like.

Questions About the Discovery and Scoping Process

"Walk me through how you scope a project before giving us an estimate."

This question surfaces whether the agency does real discovery or produces estimates from brief conversations. A strong answer describes a structured process: stakeholder interviews, requirements documentation, technical architecture review, integration feasibility checks, and a written deliverables set. A weak answer describes a conversation, a spreadsheet, and a number.

"What written deliverables do we receive from the discovery phase?"

Ask to see examples of each deliverable. A requirements document, architecture diagram, and integration map from a previous engagement (with sensitive details redacted) are reasonable to request. If the agency cannot produce examples, their discovery process is not producing the artifacts it should.

"How do you handle requirements that are unclear or unresolved during scoping?"

Good agencies surface ambiguity explicitly and document open questions with resolution timelines. Agencies that give confident answers to questions that are genuinely ambiguous are not being thorough — they are making assumptions that will surface as scope disputes later.

"How does your discovery process change if our requirements are likely to evolve during development?"

This question tests whether the agency can advise on contract structure. A sophisticated answer distinguishes between products that are well-suited to a fixed price engagement (stable, fully defined scope) and products that benefit from a time-and-materials structure (evolving scope, iterative validation). An agency that recommends fixed price for every project regardless of scope clarity has an incentive misalignment worth noting.

Questions About Estimation

"How do you break down your effort estimates, and what assumptions do they rest on?"

Estimates should be broken down by workstream and should document their assumptions explicitly. An estimate that arrives without stated assumptions is an estimate that will need revision the moment an assumption turns out to be wrong. Ask for the assumptions in writing.

"What happens to the estimate if our requirements change after the contract is signed?"

This question reveals the agency's change management process. A clear answer describes a defined change request process: a written change request, an impact assessment on timeline and cost, and mutual agreement before the change is incorporated into the build. An agency that says "we'll handle changes as they come" is describing a process where scope and cost drift without accountability.

"Can you share an example of a project that came in significantly over the initial estimate, and what caused it?"

Ask how the team identified and communicated a variance, what caused it, and how the client and agency agreed on the response.

Questions About Communication and Project Management

"How will we be updated on progress, and who is our primary point of contact during the build?"

You want a specific answer: a named project manager or technical lead, a defined communication cadence, and a defined format for progress updates. "We'll be in touch regularly" is not a process.

"How do you handle disagreements between our product team and your engineering team about scope, timeline, or implementation decisions?"

This question tests whether the agency has a defined escalation path. Good agencies have clear decision rights: product decisions belong to the client, technical implementation decisions belong to the engineering team, and disputes that cross both domains have a defined resolution process.

"What is your policy on adding team members to our project mid-engagement?"

Team continuity affects quality. Engineers who join a project mid-build take time to get up to speed, and that ramp-up has a cost. Some agencies treat projects as interchangeable and rotate engineers freely. Others commit specific team members for the duration. Know which you are buying.

Questions About Technical Approach

"What is your recommended architecture for a product like ours, and why?"

You are not testing for the correct answer — there often is not one. You are testing whether the agency can articulate a reasoned technical position based on your specific requirements and constraints, rather than defaulting to whatever stack they are most comfortable with.

"What third-party integrations in our scope do you have direct experience with, and which ones will require investigation?"

Ask the team to distinguish integrations it has used directly from those requiring research. Request examples for dependencies that are important to your project.

"How do you approach security and compliance requirements in your builds?"

Security and compliance should be part of the requirements conversation, not an afterthought. An agency that addresses security requirements as part of scoping — not as a bolt-on after launch — is operating at a higher standard.

Red Flags Worth Noting

• An estimate produced before a structured discovery phase is complete
• Refusal to share example deliverables from previous projects
• No defined change management process for scope changes
• Confident answers to questions that are genuinely uncertain
• A discovery phase that produces only a presentation deck, not written technical deliverables
• No ability to explain the reasoning behind architectural recommendations

Compare the written scope, assumptions, sample deliverables, and named responsibilities across suppliers before deciding.

---

Discuss LinkIT's discovery and scoping process.