How often should I check in with a freelance developer?

Once a week in writing, plus whatever ad-hoc questions come up. Daily check-ins signal that progress is not visible, which is a problem to fix at the source — with a staging environment and repository access — rather than to paper over with more meetings.

What should a weekly update contain?

What landed, what is next, and what is blocked and on whom. Three lines is a good update. Anything longer usually means the work is being described rather than shown, which is a sign the staging environment is not doing its job.

How do I handle a request that is outside the agreed scope?

Have it named as out of scope when it comes up, with its cost in time attached, then choose: swap it for something already in scope, extend the timeline, or park it. The failure mode is never the change — it is a series of small changes nobody flagged, discovered together at the end.

Managing freelance software engineersGuide — 10 August 2026

Most freelance engagements that go wrong go wrong on communication, not on code. The practices below are the ones that survive not being in the same room — written scope, visible progress, and a defined path for the conversation nobody wants to have.

Manage the outcome, not the hours

The instinct when you cannot see someone working is to ask them to prove they are. It is the wrong instrument: time reports measure attendance, and attendance is not what you bought.

What you bought is a working system, and the honest measure of it is deployed code you can look at. Ask for a staging environment early and check it yourself. A developer whose progress is visible does not need to be asked how it is going — and one whose progress is not visible will not become more productive by being asked.

Put three things in writing, and only three

Written process becomes theatre quickly. These are the ones that earn their overhead:

The scope — what is included, what is explicitly excluded, and what happens when that changes
A weekly written update — what landed, what is next, what is blocked and on whom
Decisions — the choice made, the alternative rejected, and the reason, in a place you can both find in six months

The weekly update beats the weekly call

A standing call is a meeting whether or not there is anything to say, and its output evaporates. A written update takes ten minutes, arrives whether or not schedules aligned, and is still readable six months later when you need to remember why something was built that way.

Keep calls for what calls are genuinely better at: a decision with three plausible options, an ambiguous requirement, or something going wrong. Booking calls for those and not for status is the single change that makes a remote engagement feel calmer.

How to give feedback an engineer can act on

"This does not feel right" costs a day of guessing. The version that costs an hour names three things: what you were doing, what you expected, what happened instead.

For a visual issue, a screenshot ends the discussion faster than a paragraph. For a behavioural one, the URL and the steps matter more than the description. None of this needs technical vocabulary — it needs specificity about what you actually saw.

Scope changes: raise them, do not smuggle them

Every project has them, and the damage is almost never the change itself. It is the pattern where small additions arrive one at a time, each too minor to renegotiate, until the original estimate is unrecognisable and both sides feel misled.

The fix is a norm agreed at the start: anything outside the written scope gets named as such when it comes up, with its cost in time stated. Then you decide — swap it for something already in scope, extend, or park it. Ten seconds of friction each time instead of one bad conversation at the end.

What a healthy engagement looks like from your side

You should be able to answer all of these at any point without asking anyone.

What was delivered last week
What is being worked on right now
Whether anything is blocked, and on whom
Where the current build is running, and whether you can use it
What is in scope that has not been started yet
Who has access to your repository, hosting and domain — and that it is you

When it is not working

Address it early and directly — the alternative is addressing it late and expensively. Name the specific thing rather than the general feeling: a missed date, an update that did not arrive, work that did not match the scope. Then ask what would need to change.

Two things make this survivable regardless of the answer: your ownership of the repository and accounts from day one, and documentation written as work lands rather than promised at handover. With both, ending an engagement is a decision. Without them, it is a hostage negotiation.

Hire a remote developer — how these practices work in an engagement How I work with clients, and what you own

Common questions

How often should I check in with a freelance developer?: Once a week in writing, plus whatever ad-hoc questions come up. Daily check-ins signal that progress is not visible, which is a problem to fix at the source — with a staging environment and repository access — rather than to paper over with more meetings.
What should a weekly update contain?: What landed, what is next, and what is blocked and on whom. Three lines is a good update. Anything longer usually means the work is being described rather than shown, which is a sign the staging environment is not doing its job.
How do I handle a request that is outside the agreed scope?: Have it named as out of scope when it comes up, with its cost in time attached, then choose: swap it for something already in scope, extend the timeline, or park it. The failure mode is never the change — it is a series of small changes nobody flagged, discovered together at the end.