A Relative Recommended Their “Website Guy”: Take It or Not?

A referral is a good starting point and a poor substitute for verification — the useful move is to check the referred vendor exactly as you’d check a stranger, and to agree an exit before you start. The relationship makes both harder later, which is why both happen now.

The moment it happens

When a relative recommends “their website guy” — take it or run? The recommendation arrives with social weight attached. Saying no feels like doubting the person who offered it, so many owners hire without asking anything.

That’s the risk, and it isn’t about the developer’s ability. It’s that the normal checks feel rude, so they get skipped, and the normal escalation later feels impossible, so it doesn’t happen.

What the referral is actually worth

It’s genuine evidence of something. Someone had a project completed to their satisfaction. That’s more than a stranger’s portfolio proves.

It’s evidence about a different project. Ask what was built. A single-page site for a relative’s coaching class tells you little about a product catalogue with payments.

It transfers trust past the checks. This is the part worth naming. Referred vendors typically get asked fewer questions, receive advances faster, and are held to vaguer deadlines — precisely the conditions in which projects drift.

Three questions to the referrer, and they take a minute:

  1. What exactly did he build for you?
  2. Was it delivered on the date he said?
  3. When you needed a change months later, what happened?

Answer three is where the useful information is. “He’s very good” is a character reference; “he took two extra weeks but fixed a bug the same day a year later” is data.

Verify anyway — the awkwardness is smaller than you think

None of these is an insult. Framed as normal process, they’re rarely resisted:

  • Four live client URLs, opened on your phone.
  • Price, delivery date, exclusions and domain ownership in writing.
  • Payments in stages rather than upfront.
  • Domain registered in your account, whoever builds it.

If asking feels uncomfortable, use the frame: “I’m doing the same paperwork with everyone, hope that’s alright.” Most vendors, referred or not, find that reasonable.

Referral advantage Referral risk
Verified he finished at least one project May be a different project type
Some accountability through the mutual contact Escalation costs a relationship
Often better pricing Vague scope and dates go unchallenged
Faster trust Checks skipped, advance paid early

Agreeing the exit before you need it

This is the part almost nobody does and the part that saves the relationship. Say it while everyone is cheerful:

If it isn’t live by [date], let’s agree now that I’ll get it finished elsewhere and there’s no hard feelings either way.

Stated in advance, that’s a normal business condition. Raised in week seven, it’s a confrontation involving three people including whoever made the introduction.

Also: pay him properly. A discounted rate given as a favour is the most common reason a referred project drifts — favours get scheduled after paid work. If the job is worth ₹18,000, paying ₹18,000 buys you a normal client relationship, which is what you actually want.

What to do this week

  1. Ask the referrer the three questions, especially the one about later changes.
  2. Ask the vendor for four live URLs and the four written items.
  3. Register the domain in your own account before work starts.
  4. Agree the exit condition out loud, and put it in the same message as the date.
  5. Pay a fair rate rather than a favour rate.

If you want it done the certain way

If the referred developer clears those checks and quotes fairly, use them — a verified referral is a reasonable choice and we’d say so. Where we’re useful is when you’d rather the terms be standard and written: published prices, a delivery date with a refund behind it, and the domain in your name. WhatsApp us; we reply in about five minutes between 9am and 7pm.

Related reading

FAQ

Is a referred web developer safer than one I find online?
Somewhat — you have evidence they completed at least one project. The risk is that referrals often skip verification and firm deadlines, which is where projects drift. Check them the same way you’d check anyone.

How do I say no to a family recommendation without offence?
Keep it about fit and process rather than the person: you needed published pricing, a written date, or a vendor with experience in your specific type of site. Deciding before an advance is paid keeps it simple.

Should I pay a friend or relative less for building my website?
A discounted favour rate is the most common reason such projects stall, because favours get scheduled after paid work. Paying a fair rate buys you a normal client relationship and the right to ask for a deadline.

What do you think?

What to read next