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

Every web dev agency sounds the same on a first call. Scalable. Pixel perfect. End to end. Partner, not vendor. The same glossy mockups in the deck, the same confident line that your project is exactly the kind of thing they're great at. Then three months later, half the people who signed are sitting in a rescue call with someone like me.

Here's the catch. Almost nothing that separates a team that ships from a team that vanishes shows up in the pitch. It shows up in how they answer a few specific, slightly awkward questions, the ones a polished sales process is built to glide right past. So here are ten of them, with what a real answer sounds like and the thing that should make you walk. I run buildbyRaviRai, and honestly, I'd want you to ask us these too. A good shop has nothing to hide here.

1. Who's actually going to write my code, and can I talk to them first?

The senior who charms you on the sales call is very often not the person who touches your project. That's the whole body-shop model. Pitch with your best people, deliver with your cheapest. If one thing predicts quality, it's whether you get to talk to the real builder before any money moves.

A good answer is simple. They put the developer who'd lead your build on the next call, and that person asks sharp questions about what you're trying to do. A bad answer is fog. "Our team will handle it." No names. "You'll get a project manager who coordinates everything," with the devs kept somewhere behind a wall. If you can't meet the dev before you sign, the dev you get won't be the dev you were sold. It happens every single time.

2. Can I see live URLs, not screenshots?

A screenshot proves someone made a mockup. A working URL proves the team shipped something that actually runs in production, which is a very different skill. Anyone can drop a beautiful Dribbble shot into a slide.

So ask for links you can click, open, and poke at. Run a couple through pagespeed.web.dev. If the answer is "we can't show anything, it's all under NDA," be careful. Some NDA work is normal. A portfolio with zero things you can actually open is not. Real work survives being inspected. Our portfolio is the format you should expect: real sites, live, clickable.

3. What's the written scope, and what happens when I want to change something?

"We'll figure it out as we go" is how a project quietly doubles in cost and a six-week timeline turns into six months. The absence of a written scope isn't flexibility. It's a blank cheque with your name on it.

What you want instead is boring and specific. A scope that lists what you're getting, a clear way to request changes, and an honest line about what isn't included. If the proposal is one paragraph, or the answer is a warm "don't worry, we'll handle whatever you need," that vagueness gets resolved in the agency's favour every time once you're locked in.

Those first three already tell you most of what you need

If a team clears those, meaning you can talk to the real dev, you can open their live work, and they'll put a real scope in writing, you've already filtered out the bottom two-thirds of the market. The rest of the questions sort the good from the genuinely good, and they protect you from the kind of failure that doesn't show up until month three.

4. Who owns the code, the repo, and the accounts?

Some agencies build everything on their own accounts and quietly hold your site, your domain, and your source code hostage. Leaving them means starting over.

So get this in plain language before you sign. The right answer is that you own all of it from day one. Your GitHub, your hosting, your domain, your logins. They work inside your accounts, not their walled garden. The wrong answer sounds like "we'll host it for you" with no handover, or a domain that turns out to be registered in the agency's name. Just ask them straight. If I fire you tomorrow, what do I walk away with? It should be everything.

5. What's your stack, and why that one for my project?

A good team picks the stack that fits your problem. A weaker one reaches for the only stack it knows and bends your project to fit. The reasoning matters more than the answer.

You're listening for something like "for a content site we'd lean Next.js or Astro, and for what you're describing, here's the reason." Bonus points if they tell you when a cheaper or simpler option would do the job. Be wary of "we build everything in one platform" no matter the project, and of buzzword soup with no logic under it. Watch especially for teams that default to a heavy page builder for work that needs clean custom code. It feels quick at the start and turns into a mess within a year.

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

A slow site quietly bleeds conversions and rankings, however pretty it looks in the demo. If an agency can't talk about LCP, INP, and CLS without hand-waving, they ship sites that look great on the call and crawl on a real phone.

