Part of How to Make Money Online with Digital Skills: A Beginner’s Roadmap.
Manage a freelance project by keeping the brief, decisions, work, reviews, and handover visible from the start. A useful process tells both sides what happens next, what information is needed, and how the finished work will be checked.
In this guide
The process can be simple. A small project may need a brief, a task list, a shared review record, and an organised delivery folder. The amount of administration should fit the work and its consequences.
Read the text version: Show the dependencies before handover
The fictional project includes two agreed outputs: a square announcement and a printable sheet.
- The client supplies approved text, logo and formats. The designer confirms the brief and acceptance checks. If necessary approved inputs are missing, hold the affected work.
- The designer builds the two drafts. The client supplies consolidated feedback.
- The designer applies the agreed changes and returns the revised outputs for the client’s approval.
- After approval, the designer inspects the actual exports and hands over the named files and notes. The client confirms receipt.
If the client requests a third format, estimate and agree that additional output before producing it. Approval of the two existing outputs is not an instruction to create an extra one. The arrows show information and approval dependencies rather than measured durations.
Practical summary
- Clarify: agree on the task, deliverables, and conditions.
- Prepare: collect approved inputs and appropriate access.
- Produce: work in controlled versions and communicate progress.
- Review: compare feedback with the agreed brief.
- Check: inspect the actual deliverables.
- Hand over: explain files, ownership arrangements, and support.
Confirm the brief before production
Restate the client’s purpose, audience, requested outputs, and constraints. Identify the materials they will supply, the decisions they must make, and the assumptions still unresolved.
Write acceptance criteria: conditions that help both sides decide whether the deliverable meets the brief. For a video, these might include approved wording, accurate captions, agreed format, and complete playback. For a website, they might include the named pages, working navigation, and specific functional checks.
Agree on scope, timing assumptions, review arrangements, payment terms, and any legal requirements appropriate to the engagement. The service-package worksheet helps organise the operational details; it is not a substitute for a suitable contract where one is needed.
Collect inputs and set up the working environment
Use an intake checklist for source files, approved copy, access, asset permissions, and contact details needed for the project. Confirm who can approve changes and how feedback will be collected.
Ask for access appropriate to the task. Use the client’s authorised sharing or account process, rather than collecting credentials casually. Make a backup or preserve an original copy before changes that need a recovery route.
For work on a live system, clarify whether a staging or draft environment is available and who authorises a live change. Creating a design or draft does not automatically authorise publishing it, sending messages, spending money, or changing customer-facing functionality.
Plan milestones around reviewable results
A milestone should name an output or decision. “First version ready for review” is more useful than “work in progress.” Include dependencies such as receiving final copy or approval of a design direction.
| Milestone | Reviewable result | Decision needed |
|---|---|---|
| Brief confirmed | Written scope, inputs, deliverables, and checks. | Both sides understand the intended work. |
| Initial version | A coherent version suitable for the agreed review. | Consolidated feedback against the brief. |
| Revised version | Approved changes applied and documented. | Whether remaining comments are corrections or new scope. |
| Final checks | The actual output inspected in its delivery format. | Any material issues resolved or clearly recorded. |
| Handover | Organised files and instructions. | Receipt and any agreed completion steps confirmed. |
Give updates that help the client act
A useful update says what is complete, what is next, what is blocked, and what decision is needed. Match the frequency to the project rather than sending repeated messages without new information.
Fictional update: “The first edit is ready and the captions have been checked against the recording. I still need the approved spelling of the guest’s surname before the final export. Please send that detail with your consolidated feedback. The additional landscape version is outside the current brief; I can estimate it separately.”
If timing changes, explain the cause and its effect early. Distinguish your own delay from missing client information without using blame as a substitute for a practical next step.
Read the text version: Write an update that helps the client act
This is a fictional status note for an educational-video edit.
The first edit is ready. Captions were checked against the recording.
The next step is the final export after the remaining review.
I still need the approved spelling of the guest’s surname.
Please send that spelling with your consolidated feedback.
The annotations identify complete, next, blocked and decision. The note states what can proceed and what information is needed. An additional landscape version is outside this fictional brief and requires a separate scope discussion. In real work, report only checks you actually completed and name the relevant version.
Handle feedback and scope changes explicitly
Read feedback against the approved brief and version. Correct your own errors. Clarify unclear comments. Group related changes so they can be assessed together.
For a new requirement, explain the effect on deliverables, effort, price where applicable, and timing before starting it. Record the agreement. If you decide to include a small extra without charge, make that decision clear so it does not silently redefine every future project.
Keep a decision log with the date, request, agreed action, responsible person, and affected version. The log can be a simple table. Its purpose is to prevent different understandings of the same conversation.
Check the delivered result, not only the working file
Exports, uploads, and handovers can introduce problems that were not obvious in the editor. Open the actual files you will send and test the relevant experience.
| Work type | Examples of checks |
|---|---|
| Design | Approved wording, readable text, required dimensions, asset permissions, and correct exports. |
| Video | Complete playback, intelligible sound, accurate captions, approved material, and correct format. |
| Website | Affected links, forms where in scope, headings, responsive layout, permissions, and rollback information. |
| Spreadsheet or admin work | Sample calculations, missing and duplicate records, access permissions, and clear instructions. |
| Audit or report | Evidence for findings, distinction between observations and assumptions, clear priorities, and accurate limitations. |
Use checks appropriate to the task rather than treating this list as exhaustive. Document what was checked and what remains outside scope. A screenshot of a page does not prove its form or payment flow works.
Make the handover usable
Deliver the agreed exports and source files, if included, with meaningful names. Explain which file is final, what software or access is needed, and any third-party licences or dependencies the recipient must understand.
State the agreed support period and what it covers. Distinguish correcting a delivery issue from new features, new content, or ongoing maintenance. Confirm that the recipient can access the files and understands the next steps.
Follow the agreed process for returning or removing access and retaining or deleting project data. Do not make unilateral changes to client accounts or confidential records during handover.
Copy this project workflow checklist
| Stage | Complete before moving on |
|---|---|
| Brief | Purpose, audience, inputs, outputs, scope, checks, timing, and commercial arrangements are clear. |
| Preparation | Permissions, approved materials, backups, working environment, and decision-maker are confirmed. |
| Production | Versions are organised and progress or blockers are communicated. |
| Review | Feedback is consolidated; corrections and new scope are distinguished. |
| Quality | The final deliverables are checked against the brief and evidence is recorded. |
| Handover | Files, instructions, access, support boundaries, and completion steps are understood. |
| Review your process | Record the estimate versus actual work, repeated problems, and one improvement. |
Worked example: an event-design project
Fictional scenario: A client requests a square event announcement and a printable version. The designer confirms the text, supplied logo permissions, intended sizes, and one consolidated review round.
The first version reveals that the supplied venue name is too long for the initial layout. The designer adjusts the hierarchy and explains the change. During review, the client requests a third format. The designer estimates that extra output before producing it.
Before handover, the designer compares both agreed versions with the approved text, opens the exports, and checks their dimensions. The delivery note identifies the final files and explains the agreed source-file arrangement. The record shows what was delivered; it does not invent a claim about event attendance.
Frequently asked questions
What if a client gives conflicting feedback?
Identify the conflicting instructions and ask the agreed decision-maker to confirm one direction. Record the decision before applying changes that would be difficult to undo.
What if I discover a problem outside my ability?
Preserve the current work, explain the problem and its effect, and agree on a response. That may involve narrowing scope, obtaining qualified help with permission, or stopping the affected work. Avoid experimenting on a live client system beyond your capability.
What should I confirm before starting a freelance project?
Confirm the purpose, audience, outputs, required inputs, acceptance checks, review process and timing assumptions. Clarify the commercial arrangements and who can approve decisions. Write down unresolved questions before production begins so that both sides understand the proposed work.
How often should I update a client?
Agree on a rhythm that fits the project and provide updates when a decision or material change matters. Explain what is complete, what comes next and what is blocked. A useful update helps the client act; repeated messages without new information can add noise.
What should I do when the client asks for extra work?
Compare the request with the agreed brief. Explain any effect on deliverables, effort, timing and price, then record the decision before starting. If you include a small extra without charge, make that choice explicit so it does not silently change future expectations.
What should my final handover contain?
Provide the agreed final files with clear names and instructions, identify relevant dependencies and explain support boundaries. Confirm the recipient can access and use the delivery. Follow the agreed process for account access and project records, and document anything that remains unresolved.
Review one project and improve the next
After completion, compare your estimate with the actual work and note where the process became unclear. Use the sustainable-growth guide to turn those observations into better scope, reliable capacity, and appropriate repeat work.