How to Vet a Web Development Agency in 2026: 10 Questions That Separate Real Builders from Body Shops

Every web development agency sounds the same on the first call. The same words — "scalable", "pixel-perfect", "end-to-end", "partner not vendor". The same portfolio of glossy mockups. The same confident promise that your project is exactly the kind of thing they do best. And then, three months later, half of the people who hired them are in a rescue conversation with someone like us.

The gap between an agency that ships and one that ghosts you isn't visible in the pitch. It shows up in how they answer specific, slightly uncomfortable questions — the ones a smooth sales process is designed to skate past. This is the buyer-side checklist. Ten questions, what a strong answer sounds like, and the red flag that should make you walk. I run buildbyRaviRai, and I'd genuinely want you to run these on us too — a good shop has nothing to hide here.

1. "Who exactly will write my code — and can I talk to them before I sign?"

Why it matters: The senior who charms you in the sales call is often not the person who touches your project. Body shops pitch with their best people and deliver with their cheapest. The single biggest predictor of quality is whether you can talk to the actual builder before money changes hands.

Strong answer: "Here's the developer who'd lead your build — let's get them on the next call." You meet a real engineer who asks sharp technical questions about your project. Red flag: vague "our team" answers, no named people, or "you'll be assigned a project manager who coordinates everything" with the devs kept behind a wall. If you can't talk to the dev before signing, the dev will be different from what was pitched. Every time.

2. "Can I see live URLs of projects you shipped — not just screenshots?"

Why it matters: Screenshots prove a designer made a mockup. A live, working URL proves the team actually shipped something that runs in production. Anyone can put a beautiful Dribbble shot in a deck.

Strong answer: a list of clickable, real, currently-live sites you can open, inspect, and run through pagespeed.web.dev. Red flag: "we can't share client work due to NDAs" for *everything* (some NDA work is normal; a portfolio of zero inspectable links is not), or screenshots that conveniently can't be traced to a live domain. Open the links. Check they load fast. View source. Real work survives inspection — see our portfolio as the format to expect.

3. "What does the written scope look like — and what happens when I want a change?"

Why it matters: "We'll figure it out as we go" is how a ₹X project becomes a 3X project and a 6-week timeline becomes 6 months. The absence of a written scope isn't flexibility — it's a blank cheque you're signing.

Strong answer: a written scope with specific deliverables, a clear change-request process, and an honest explanation of what's *not* included. Red flag: a one-line proposal, a verbal "don't worry, we'll handle whatever you need," or a fixed price with no defined boundaries. Vague scope always resolves in the agency's favour once you're locked in.

3 is where most projects are already won or lost

If an agency clears the first three — real dev access, inspectable live work, written scope — you've already filtered out the bottom ~70%. The remaining questions separate the *good* from the *great*, and protect you from the failure modes that don't show up until month three.

4. "Who owns the code, the repository, and the accounts?"

Why it matters: Some agencies build on their own accounts and hold your site, domain, and source code hostage — so leaving them means rebuilding from scratch. Ownership is the difference between a vendor relationship and a captivity one.

Strong answer: "You own everything from day one — your GitHub, your hosting, your domain, your credentials. We work *in* your accounts." Red flag: "we host it for you" with no access handover, code that lives only on their servers, or a domain registered under the agency's name. Ask explicitly: *if I fire you tomorrow, what do I walk away with?* The answer should be "all of it."

5. "What's your actual tech stack — and why that one for my project?"

Why it matters: A good team picks the stack that fits *your* problem. A weak one uses the only stack they know and bends your project to fit it. The reasoning behind the choice tells you more than the choice itself.

Strong answer: a specific recommendation with honest trade-offs — "for a content site we'd go Next.js or Astro; for what you're describing, here's why." They'll even tell you when a cheaper or simpler option fits better. Red flag: "we build everything in [one platform]" regardless of the project, or buzzword soup with no reasoning. Watch for teams that default to a heavy page-builder for a job that needs clean custom code — it feels fast to start and rots within a year.

6. "How do you handle performance and Core Web Vitals?"

Why it matters: A slow site bleeds conversions and rankings no matter how pretty it is. If an agency can't talk specifically about LCP, INP, and CLS, they ship sites that look great in the demo and crawl on a real phone.