A solid answer comes with numbers. Real targets, like LCP under 2.5 seconds and INP under 200 milliseconds, plus their own live sites scoring 85 to 100 on mobile PageSpeed. Performance is a build requirement for them, not a thing they bolt on later. If all you get is "it'll be fast, don't worry," run their existing work through PageSpeed yourself. A score in the 30s on mobile tells you everything.

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

A website isn't a one-time purchase. It's a living thing that needs updates, security patches, and the occasional fix at an inconvenient hour. Teams that go quiet at launch leave you stranded the first time something breaks.

You want a plan. A warranty window, a maintenance option with pricing you can actually see, and a clear way to reach a human when the site is down. The thing to avoid is a hard stop at launch and then surprise "emergency" rates the first time you need help. Ask what a small fix costs before you launch, not after.

8. Show me how you'll communicate during the project

Most projects that fall apart don't fall apart on the code. They fall apart on communication. Two weeks of silence, then the wrong deliverable lands. The way a team talks to you in week one is the way they'll talk to you in month three.

So look for a real cadence. Weekly updates, a shared channel or board, one named person you can reach, and a response time they'll commit to. If the whole plan is "email us anytime," or the sales rep is already hard to pin down before you've paid, take the hint. That's the best behaviour you're ever going to see from them.

9. Tell me about a project that went wrong, and how you handled it

Every real team has shipped a bug, blown a deadline, or watched a project go sideways. An agency that claims a perfect record is either bending the truth or hasn't done enough work to have any scars. What you actually care about is how they handle a mess, because that predicts how they'll handle yours.

The answer you want is a real story. "We underestimated this part, here's what broke, here's how we made it right." That kind of honesty is the strongest signal you'll get all day. The answer to avoid is "nothing's ever gone wrong, we're great," or a tidy version where every past problem was somehow entirely the client's fault.

10. What would make you turn this project down?

A team that says yes to everything is optimising for your signature, not your result. A team with judgment will occasionally tell you the idea needs rethinking, or the budget doesn't match the scope, or that you don't actually need them yet.

Listen for real conditions, like "if you need this in two weeks at this scope, we'd rather decline than ship you something broken." They've clearly walked away from work before. The answer that should worry you is boundless enthusiasm with zero pushback. The willingness to lose your business by being straight with you is the clearest sign they'll look after the project once it's theirs.

How to actually use this

1. Don't fire all ten off like an interrogation. Work four or five of the sharpest ones (1, 2, 3, 4 and 9) into a normal conversation and watch how they react. How they answer tells you as much as what they say.
2. Send the same questions to three teams. The contrast is the whole point. One will dodge, one will give you polished non-answers, and one will actually engage. Hire that one.
3. Verify instead of trusting. Open the live URLs. Run PageSpeed yourself. Ask to meet the developer. A good shop is happy to do all three. A body shop gets defensive.
4. Trust the honest answers most. The team that admits a flaw, owns a real failure, or tells you what they'd turn down is almost always the safer bet than the one with the spotless story.

FAQ

Agency, freelancer, or in-house?

A freelancer is the cheapest option and great for small, well-defined work, but you're betting on one person, so illness, a vanish, or a full calendar can stall you. In-house is best for ongoing product work, though it's expensive and slow to build. A small senior shop makes sense when you want a team's worth of skills (design, dev, and the infrastructure side) without hiring four people, and you care about continuity more than the rock-bottom price. The ten questions above work for all three. A good freelancer answers them just as cleanly as a good agency does.

How much should this cost?

It swings wildly with scope and where the team is based, so anchor on value rather than the sticker price. A written scope, senior engineering, code you own, and real support after launch are worth paying for. A suspiciously cheap quote with none of that usually turns into the most expensive option once you count the rescue job. Get itemised quotes from a few teams and compare what's actually included, not just the number on the front page. Our pricing and cost calculator show what a transparent estimate looks like.

What's the single biggest red flag?

Not being allowed to talk to the actual developer before you sign. Almost everything else, like vague scope, no live URLs, or no handover of accounts, tends to cluster around that one. If the people building your site are kept behind a sales wall, assume the build quality is back there too.