Define freelance deliverables: turn the brief into a clear scope.

Gather a brief that supports clear decisions.

Start with the client’s situation: why are they starting this project now, who is the result for, and which problem do they want to solve? A brief becomes useful when it gives enough context to choose the work required. A long list of wishes needs discussion and priorities.

Ask questions that change the proposal

Ask what already exists, what works and what should change. Identify the audience, intended use and main priority. For a website, the need might be to explain an offer more clearly or make contact easier. Those objectives do not necessarily require the same pages or functionality.

Explore the constraints next: a date tied to an event, budget, required tools, available content or an internal approval process. Ask for references and what the client likes about them specifically. A preference about readability or tone gives you more information than a link sent without explanation.

Identify missing answers and who can supply them

Find out who uses the result, who provides resources and who can make decisions. If the client does not yet know an answer, propose clarifying it before pricing the affected work. You can plan a scoping phase when discovery itself requires work, with defined contents and a price, rather than estimating from assumptions neither party has confirmed.

Restate the need before turning it into scope.

After the initial exchange, write a short summary covering context, objective, audience, constraints and remaining decisions. Ask the client to correct anything that does not match their intention. Restating the brief helps separate confirmed facts, your proposals and assumptions that still need an answer.

Follow a fictional example from brief to deliverables

Consider a fictional consulting firm that wants to explain its offer more clearly before an event. It asks for a “website redesign”. After discussion, the agreed project covers designing three pages for desktop and mobile. The firm supplies copy and images; building the website is outside this phase.

The summary could say: “Prepare the structure and mock-ups for the Home, Services and Contact pages to present the firm’s offer. The client will supply content before detailed design begins.” This wording identifies the result and dependencies without promising a live website.

Have the basis for the proposal confirmed

Ask for a response on the scope understood and open points. If the client also expects copywriting or publication, the difference appears in time to adapt the offer. The brief then informs the project documents. Keep the outcome of discussions with the version used for pricing and agreement, so later decisions can return to the same reference.

Write deliverables both parties can recognise.

For each deliverable, explain its contents, quantity and format. Add useful criteria for checking that it matches the order. The reader should understand what they will receive without knowing your internal process or having to guess what a term such as “design”, “strategy” or “support” includes.

Turn the need into a deliverables list

The quantities here are fictional project choices. For consulting, you could describe interviews, analysis and a presentation; for a video, duration, versions and exports. The principle is to name results that make the work observable, with enough detail for the client to understand the order.

Connect the list to the shared basis

In Dealokr, include the deliverables and their boundaries in the project terms. The client can compare the work presented with what was agreed. If an appendix details the list, keep a clear reference and version so two different descriptions do not circulate.

Distinguish formats, versions, source files and uses.

A deliverable may take several forms: preview, final export, editable file, documentation or link to an external service. Describe what is actually included and the expected state of each item. Receiving a PDF, accessing a design file and taking over a project in its software meet different needs.

Specify the package and its dependencies

For the web example, decide whether mock-ups will be provided in a Figma file, as exports or both. Identify the pages and reference version. Also explain what another provider needs to take over: styles, linked resources, software or necessary licences.

If editable sources are included, describe them without implying that every working file is included. An abandoned draft and the selected version have different places in the handoff. External items should also remain identifiable, with an owner and suitable access, so the client knows which material belongs to the final arrangement.

Treat permitted uses as a separate decision

Discuss the files to hand over separately from how the client wants to use them. Check planned third-party resources, such as fonts, images, music or components, depending on the service. Identify who supplies licences and any restrictions to address in the agreement. Have wording reviewed for a sensitive rights question.

Permissions for a Figma workspace or code repository are managed in the relevant service. Exports hosted in Dealokr and access to a third-party tool therefore need separate descriptions, so the client knows what they can retrieve and where.

Record exclusions and the client’s contributions.

A deliverables list becomes clearer when related work is addressed explicitly. In the example, page design does not include implementation. Copywriting, photography, licence purchases and support after launch are also decisions to make, according to the needs and budget. Leaving them unstated can make the same proposal mean different things to each party.

Explain what could be added

Describe exclusions with their practical consequences: the client provides text, another provider handles implementation or an option can be considered. This helps organise the project. It avoids discovering during review that one party expected a broader result than the one planned.

If the client later requests a fourth page or complete copywriting, describe the need and its effect on price and timing. You can offer an option, a change in priorities or another phase. Have the decision confirmed before adding that work to the plan.

Make client contributions usable

Request specific items and a date: reviewed copy, the reference logo, authorised images, access or sample data. Identify who collects them and who answers questions. If a resource is missing, explain which task depends on it and agree a realistic next step rather than allowing an unexplained delay to emerge.

Agree review criteria and how feedback will be handled.

Before production, define the points used to examine each deliverable. They should match the scope and make sense to the client. Planned sections, required content or a described behaviour are easier to discuss when connected to an identifiable version and shared references.

Separate the project objective from deliverable review

The fictional firm wants more contact enquiries. That ambition informs design, but it is not checked in the same way as the presence of a Contact page in a mock-up. Distinguish the result you provide from commercial effects that also depend on content, traffic and how the website is used.

For visual or editorial choices, agree a direction, references and priorities. The client should know what they are examining and how to express feedback. Identify who consolidates comments and the planned review arrangements, so you receive a coherent response rather than several conflicting instructions.

Distinguish a mismatch, revision and new need

If an agreed section is missing, examine that mismatch against the order. A presentation adjustment may fall within the planned revisions; a new page or different objective may change scope. Do not put every response in the same category. Restate the request and decide how to handle it using the agreement.

In Dealokr, the preview allows the client to review the work and request the planned revisions. Written deliverables and the presented version give that discussion a basis. You can connect feedback with what was planned, clarify open points and agree the next version.

Connect deliverables with dates, dependencies and handoff.

A precise list also needs to fit a realistic schedule. Identify stages, expected contributions and review points. If design depends on the client’s text, make that connection visible. A presentation date and a final handoff date can differ and should be understood as separate events.

Plan the sequence before the first file

For each stage, identify the result presented, who responds and what follows. If something still needs confirmation, distinguish work that can begin from work depending on that answer. Handoff arrangements are prepared through the scope, before the last exports, rather than left for the final message.

For fixed-price work in Dealokr, the client pays 100% before production through Stripe Connect. You then present a preview and handle the agreed revisions. You request the transfer under the project’s conditions; confirmation opens access to hosted final files. The bank payout remains separate, and external service permissions are managed in those services.

Read the scope from the client’s perspective

Before asking for acceptance of the proposal, check that the client can name what they will receive, their contributions, the boundaries and the review process. Clarify wording that requires guesswork. You then have a reference for pricing, producing and examining the work on a shared basis.