Strong answer: they reference real targets (LCP under 2.5s, INP under 200ms), can show you their own live sites scoring 85–100 on mobile PageSpeed, and treat performance as a build requirement, not an afterthought. Red flag: "it'll be fast, don't worry" with no specifics, or a portfolio of sites that score in the 30s on mobile. Run their own work through PageSpeed before you trust their promises about yours.

7. "What happens after launch — and what does it cost?"

Why it matters: A website is not a one-time purchase; it's a living thing that needs updates, security patches, and fixes. Agencies that go silent at launch leave you stranded the first time something breaks.

Strong answer: a clear post-launch plan — a warranty period, a maintenance/retainer option with transparent pricing, and a defined way to reach them when something breaks. Red flag: no mention of maintenance, a hard stop at launch, or surprise "emergency" rates the first time you need help. Ask what a typical small fix costs *before* you launch, not after.

8. "Can you show me how you communicate during a project?"

Why it matters: Most failed projects don't fail technically — they fail on communication. Silence for two weeks, then a wrong deliverable, is the classic pattern. How a team communicates in week one is how they'll communicate in month three.

Strong answer: a defined cadence — weekly updates, a shared board or channel, a named point of contact, and a guaranteed response time. Red flag: "email us anytime" as the entire communication plan, or a sales rep who's hard to reach *before* you've paid (it only gets worse after). Notice how fast they reply during the sales process — that's their best behaviour.

9. "What's gone wrong on a past project, and how did you handle it?"

Why it matters: Every real team has shipped a bug, missed a deadline, or had a project go sideways. An agency that claims a flawless record is either lying or hasn't done enough work to have scars. How they handle failure predicts how they'll handle *yours*.

Strong answer: a genuine story — "we underestimated X, here's what broke, here's how we made it right." Honesty here is the strongest possible signal. Red flag: "nothing's ever gone wrong, we're perfect," or blaming every past problem entirely on the client. The teams worth hiring are the ones who own their mistakes out loud.

10. "What would make you say no to this project?"

Why it matters: An agency that says yes to everything is optimising for your signature, not your outcome. A team with judgment will sometimes tell you that your idea needs rethinking, your budget doesn't match your scope, or that you don't actually need them yet.

Strong answer: they'll name real conditions — "if your timeline is two weeks for this scope, we'd decline rather than ship something broken" — and they've clearly turned down work before. Red flag: "we can do anything you need!" with boundless enthusiasm and zero pushback. The willingness to lose your business by being honest is the clearest sign they'll protect your project once they have it.

How to actually use this list

1. Don't ask all 10 like an interrogation. Weave 4–5 of the sharpest ones (1, 2, 3, 4, 9) into a normal conversation and watch how they respond — the *manner* of the answer matters as much as the content.
2. Send the same questions to 3 agencies. The contrast is the signal. One will dodge, one will give polished non-answers, and one will engage honestly. Hire the third.
3. Verify, don't trust. Open the live URLs. Run PageSpeed. Ask to meet the dev. A good shop welcomes this; a body shop gets defensive.
4. Weight the honest answers highest. The agency that admits a flaw, names a real failure, or tells you what they'd decline is almost always the safer hire than the one with a flawless story.

FAQ

Agency, freelancer, or in-house — which should I choose?

Freelancer: cheapest, best for small well-defined projects, but a single point of failure (illness, disappearance, capacity). In-house: best for ongoing product work, expensive and slow to build. Agency/senior shop: best when you want a team's worth of skills (design + dev + DevOps) without hiring four people, and you value continuity over the lowest possible price. These 10 questions apply to all three — a good freelancer answers them just as cleanly as a good agency.

How much should a real agency cost?

It varies enormously by region and scope, so anchor on value, not just the number: a written scope, senior engineering, code ownership, and post-launch support are worth paying for; a suspiciously cheap quote with none of those usually becomes the most expensive option once you factor in the rescue project. Get itemised quotes from a few teams and compare what's *included*, not just the headline price. (Our pricing and cost calculator show the format of a transparent estimate.)

What's the single biggest red flag?

Not being able to talk to the actual developer before you sign. Everything else — vague scope, no live URLs, no ownership handover — tends to cluster around that one. If the people building your project are kept behind a sales wall, assume the build quality is behind that wall too.