Red Flags When Hiring Freelance Developers

PORTFOLIO PROOF: CAN THEY SHOW, NOT TELL?

A freelancer's portfolio is their CV, reference and interview in one. The red flags:

• No live work to show. Screenshots without links, "NDA" covering everything, or a portfolio of tutorial projects. One or two genuine NDAs are normal; a whole career of them is a story, not a portfolio. Ask for a walkthrough of one project — what they built, what broke, what they'd do differently.
• Work that isn't theirs. It happens more than you'd think: agency work presented as solo work, or a template sold as custom. Ask directly: "What exactly did you personally build on this project?" Honest freelancers answer precisely; embellishers get vague.
• Nothing in your stack. A brilliant PHP developer isn't automatically a brilliant React developer. If your product is in a specific stack, hire proven experience in it — not "I can pick it up". Learning on your budget is not a discount, it's a risk with your name on it.
• No evidence of finished products. Half-built demos and abandoned side projects suggest someone who starts well and ships rarely. You need a finisher. Ask what they shipped to real users and what happened after launch.

The green flag version: live links, specific about their role, relevant stack, and at least one project they'd happily walk you through including the ugly parts. Nobody's work is perfect; the ones who admit it are the ones you want.

CODE OWNERSHIP: WHO OWNS WHAT YOU'RE PAYING FOR?

This is the section that saves startups from the worst outcomes. Under UK law, a contractor generally owns the copyright in what they create unless the contract assigns it to you. No written agreement, no clean IP — and unclean IP is something investors check in due diligence. Founders have had funding rounds delayed over exactly this.

Red flags:

• No contract, "we'll sort paperwork later". Later never comes, or comes during a dispute. The contract — with IP assignment, payment terms and what happens on termination — gets signed before work starts. Full stop.
• They want to work in their own repo, on their own servers. Your code should live in a repository you own and control from day one (GitHub, GitLab, Bitbucket — your account, their access). Same for hosting, domains and third-party services: your accounts, their access, revocable by you. If the freelancer holds the keys, you don't have a contractor — you have a dependency.
• Vague about licensing. "I'll use some libraries I built" is fine; "those libraries stay mine under a separate licence" needs to be in writing, with terms you understand. Surprise licence claims surface at the worst possible moment — usually during acquisition diligence.
• Refuses documentation as a deliverable. Code without documentation is a black box with your money inside. Documentation — setup instructions, architecture overview, deployment steps — should be a named deliverable in the contract, not a favour.

COMMUNICATION: THE SLOW KILLER

Bad code gets rewritten; bad communication kills projects slowly. Most failed freelance engagements don't fail on skill — they fail on the founder discovering, six weeks in, that "almost done" meant "barely started".

Red flags:

• Slow or evasive before you've paid. Pre-hire communication is the best they'll ever be. If replies take days and answers dodge specifics now, imagine month three when the money's spent.
• Can't explain trade-offs in plain English. You don't need them to teach you to code, but a developer who can't explain why they're recommending something — in terms you understand — either doesn't understand it themselves or doesn't respect you enough to try. Both are disqualifying when you're the one making the business call.
• No working rhythm proposed. Good freelancers propose a cadence: weekly demo, async updates, shared task board. If they shrug at "how will we track progress?", you're hiring a black box. Agree the rhythm before the contract, not after the first missed deadline.
• Timezone theatre. Some overlap in working hours isn't a luxury — it's how blockers get unblocked. A 12-hour gap with no agreed overlap window means every question costs you a day. If going offshore for cost reasons (a legitimate choice), the overlap plan is part of the deal.
• All yes, no pushback. A freelancer who agrees with everything — every feature, every deadline, every idea — isn't listening. The valuable ones push back: "that'll take three weeks, here's the two-day version." Yes-men ship your mistakes on schedule.

DISAPPEARING RISK: WHAT IF THEY VANISH?

Freelancers get sick, get better offers, take holidays and occasionally just stop replying. The model has no redundancy — that's the trade for the rate. Your job is to make disappearance survivable, not impossible.

Red flags that raise the odds:

• Juggling visibly too many clients. Ask directly how many active clients they have and how many hours a week yours gets. "Full-time on yours" from someone with four active clients is arithmetic that doesn't work.
• No backup plan for absence. Ask: "If you're ill for two weeks mid-project, what happens?" Good answers involve documentation, a handover-ready repo and honest timelines. Bad answers involve "that won't happen".
• Single point of failure by design. If only they can deploy, only they understand the database, and only they hold the API keys, their disappearance isn't an inconvenience — it's a company-threatening event. This is a structure problem you must prevent regardless of how reliable they seem.
• Payment entirely upfront. Never. Milestone-based payment isn't distrust — it's the industry standard for a reason. Anyone demanding 100% upfront is either desperate or planning to be.

None of this means freelancers are unreliable people — most are professionals. It means the structure has no safety net, so you build your own: repo you own, docs as deliverables, milestones, and no single-person secrets.

HOW TO DE-RISK: THE CHECKLIST

Vetting is half the job; structuring the engagement is the other half. Do all of these and a freelance hire becomes one of the safest bets in the startup playbook:

1. Start with a paid trial. A small, real, paid piece of work — a week or two, clearly scoped — before committing to the full project. You learn more from one week of real collaboration than from ten interviews. Our guide to paid trials and handover covers how to structure one properly.
2. Contract before code. IP assignment to you, payment tied to milestones, termination terms, confidentiality. A one-page agreement beats a handshake; a proper contract beats a one-pager. Get it signed before the first commit.
3. Your repo, your accounts, day one. Code in your GitHub/GitLab from the first day. Hosting, domains, app store accounts, third-party services — all in your name, with the freelancer granted access. Revocable access, not shared passwords.
4. Milestone payments, never 100% upfront. Typical split: a small kickoff payment, then milestones tied to working, demonstrable software — not to dates or "progress". Final payment on delivery plus a short warranty window.
5. Weekly demos of working software. Not status reports — software you can click. "Show me" every week catches drift early, when it's cheap to fix.
6. Documentation as a deliverable. Named in the contract: setup guide, architecture overview, deployment runbook. If they vanished tomorrow, could another developer pick it up? That's the test.
7. One technical reviewer. If you're non-technical, pay a senior developer for a few hours to review the code at milestones. It's the cheapest insurance in software — a few hundred pounds to catch problems worth thousands.

Do this and you've converted the freelancer's structural risks into a managed, professional engagement. Skip it and you're gambling — sometimes you win, but the losses are spectacular. Compare the freelancer route against the alternatives in freelancer vs agency vs in-house, and if the project needs a whole team rather than one person, read when to hire an agency — or look at how we run application development engagements.

HIRING FREELANCERS — FAQs