How to vet a web developer in 30 minutes, the checklist

This twelve-point checklist surfaces ninety percent of red flags in a single thirty-minute conversation.

Most AU small businesses spend more time choosing a coffee machine for the office than vetting the person they pay twelve thousand dollars to build their website. Then the website does not work, and they wonder how they got there. They got there because nobody taught them how to vet a developer.

This is the checklist. Twelve points across three windows. Before the call, during the call, after the call. Print it. Take it to every sales conversation. The developers who pass are worth your time. The ones who do not save you twelve months of pain.

Before the call: four points to check in fifteen minutes

You should never get on a sales call cold. Fifteen minutes of pre-work surfaces half the red flags before you waste anyone's time.

1. Open three of their live client sites in a private browser tab

Live URLs only. Not screenshots. Not Figma mockups. Not "case studies" that read like marketing copy.

If their portfolio page says "Recent work" but the sites either fail to load, return SSL errors, or look like generic WordPress installs, you have learned almost everything you need. A developer cannot hide a broken portfolio. If they cannot ship sites that survive twelve months without a rebuild, they cannot ship yours either.

Bold opinion: at least one of the three live sites should be from the last six months. Older work tells you what they used to do. Recent work tells you what they do now.

2. Run Google PageSpeed on one of their live sites

Take their best-looking portfolio site. Drop the URL into PageSpeed Insights. Look at the mobile score.

Below sixty on mobile means the developer either does not know how to optimise performance or does not consider it part of the brief. Either answer is a problem in 2026 when Google's Core Web Vitals are a ranking factor and your customers are checking sites on a phone in a service station carpark.

3. Find them on LinkedIn

The developer should have a profile. The profile should match the agency. The work history should include actual coding roles, not just "founder, current". Senior developers usually have a paper trail of real engineering roles before they went solo.

If the profile is empty, vague, or screams "stock photo and three buzzwords", the human you are speaking with may not be the human writing the code.

4. Check if their own site loads cleanly

This sounds obvious. It is not. Almost forty percent of AU web developers I have audited have personal or agency sites that have at least one broken link, a slow page load, or a "coming soon" page that has been up for six months.

A web developer whose own website is broken does not get to charge you to build yours.

During the call: seven questions to ask, in order

Print this section. Ask the questions in this exact order. The order matters because each question filters for a different layer of seriousness.

5. "Can I see three live sites you built in the last twelve months?"

You already did this in pre-work, but ask again. Watch which three sites they choose. The sites they choose tell you what they are proud of. Compare against what you actually want built. If the gap is large, the engagement will go badly.

6. "Who specifically writes the code, what is their name, and will they be on the kickoff call?"

The answer should be a first name. Ideally the human on the call. The answer should not be "our team" or "depends on the project". The answer "the dev team will be introduced after contract signing" means you are looking at a sales-pipeline-to-juniors structure.

7. "Walk me through your last delivery, week by week"

You are asking for the rhythm of a real project, not confidential client information. A real delivery has a kickoff, a discovery, a design phase, a build phase, a staging review, a launch, and a hand-over. A senior who has shipped will describe each of those in detail. A salesperson will get vague by week three.

8. "What stack do you use, and why?"

The answer should be specific. "Next.js, Supabase, Vercel, Tailwind" tells you something. "We use the best technology for the job" tells you nothing.

You do not need to understand the stack. You need the developer to be able to defend the stack. A developer who cannot tell you why they chose their tools is going to make all your decisions for you with no transparency.

9. "What happens if you miss the deadline?"

The right answer is specific and unflinching. Discount, refund, free month of work. "We do not miss deadlines" is a brag, not an answer. Brags are usually lies.

A real shop has a written policy for missed deadlines. They quote you the policy in the call. They do not get defensive.

10. "What is your refund policy if I cancel in the first two weeks?"

The killer question. Most AU web developers do not have one. If they hesitate, ask a second time. If they still hesitate, your deposit is gone the moment it hits their account.

A senior shop with confidence in their delivery will have a refund window written into the contract. Even something small, like fifty percent refund in the first ten business days, is a sign that they expect to be held to a standard.

11. "Can I talk to your last paying client?"

The hardest reference check, and the most valuable. A confident developer will offer up the last delivery as a reference. A nervous one will offer a curated reference from two years ago.

Talk to the reference. Ask the reference whether the developer met the deadline, whether the budget held, and whether they would hire them again. The reference does not need to be effusive. The reference needs to be specific.

After the call: three deliverables to check, three deal-breakers to walk on

The first call should produce three things. If it does not, the developer is not serious.

12. The first proposal should arrive within five business days

Not the contract. The proposal. A written document that summarises scope, timeline, milestones, fixed price, and what is included vs not included. If it takes longer than a week, the developer is overcommitted or disorganised. Either is a problem.

The proposal should be specific. Generic language like "modern responsive website with custom design and SEO optimisation" is a copy-paste from every other proposal in their pipeline. Specific language references your actual business, your actual goals, and your actual user.

13. The proposal should include a payment schedule that protects you

The standard structure is thirty percent on contract sign, forty percent on staging delivery, thirty percent on production launch. Any developer asking for fifty percent or more upfront is funding their next project with your deposit. Any developer asking for one hundred percent upfront is a leaving party.

14. The proposal should reference your specific scope, not a template

The proposal that comes back should reference the live sites you talked about, the specific functionality you described, and the deadline you mentioned. If the proposal is generic, the developer was not listening on the call, and the project will go the same way.

Three instant deal-breakers, no negotiation

These three signs mean walk, no matter how nice the developer is or how much pressure you feel to start.

One. They refuse to put the money-back clause in writing. Even a small clause, even with conditions, is the line between a transaction and a leap of faith. Walk.

Two. They cannot name the human who will write your code. "Our team" is not a name. Walk.

Three. They want to start before the proposal is signed. A serious developer signs the contract before any work begins. Anyone offering to "just get started" is bypassing the parts of the process that protect you. Walk.

How to use this checklist

Print it. Take it to every developer call you have in the next quarter. Score each developer from zero to fourteen. Anyone who scores below ten is not worth hiring. Anyone who scores above twelve is worth a serious conversation. The handful who score fourteen are the ones you offer the project to before they get booked by someone else.

If you want to see what a senior-only delivery looks like in practice, our Voltari Digital Pilot tier is fixed-price, fixed-timeline, with a money-back clause written into the contract on day one. Send the brief to /#contact and we will price it before any call. You can also read how Australian SMBs keep getting burned for the structural reasons this checklist exists in the first place.

Vet before you hire. Hire once.