Articles · Hiring

2027-03-12 12 min EN / FR

Warning signs when hiring a freelance developer

Most bad freelance projects do not fail on day ninety. They fail in the first week of emails, in a vague quote, or in habits nobody corrected. Warning signs are cheap to spot early and expensive to ignore once the code lives only in someone else's laptop.

This is not a list of reasons to distrust freelancers. Many of the best builders work independently. It is a list of patterns that predict lock-in, surprise invoices, silent single points of failure, and a handover that never happens. One or two soft signs can be talked through. A cluster of hard ones means walk away, or redesign the engagement before money moves.

First contact

The first messages already show how the work will feel.

  • They never restate your problem. They reply with a price or a stack before they show they understood the outcome you need. A useful first reply paraphrases the goal, names uncertainties, and asks for missing facts.
  • They push a tool before a problem. "We should rebuild this in X" without asking what hurts today is sales, not diagnosis. A short discovery workshop exists to avoid that trap.
  • They refuse to talk ownership. If accounts, domains, and code repositories are "details for later", treat that as a decision already made against you. Run a quick account ownership audit mindset from day one.
  • References are vague or unreachable. "I did stuff for a big brand" with no contact, no public artefact, and no comparable scope is noise.
  • Pressure to start this week. Urgency can be real on your side. Urgency used as a reason to skip a brief, a quote, or a contract is a red flag on theirs.
  • Communication only on a private chat they control. Decisions, scope, and approvals should leave a trail you can export (email, tickets, a shared doc you own).

Quote and contract

A thin commercial document is often the first concrete warning. Pair this section with reading a quote: what is missing from most of them and with contract clauses to demand from any tech provider.

  • Scope is a slogan. "Build the app" or "fix the site" without deliverables, out-of-scope list, or acceptance criteria.
  • No environments, no handover, no documentation. If staging, deployment, admin access, and a written handover are absent, you are buying a demo, not a system you can run.
  • Accounts stay in their name. Hosting, domain, Git, analytics, payment, or AI provider under their personal email means they can leave with the keys. Fix it in writing before kickoff.
  • IP and source stay unclear. You need assignment or a licence that lets another developer continue without their permission. Silence here is a future dispute.
  • Payment is front-loaded with no milestones. A large deposit can be normal. Paying almost everything before you see working increments is not.
  • No change process. When new requests have no estimate path, either you get silent overruns or endless free extras that breed resentment.
  • They will not sign basic protections. Refusal to discuss exit, access, backups, or no-withholding of credentials is louder than any portfolio slide.

If the quote looks fine but the contract dodges ownership, believe the contract.

Way of working

Ask how the engagement will run before you care which framework they prefer.

  • No written updates. "I'll ping you when it's done" hides slip and blocks decisions. Weekly written progress (done, next, blockers) is a minimum for anything longer than a few days.
  • Code lives only on their machine. Your organisation should own the repository from the first commit, with you as admin.
  • No staging you can open. Production-only delivery means every change is a live risk and you never review early.
  • Secrets in chat or spreadsheets. Credentials should land in a vault you control, not in WhatsApp history.
  • They discourage questions. Defensiveness when you ask about backups, monitoring, or who can deploy is a sign, not a personality quirk.
  • Everything is custom, nothing is documented. Clever code without a runbook becomes a liability the day they are unavailable.

Want a second pair of eyes before you hire?

We can review a brief, a quote, or an engagement setup so ownership and handover are clear before the first invoice.

Describe the hire Custom solutions

During the project

Early habits that do not improve usually get worse after go-live.

  • Missed dates with no rewritten plan. Slip happens. Silence and "almost done" without a new date or reduced scope is the problem.
  • Scope grows, price stays magical. Either the budget is fiction or the quality is being cut where you cannot see it.
  • You cannot log in as admin. If only they can deploy, restore, or change DNS, you already failed the ownership test.
  • No backups you have tested. "The host does backups" is not enough. Read backups that actually restore.
  • Production data copied into tests. A quiet GDPR and security failure. See GDPR and test environments.
  • AI or third-party tools plugged in with their keys. Same ownership problem as hosting. Keep company accounts and limits, as in adding AI without handing over the keys, and put AI use in the contract.
  • Documentation deferred forever. "We'll write it at the end" often means never. Demand artefacts as you go: see the documentation you should demand at delivery.
  • Hostility when you involve another reviewer. A short technical review by someone else is normal. Panic or refusal is not.

How to reduce risk

Warning signs are half the story. Structure does the rest.

  • Write a brief before you ask for prices. Comparable quotes need a shared problem statement. Start with how to brief a developer so you get a useful quote.
  • Prefer a paid discovery when the problem is fuzzy. A fixed-price build on an undefined problem is how budgets disappear. A discovery workshop style phase buys clarity.
  • Own accounts from day one. You create them, or they create them under your org and transfer admin before serious work.
  • Require an exit plan in the engagement. Inventory, access, code, backups, handover: the shape is in the exit plan every client should require.
  • Pay against milestones you can verify. Working software in your staging, repository access, and docs for what was built.
  • Name a client-side owner. Someone who answers questions within days, not weeks. Freelancers fail when the client vanishes too.
  • Plan offboarding while they still answer email. Access removal and secret rotation are easier before the relationship cools. Use the offboarding checklist at the end, not as an emergency.

Revealing questions

Ask these in writing. Vague or evasive answers are data.

  • Who will own the domain, hosting, Git, and third-party accounts at kickoff and at delivery?
  • Where will the code live, and who are the admins on day one?
  • What does "done" mean for the first milestone, in testable terms?
  • What is explicitly out of scope?
  • How do you handle change requests (estimate, approval, impact on date)?
  • How often will we get a written status, and in what channel we own?
  • What documentation is delivered, and when (not only "at the end")?
  • How do backups and restores work, and when was the last restore test?
  • If you disappeared for a month, what would another developer need, and where is it?
  • Do you use AI tools on this project, with whose accounts, and on which data?
  • Can we book a short call with a past client on a similar project?

Two-sided problems

Some failures are mutual. A skilled freelancer still fails when the client side is chaotic.

  • No decision maker. Three people give conflicting priorities and nobody owns the final call.
  • Moving target with a fixed price fantasy. You change the product every week and still expect the original number and date.
  • Content, access, or approvals always late. The developer waits, then gets blamed for the calendar.
  • You hire on price alone. The cheapest bid often omitted the work you assumed was included.
  • You never read the quote. Surprises at invoice time were often written in the exclusions you skipped.

Clean your side of the table: clear brief, one owner, timely answers, and a contract you actually understand. That makes real warning signs on the freelancer side easier to see.

Checklist

Before you hire

  • Brief written, shared with every candidate the same way
  • At least one candidate restated the problem and named risks
  • Quote lists scope, out of scope, assumptions, and ownership
  • Contract covers IP, accounts, handover, access, and change process
  • You know who creates and administers every critical account
  • References or comparable work checked where the stake is high

During the work

  • Repository and staging under your control
  • Weekly written status with blockers
  • Credentials in your vault, not only in theirs
  • Milestones accepted against criteria, not vibes
  • Docs and runbooks growing as features land
  • Backups and test-data rules followed

At the end

  • Admin access transferred and verified by you
  • Source, docs, and deploy path usable by someone else
  • Exit inventory complete (accounts, secrets, dependencies)
  • Offboarding done: access removed where the freelancer no longer needs it
  • Warranty or bug window dates written down
  • Maintenance terms clear, or a clean stop with no hostage access

Related

Hiring and want the engagement set up cleanly?

Write us before kickoff if you want ownership, milestones, and handover baked in from the start.

Start a conversation All articles