Questions to Ask a Software Development Agency: Six With Proof
Each question paired with the artifact that proves the answer, and the rule you set before the call.
The most useful questions to ask a software development agency are the ones with a document behind them. Ask who writes the code and you get a name; ask for that engineer's current allocation and the staffing clause in the contract, and you get something you can check after the call. Pair every question with an artifact and a pass/fail rule you set in advance.
Updated November 2026.
Why the standard questions to ask a software development agency cannot be checked
Four pages hold most of this query and they are substantially the same page: ten to fifteen questions, an "ideal answer" printed beside each one, a red-flag answer beside that, and no step in which you find out whether what you heard was true. The highest-ranking of them, DesignRush, prints an ideal and a red-flag answer for all ten questions without saying where either came from, and shows agency ratings beside the article while disclosing that some placements are sponsored, with no explanation in the piece of how those ratings were collected.
The answers are easy to give and the stakes are not. Flyvbjerg and Budzier's study of 1,471 IT projects found an average cost overrun of 27%, with one project in six behaving as a "black swan" at 200% average cost overrun and almost 70% schedule overrun. No question list changes that distribution. What a question can do is leave a trace you can check once the slide deck is closed.
So the test for a question is narrow. Name the document that would prove the answer, and write down what would count as a fail, before anyone is on the call. A question with neither is a conversation.
One question, one artifact, one rule written before the call
Six questions carry most of the signal in a second-round call. Each row gives the artifact that settles it and the rule to fix in advance, so an answer is scored against something you wrote rather than against how confident the speaker sounded.
| Question | Artifact that proves the answer | Pass/fail rule, written first |
|---|---|---|
| Who writes the code, and how much of it leaves your payroll? | Named engineers in the statement of work with their allocation, plus a written list of every party outside the agency that will touch the repository. | Fail unless two of those engineers join a technical call and the contract requires written consent before work moves to a party not on the list. |
| How are scope changes priced and approved? | The last three change orders issued on other accounts, redacted, with dates and amounts. | Fail if none can be produced, or if the statement of work does not define what counts as a change, the price basis and the response window. |
| How wrong are your estimates, and in which direction? | One finished project's original estimate set beside its final invoice. | Fail on an unexplained gap, not on a gap. An agency that has never been wrong has not measured. |
| Who owns the code, and what arrives on the first day of handover? | A signed assignment clause, plus a finished project's handover pack: commit history, README, runbook, infrastructure definitions, credential inventory. | Fail if the assignment covers only "deliverables", or if the pack would have to be written specially for you. |
| Can we speak to a client whose project went badly? | A named contact from a difficult engagement of comparable scope, plus the product running in public. | Fail if every reference is a success, or none is recent and comparable in size. |
| What does your security claim rest on? | The audit report or certificate itself, with its scope statement and the period it covers, plus the subprocessor list. | Fail on a badge image or a page on their own site, or if the scope statement does not name software development. |
Who writes the code, and whether any of it leaves the building
"Senior developers lead every project" is a claim about the agency, not about your project. The artifact that turns it into a claim about your project is a staffing table inside the statement of work: names, roles, the share of their week your work gets, and a substitution clause that requires written notice and your approval before anyone named is swapped out. Ask for names on the call and you get names. Ask for them in the contract and you find out whether the agency will be held to them.
Subcontracting is the same problem one layer down, and asking the question directly almost never works, because few agencies describe a long-standing delivery partner as a subcontractor. Federal buyers handle it with a clause rather than a question. The standard subcontracts clause, FAR 52.244-2, requires a contractor to obtain written consent before placing the subcontracts listed in the contract, and exempts those that were reviewed during negotiations and named in the contract itself. Borrow the shape: list the parties you have approved, and require written consent for anyone else who will hold a credential or push a commit.
The rule to write down first is a count, not a judgment: two of the three named engineers on a technical call answering a question about a prior build's architecture, and the consent clause present in the draft contract. An agency that staffs the work with the people who sold it clears that in a day.
Change orders and estimates: ask for the last three, not the policy
Every agency has a change-order policy and every policy reads the same way, because the policy is a paragraph and the behavior is a habit. The artifact is the behavior: the last three change orders the agency issued on other accounts, redacted down to the trigger, the date, the price and the turnaround. Read them for what the agency treats as a change rather than a clarification, whether the price basis is a rate card or a renegotiation, how long each decision took, and whether a change order has ever moved a price down.
Estimate accuracy is the companion question and the cheaper one to verify. Ask for one completed project's original estimate next to its final invoice. The 27% average overrun in the project data above is the benchmark to hold it against: a firm that lands inside that and can say why is more credible than a firm whose estimates were always exactly right. Which pricing model you end up in matters here too, and the difference between fixed price, time and materials, and outcome-based contracts is mostly a difference in who absorbs that gap.
This is also where the advice stops applying. If the whole engagement is one deliverable under $25,000 on a fixed price, the change-order machinery costs more to run than it protects, and a single-page scope with a named cut line will do.
Code ownership and handover: test the repository, not the promise
Ownership of software written for you is not automatic, and this is the question most lists skip. Under 17 U.S.C. § 101, a work made for hire is either an employee's work inside the scope of employment or a specially commissioned work falling into one of nine listed categories, among them translations, compilations, instructional texts and atlases. A computer program is not on that list. Code an outside agency writes therefore starts out belonging to the agency, and only a signed written assignment moves it.
So the artifact is two-part: the assignment language itself, which should cover everything written under the agreement rather than a list of named deliverables, and the handover pack from a project the agency has already finished. A pack that already exists is a commit history with more than one author, a README a new engineer can follow, a runbook for the things that break, infrastructure defined as code, and an inventory of every credential and third-party account. One assembled for your benefit is a document, not a practice.
You do not have to read it yourself. As of October 2026, Edverise lists 491 firms under code review and technical audits, and 22.8% of them state a minimum project size of $1,000, so an independent read of another agency's handover pack is a line item rather than a project of its own.
References and case studies: what past performance has to carry
Public buyers are required to look at past performance, and the rules they follow are a better model than anything in a vendor questionnaire. FAR 15.305(a)(2) calls past performance information one indicator of an offeror's ability to perform the contract successfully, and requires that its currency, its relevance, its source, its context and general trends in performance all be weighed. The same section says an offeror without a record of relevant past performance may not be rated favorably or unfavorably on it.
Three things follow for a shortlist of agencies. A reference is one indicator, not a verdict. A glowing reference from an old project in a different domain carries less than a mixed one from last quarter at your size. And a young firm with no comparable record is not disqualified by that, but it gets no credit for it either, so the rest of its artifacts have to be stronger.
Verifying a case study is mechanical once you know what to ask for: the named client contact who approved the invoices, the dates the work ran, and the definition behind any number in the write-up. If the study claims a gain, ask who measured it, against what baseline, and over what window. A case study whose metric has no owner is marketing copy with a logo on it. If you are running a structured process, this is the point where a written software development RFP template earns its keep, because it makes every agency answer the same question in the same shape.
What a listing, a badge or a rating actually proves
You will be reading directory profiles alongside these calls, so it is worth being exact about what one tells you. On Edverise, a company profile starts as a listing compiled from public information, and becomes Verified only once the company claims it and proves control of its domain by DNS or email. A listing therefore proves a firm exists and is findable. Verified status proves someone at that firm controls the domain. Neither is a statement about the work.
Reviews carry more, under conditions worth checking on any platform. On Edverise a review has to come from a named client on a real project and is checked before publication; anonymous reviews are not accepted. Reviews are also still being collected and most profiles carry none yet, so an empty review section is a fact about the platform's age rather than a finding about the firm. The rules for who can review a company are published, which is the part to look for elsewhere.
Ratings and rankings are where a buyer is most easily misled. Edverise keeps merit-based ranking visibly separate from sponsored placement, labels the sponsored slots, and publishes the ranking methodology and what does not count toward it. The working rule for any platform: a rating shown without a published method for collecting it should be read as advertising, and a badge is an image file until you can trace it to a standard with an issuing body.
One directory signal is genuinely checkable, and it is the one that tests a specialization claim. Edverise runs 1,249 active service categories, and the median category lists 5 firms, with 703 categories listing fewer than 10 and 29 above the counting limit of 10,000. So "we are one of the few firms doing this" is not an opinion: open the category and count. The counts are of listings per category, and a firm offering eight services appears in all eight, so they are never added together across categories.
Where the money floor sits, and what a quote has to clear
Minimum project size is the one number almost every agency states publicly, and it tells you whether a shortlist was ever in your band. As of October 2026, of the 2,247 firms listed under software development services on Edverise, 33.4% state a minimum project size of $1,000 and 11.3% state $25,000 or more. Only 3.6% state a floor of $50,000 or more.
That is useful in both directions. If all three shortlisted agencies quote well above your budget, the shortlist was drawn from the wrong band and the fix is a filter rather than a negotiation. And a stated floor of $50,000 puts a firm in the smallest band of the distribution, which is worth asking about: a firm whose smallest engagement is several times yours has no habit of running work at your size.
The honest cut line: skip the formal process when the project is one deliverable under $25,000, and run it above that. Below that threshold the artifacts that matter shrink to two, the assignment clause and the handover pack, and the rest of the script is overhead.
Frequently asked questions
What should I ask a software development agency on the first call?
On a first call, ask three things: who specifically would be assigned, what the agency's smallest and largest current engagements are, and what it would need from you in the first two weeks. Those answers tell you whether the agency sits in your size band and has a working start-up routine, which is all a first call can settle.
How do I find out who will actually write the code?
Ask for the engineers to be named in the statement of work with their allocation, and ask two of them to answer an architecture question on a technical call. A name in the contract with a substitution clause requiring your written approval is the artifact; a name in a slide deck costs the agency nothing.
What questions reveal that an agency subcontracts?
Asking directly rarely reveals it, because a long-standing delivery partner is seldom described as a subcontractor. Instead ask for a written list of every party that will hold a credential or push a commit, and put a clause in the contract requiring written consent before work goes to anyone not on it. Hesitation over the clause is the answer.
How do I check an agency's case study is real?
Ask for the named client contact who approved the invoices, the dates the work ran, and who measured any number the study quotes and against what baseline. Then look at the product running in public. A case study with no named owner for its metric and no reachable contact is a marketing asset, not past performance evidence.
Should I ask for the team's CVs before signing?
Ask for CVs, but treat them as the weakest artifact in the set. A CV proves a history, not an allocation. The stronger versions are the named staffing table in the statement of work, the substitution clause, and two of those engineers answering a technical question live. Use CVs to decide who you want on the call.
Before the call, write the scoring sheet
Put the six questions on a single page, one row each, with the artifact you will ask for and the rule that decides pass or fail. Send the artifact list with the meeting invitation so nothing has to be produced under pressure, and fill the sheet in during the call rather than after. Three agencies scored against the same written rules usually separate on the second or third row, and rarely on price.
Then score what you are actually looking at. Edverise's guidance on how to find, compare and vet a vendor covers the filters that build a shortlist worth taking to a second round, and the same habit applies there: ask what each signal on a profile proves, and discount the ones that do not say.