Quick Answer: You can’t judge code you can’t read, but you can judge the system that produces it. Ask every finalist the same 12 questions, in writing, across four groups: Process (discovery, the spec, change handling), People (who writes the code, seniority, departures), Quality (definition of done, visible QA, staging access), and Terms (ownership, post-launch, exclusions). Score each answer 0-2 and compare sheets: 19-24 is a finalist, 12-18 means probe the gaps, 0-11 is a pass regardless of the portfolio.
The stakes are the industry’s base rate: McKinsey and Oxford’s study of 5,400+ IT projects found an average budget overrun of 45%. Vendor selection is the one moment you can move your own odds, before the contract makes them yours.
Here is the shortlisting experience as buyers describe it: “Every agency says the same things: experienced team, agile process, quality code. The portfolios all look good. I have no way to tell who will actually deliver until it’s too late to switch.” That last clause is the real problem. Software engagements have a brutal switching cost, so the selection mistake isn’t discovered, it’s inherited, for a year.
This guide is the instrument we’d want every buyer to bring to every agency, ourselves included. It works because of an asymmetry you can exploit: the agency has sold a hundred projects and you’ve bought three, but systems can’t improvise. A company that genuinely runs paid discovery, written change orders, and senior code review answers these questions instantly, specifically, and in writing, because the answers existed before you asked. A company that doesn’t will answer in adjectives. Twelve questions, and the adjectives identify themselves.
Why Portfolios and Testimonials Can’t Separate Finalists
It isn’t that portfolios lie; it’s that they’re all survivors. A portfolio is the curated subset of projects that went well, shown as screenshots, which reveal design taste and nothing about what the code looks like underneath, how the budget behaved, or what month four felt like. Testimonials are the same filter applied to clients. By the time you’re comparing three finalists, you’re comparing three marketing departments, and marketing departments converge, which is exactly why every proposal reads identically. The things that actually decide your outcome (who reviews the code, how a scope change gets priced, who owns the repo on day one) are systems, invisible in any portfolio and fully visible under direct questioning. The old treaty-signing proverb is the whole method:
“Trust, but verify.”
Russian proverb, made famous by Ronald Reagan (1987)
Process: Questions 1-3
| Question | The strong answer | The evasive answer |
|---|---|---|
| 1. What happens before you quote? | A paid discovery phase producing a written specification with acceptance criteria, which you own either way | “We can quote from this call and your deck” |
| 2. Who writes the spec, and who owns it? | “We draft it with you; it’s your document whoever builds” | “We’re agile, heavy specs just slow things down” |
| 3. How do mid-project changes get handled? | Written change orders at any size, each with price and schedule impact, approved by you | “We’re flexible, we absorb the small stuff” |
Why this group comes first: these three answers predict your budget better than the quote does. A number produced without discovery is a measurement of fog, “agile” used as a reason not to write things down is a scope dispute scheduled for month four, and absorbed changes are precisely how projects end 45% over with nobody able to say why; the full mechanics, cause by cause, are in our budget overrun guide, which doubles as the reference for what these three answers should contain.
People: Questions 4-6
| Question | The strong answer | The evasive answer |
|---|---|---|
| 4. Who exactly will write my code? | Named people, whom you meet before signing, committed through launch | “Our team of 200 experts” |
| 5. What’s the seniority mix, and who reviews the work? | A stated ratio, and every line passes senior review before it merges | “All our developers are senior” |
| 6. What happens if my lead developer leaves mid-project? | Documented handover process, documentation as a paid deliverable, overlap period | “That won’t happen, our retention is excellent” |
The pattern to listen for in this group, and really in all twelve: you’re not judging the promise, you’re listening for whether a system or an improvisation is answering. “That won’t happen” is a plan that requires luck; “here’s the handover process” is a plan that assumes people are people. The sales-call bait-and-switch (senior faces in the pitch, juniors in the repo) dies at question 4’s “whom do I meet before signing,” and question 5’s honest version admits juniors exist, because juniors are fine when every line passes senior review and are expensive precisely when it doesn’t, which is the arithmetic behind what an hourly rate actually buys.
Quality: Questions 7-9
| Question | The strong answer | The evasive answer |
|---|---|---|
| 7. What is inside your definition of done? | Code review, automated tests, and documentation are part of “complete,” in the contract, not extras | “We test everything thoroughly” |
| 8. Is QA a line item I can see? | Yes, scoped: what gets tested, on which devices, including edge and failure paths | “It’s bundled into development” |
| 9. Do I get staging access throughout? | A standing staging URL from the first sprint; you watch the product grow | “We’ll demo at each milestone” |
Quality is where a non-technical buyer feels most outgunned, and these three questions need no technical judgment at all, because each converts “quality” from an adjective into an artifact you can check: a contract clause, a line item, a URL. Invisible QA is happy-path QA; a milestone demo is a performance, while a standing staging link is a window; and a definition of done that lives in good intentions is how the cheap build acquires the APR nobody quoted, since debt is created at the exact moment unreviewed, untested work gets accepted as finished.
Terms: Questions 10-12
| Question | The strong answer | The evasive answer |
|---|---|---|
| 10. Who owns the code, repo, and infrastructure, from day one? | You do, in the contract: repo in your org, cloud and domain accounts in your name, from the first commit | “Ownership transfers on final payment” |
| 11. What exactly happens after launch? | A defined defect-warranty window, then support at rates written into this proposal | “Don’t worry, we’ll always be here for you” |
| 12. What does this quote exclude? | A volunteered written list: revision rounds, QA depth, support, third-party fees | “It’s all-inclusive” |
Terms is the group that decides whether you’re hiring a partner or acquiring a dependency. “Ownership on final payment” sounds almost reasonable until you’re in a dispute, at which point your own product is collateral; we’ve anatomized that trap, exit clause by exit clause, in the hostage codebase. Question 11’s vague warmth (“we’ll always be here”) is how month-two bug fixes become invoices at surprise rates, and question 12 is the quote-spread decoder: a low bid is very often a normal bid with the exclusions removed, so the vendor who volunteers the list is showing you an honest total while the “all-inclusive” one is showing you a brochure.
Shortlisting right now?
Send Techuz the brief and ask us all twelve, in writing. As a custom web development company in the USA market with 12+ years and 500+ projects behind the answers, we’d rather compete on the sheet than on the pitch.
Red Flags That End the Conversation Immediately
Most weak answers cost a point; a few end the evaluation on the spot, because each one predicts a specific, documented failure. A detailed quote with no questions asked: a vendor who didn’t need to understand your project is pricing their hope, not your build. “We’ve never had a project run over”: the only disqualifying answer to an overrun question, for the same reason it would be from a surgeon; the honest version names a past overrun and what changed after it. Ownership that transfers on final payment: see the hostage codebase; this clause has one purpose and it isn’t yours. Nothing in writing: a vendor who keeps specs, changes, and exclusions verbal is keeping them deniable. No communication structure for the time-zone gap: if the plan for a 10-hour offset is “we’re very responsive,” you’re buying the clarification-cycle failure we mapped in Signal Loss, where one ambiguous sentence costs two days per round trip; the strong answer names overlap hours, a decision log, and who’s awake when you are. A price that only works without review and QA: the Accelerance survey’s own conclusion, from inside the outsourcing industry, is that chasing the lowest sticker price is a false economy; a bid far below the field isn’t a discount on the same product, it’s a different product with the expensive parts deleted.
The Scoring Sheet
Copy this into a spreadsheet, one column per agency, and score each question 0 (evasive or adjective-only), 1 (partial, or strong but verbal), or 2 (strong, specific, and in writing), for a maximum of 24:
- Q1 Paid discovery with an owned spec Q2 Spec authorship and ownership Q3 Written change orders, any size
- Q4 Named team, met before signing Q5 Seniority mix and universal review Q6 Departure handover process
- Q7 Contractual definition of done Q8 Visible, scoped QA line item Q9 Standing staging access
- Q10 Ownership from day one Q11 Defined warranty and support rates Q12 Volunteered exclusions list
19-24: a finalist; compare price between finalists only, never between a finalist and a cheaper evader. 12-18: re-ask the low-scoring questions in writing, once; a company with real systems answers better on paper, and one without gets vaguer. 0-11: pass, however beautiful the portfolio and however low the price, because the evasions are the forecast. Two mechanical rules make the sheet work: every finalist gets the same twelve, and answers only count at full score in writing, since the contract is where verbal warmth goes to disappear.
How Techuz Answers These 12
A selection guide published by an agency should put its own neck on the sheet, so here are four of our twelve, committed in public rather than claimed on a call. Q1: engagements start with a paid, fixed-scope discovery whose deliverables (specification, ranged estimate with stated assumptions, risk register) are yours, whoever builds. Q3: every scope change goes through a written change order with no minimum size, priced before it’s built. Q10: repository, infrastructure, and accounts are set up in your name from day one; our access is the revocable thing, not yours. Q12: our proposals carry the exclusions list on page one: revision rounds, QA scope, the warranty window, support rates, and third-party costs, because the spread between quotes should be explainable, not mysterious. The other eight are better asked than published, since the point of this guide is that you verify rather than trust: bring the sheet, ask all twelve, and score our web development services against every other agency on your list with the same ruler. That’s the comparison we built the ruler for.
Ask us the other eight
Thirty minutes, your brief, all twelve questions, answers in writing afterward. Score the sheet and decide with the comparison in front of you.
FAQs
What questions should I ask before hiring a web development agency?
Twelve, in four groups: what happens before the quote, who writes and owns the spec, and how changes are priced (Process); who exactly writes the code, the seniority mix and review practice, and the departure plan (People); the definition of done, a visible QA line item, and staging access (Quality); ownership from day one, post-launch warranty and rates, and what the quote excludes (Terms). Ask every finalist the same twelve, in writing, and score the answers 0-2.
How can I evaluate a web development company without a technical background?
Don’t evaluate the code; evaluate the system that produces it, which requires no technical judgment. Each of the twelve questions converts a claim into a checkable artifact: a contract clause, a line item, a named person, a staging URL, a written list. You’re listening for whether a system or an improvisation is answering: companies with real processes respond instantly and specifically because the answers existed before you asked.
What are the biggest red flags when choosing a web development company?
Six end the conversation outright: a detailed quote produced without asking you questions, the claim that they’ve never had a project run over, code ownership that transfers only on final payment, a refusal to put specs and changes in writing, no concrete structure for working across a time-zone gap, and a price that only makes sense if review and QA have been removed. Each predicts a specific, well-documented failure mode rather than a matter of taste.
Should I choose the cheapest web development quote?
Not on price alone, because the cheapest quote is frequently a normal quote with the expensive parts deleted: senior review, scoped QA, a warranty window, and the exclusions left unmentioned until they arrive as invoices. The working rule from the scoring sheet: compare price only between finalists who scored 19 or higher, where you’re genuinely comparing the same product, and treat a bid far below that field as a different product wearing the same label.
Who should own the code when working with a development agency?
You, from day one, in the contract: the repository in your organization, cloud and domain accounts in your name, and documentation delivered as the project runs rather than at the end. “Ownership transfers on final payment” converts your own product into the agency’s collateral in any dispute, and it’s the foundation of the hostage-codebase pattern. An agency confident in its work has no need to hold the asset; its access should be the revocable thing, not yours.