Freelance deal checklist

A better freelance deal starts with fewer assumptions.

Use this checklist to turn a client conversation into a deal both sides can follow. It covers the points that are easiest to skip at the start and most expensive to reconstruct at the end.

Create a Dealokr deal Use the guide

Dealokr protects the deal journey and its record. Payment processing remains with the configured provider.

The framework

Use the checklist in the order the client experiences the project.

This is not a legal template. It is an operating checklist for a clear deal. Apply the level of detail that fits the work, then obtain professional advice where the project or jurisdiction requires it.

1. Define
Make the outcome tangible
Write a one-sentence result, the client decision-maker, the total price, currency, and realistic timing.
2. Agree
Turn the scope into rules
List deliverables, exclusions, revision boundaries, relevant rights, and the payment sequence.
3. Start
Make the next action obvious
Give the client the agreement and provider payment route before production begins.
4. Review
Separate preview from final handoff
State what they are reviewing, how feedback works, and which assets stay controlled until release.
5. Close
Record the final decision
Keep approval, release, key messages, and references with the project record.

Put it into practice

Make the next action unambiguous.

Use these prompts to turn a broad payment intention into a workflow that a client can understand without a long explanation.

The one-sentence test: can the client repeat the outcome?

If the project cannot be described in a plain sentence, it is difficult to price, approve, or complete. Start with the intended outcome, then list the concrete deliverables that prove it has been achieved.

A category is not a scope. “Website design” is a category; “a responsive five-page marketing site based on the approved wireframe, excluding copywriting and custom illustrations” is closer to a usable scope.

Clarify the boundaries that cause expensive surprises.

Most scope drift comes from invisible assumptions: how many revisions are included, whether source files are included, who supplies content, what counts as a delay, and whether a new idea belongs to this phase. Write those points early in language the client can understand.

If commercial usage rights, personal data, regulated work, or a high-value contract is involved, get advice appropriate to the jurisdiction and deal.

Treat delivery as a sequence, not a single upload.

A client may need to inspect work before you release the final package. Distinguish the review version from final exports, editable sources, credentials, or production files. State the action expected from the client and how an approval or revision request is recorded.

This makes the close of the project feel organised rather than adversarial.

Working checklist

The full pre-flight checklist

Use the sections below as a working checklist. They are grouped by project moment so you can use only what applies.

Before you quote

The desired outcome is written in one sentence.
The buyer, project contact, and approver are identified.
The price, currency, tax treatment where relevant, and timing are understood.
Known dependencies, client inputs, and deadlines are stated.

Before you send terms

Deliverables are concrete files, services, or outcomes.
Exclusions and revision boundaries are written plainly.
Rights, source-file inclusion, and third-party assets are addressed where relevant.
The payment step and what starts after it are visible.

Before you begin

The client can review the terms and ask questions.
The configured provider payment action is clear.
The project start condition is known to both sides.
The working version and communication route are agreed.

Before you deliver

The review version is separated from final or source assets.
The client knows what to check and who can approve.
A revision request can be tied to the relevant version.
External file links are shared with appropriate access controls.

Before you close

Approval or the agreed review outcome is recorded.
The final release matches the accepted scope.
The agreement, payment status, delivery, and key messages stay findable.
Your invoice and accounting obligations are handled in the right system.

Client-ready wording

Useful language for the moments that matter.

Use these as starting points, then replace the bracketed details with the real scope, timing, and decision for the project. They are practical prompts, not legal clauses.

Client-ready summary

Use this before sending terms.

“Here is the project summary: [outcome], [deliverables], [timeline], and [price]. The link also shows the payment step, review route, and final handoff so we both know what happens next.”

Why it helps: it turns a dense proposal into a simple client decision.

Approval request

Ask for a clear response, not a vague reaction.

“Please approve this version if it meets the agreed criteria, or send the revision points by [date]. Once that is complete, I will proceed with the final release described in the deal.”

Why it helps: the client is told what to review, how to respond, and what their response changes.

Project close

Give the record a clean ending.

“The project is now complete: the approved deliverables and final release are recorded in the deal. Please keep the link as the reference for the agreement, delivery, and handoff history.”

Why it helps: it makes the closing state visible if someone returns to the project later.

Helpful context, not legal advice

Payment terms should be explicit and suitable for the deal.

Late-payment rules and remedies vary by country, customer type, and contract. The sources below explain why written payment terms and a documented payment request matter; check the rules that apply to your own situation.

Common questions

Clear answers before the project gets complicated.

What should be in a freelance deal before work starts?

At minimum: the outcome and scope, price and payment timing, deliverables and exclusions, revisions, deadline or delivery window, approval path, relevant rights, and final-file handoff conditions.

Can I use this checklist outside Dealokr?

Yes. It is designed as a practical operating checklist. Dealokr gives you a shared place to turn the information into a deal record, client link, delivery workflow, and proof timeline.

Does this checklist replace a contract or legal review?

No. It helps you prepare the commercial facts a good agreement needs. The legal effect of any document depends on the parties, the terms, and the applicable law.

A protected next deal

Protect the payment journey and final handoff in one deal.

Start with clear terms, a protected payment journey through the configured provider, and protected delivery instead of trying to reconstruct the project at the end.

Create a Dealokr deal See how it works