What Agencies Get Wrong When Hiring Freelance Developers

I've been freelancing for sixteen years. In that time, I've worked with agencies that made the experience brilliant and agencies that made me question my career choices. The difference was almost never about the project. It was about how the agency managed the relationship.

If you're an agency that's been burned by freelancers, I've got some uncomfortable news: there's a decent chance it was your fault.

Not entirely. There are genuinely bad freelancers out there. But I've watched good developers produce terrible work because the agency set them up to fail. Here's how.

Mistake 1: Treating Freelancers Like Employees (Without the Benefits)

This is the big one. Agencies that expect freelancers to:

• Be available 9-5 every day
• Attend every meeting
• Be exclusive to their work
• Respond to Slack within minutes
• Take on admin and internal tasks

...while also offering:

• No holiday pay
• No sick pay
• No pension contributions
• No job security
• Payment terms of 30-60 days

Pick a lane. Either hire someone full-time and give them the benefits, or accept that freelancers manage their own time and have other commitments. You're paying for output, not attendance.

The best agencies I work with don't care what hours I keep. They care that the work gets done, the quality is right, and I'm available when needed for calls and collaboration. If I want to do three hours in the morning and five hours in the evening, that's my business.

Mistake 2: Vague Briefs

"Make it modern." "It needs to feel premium." "Can you just build the dashboard?"

These are not briefs. These are vibes. And they lead to one of two outcomes: the developer builds what they think you want (and you hate it), or the developer spends hours asking clarifying questions (and you complain they're slow).

A good brief for a freelancer should include:

• What you're building (specific features, not concepts)
• Why it matters (business context — what problem does this solve?)
• Who it's for (user type, technical level, expectations)
• Acceptance criteria (how do we know it's done?)
• Design files (if applicable — and not a Dribbble link, actual Figma files)
• Technical constraints (existing codebase, hosting, third-party integrations)
• Timeline (realistic, with reasoning)

I've had agencies send me a three-line Slack message and expect a full feature built from it. Then they're shocked when the result doesn't match what they had in their head. Of course it doesn't. You didn't tell me what was in your head.

Mistake 3: Not Giving Code Access

This one baffles me every time. An agency hires a developer, then refuses to give them access to the repository, the staging environment, or the production database.

"We'll give you a zip of the codebase." "You can push code and we'll merge it." "We don't give external people access to our servers."

I understand the security concern. I do. But if you don't trust a developer enough to give them code access, you shouldn't be hiring them. Full stop.

The workaround — sending zips back and forth, having someone internally merge code — adds days to every task. It makes debugging impossible. It means I can't run the application locally without spending half a day setting it up from an incomplete export.

If you're worried about security, there are sensible middle grounds:

• Give repo access but not deployment access
• Use branch protection rules
• Require PR reviews before merging
• Use a separate staging environment
• Rotate credentials after the engagement ends

But don't hobble the developer and then complain about slow delivery.

Mistake 4: Micromanaging Hours Instead of Outcomes

"Can you log your hours in our time tracker?" "We need a breakdown of how you spent each hour." "You logged 6.5 hours on Tuesday but only committed twice — what happened?"

I get it. You're billing clients by the hour, so you need to track hours for invoicing. Fine. I'll log my time. But the moment you start auditing my hours against commits, you've crossed a line.

Development isn't assembly-line work. Some of the most valuable hours are spent reading code, understanding a system, thinking about architecture, researching approaches. None of that produces commits. All of it makes the commits that follow dramatically better.

Focus on outcomes instead:

• Was the feature delivered on time?
• Does it meet the acceptance criteria?
• Is the code quality acceptable?
• Were there any issues in QA?

If the answer to all of those is yes, it doesn't matter whether I spent 20 hours or 30 hours getting there. If you're paying a day rate, you're paying for expertise and outcomes, not for someone to keep a seat warm.

Mistake 5: No Feedback Loop

The freelancer delivers. The agency goes quiet. Two months later, you hear the client had issues, or the feature needed rework, or the project was "fine but not quite what they wanted."

Nobody told the developer.

Without feedback, I can't calibrate. Maybe my code was brilliant but the feature was spec'd wrong. Maybe the code worked perfectly but the design was off. Maybe everything was great and the client was just difficult. I don't know, because nobody closed the loop.

The agencies I work with long-term all do the same thing: they tell me how it went. "Client loved it." "QA found two bugs, here's the tickets." "This worked well but next time let's do X differently." That feedback makes every subsequent project better.

Mistake 6: Underpaying and Expecting Magic

A good senior developer costs money. If you're comparing my rate against someone on Upwork who charges a third of the price, we're not competing for the same work.

What you get from a cheap developer:

• Code that works but is unmaintainable
• No tests
• No documentation
• Disappears when things break
• You'll pay someone else to rewrite it in six months

What you get from a proper senior:

• Code that's maintainable and follows your standards
• Tests that catch regressions
• Clear documentation and PR descriptions
• Someone who flags risks before they become problems
• Code you can hand to your internal team without a translation guide

The cheapest option is almost never the cheapest option. I've rebuilt more systems than I can count that were originally done on the cheap. The agency pays twice: once for the bad version and once for the good one.

Mistake 7: Moving Goalposts

"Just one more thing." "Can you also..." "While you're in there, could you..."

Scope creep is the silent killer of freelance relationships. And it's almost always the agency that causes it, because they're managing their client's expectations poorly and passing the pressure downstream.

If the scope changes, the timeline changes. If the timeline changes, the cost changes. This isn't me being difficult. This is basic project management. Every "quick addition" has to be designed, built, tested, and deployed. Even if the code change is small, the surrounding work isn't.

The fix is simple: when the scope changes, acknowledge it. "This is new scope. It'll add two days. Here's the updated estimate." Freelancers who just absorb scope changes without pushing back end up resentful and rushed. Neither produces good work.

What Actually Works

The agencies I've worked with for years — five, eight, even ten years — all share these traits:

Clear briefs with acceptance criteria. I know what done looks like before I start.

Outcome-focused management. They care about what I deliver, not when I'm online.

Full technical access. Repos, staging, CI/CD. Everything I need to be effective.

Regular communication. Not micromanagement — just normal team communication. Standups, Slack, quick calls when needed.

Fair rates paid on time. Nothing destroys a relationship faster than chasing invoices. The best agencies pay within 14 days. Some pay on completion. All of them pay without me having to ask twice.

Trust. They trust me to flag problems, make good technical decisions, and deliver quality work. In return, I trust them to provide clear briefs, pay on time, and include me in decisions that affect my work.

It's not complicated. Treat freelancers as partners, give them what they need to succeed, and hold them accountable for outcomes. Do that, and you'll never have a bad freelancer experience again.

Well. Almost never.

---

I've been embedded in agency teams for over a decade. If you're looking for senior development capacity you can trust, let's talk.