How to Write a Freelance Contract for Interactive Work (2026)

To write a freelance contract for interactive work, you turn a loose project brief into eight written sections: parties, scope of work, fees and payment schedule, schedule and approvals, revisions and change requests, intellectual property, confidentiality and independence, then cancellation and handoff. Both sides sign it before any build starts. It takes an afternoon for a small project, a full day for a multi-month engagement.

This guide is for freelance interaction designers, UI and motion designers, game and prototype developers, and the small studios and publishers who hire them. It is general information, not legal advice. Rules differ by country and state and change over time, so have a qualified attorney in your jurisdiction review anything you sign.

The reason interactive work needs a written contract more than most fields is that it expands quietly. A prototype becomes a production build, three screens become twelve, a two-week sprint becomes a rebrand. Without itemised deliverables, an exclusions list and a revision cap, none of that shows up as a disagreement until the invoice.

Ask anyone who freelances for media and you will hear the same pattern: a client agrees a fee for a defined body of work, then asks for much more at the original price, and the conversation turns into who absorbs the difference. A contract does not prevent that conversation. It decides the terms of it in advance, while everyone is still being reasonable.

What You Need

Gather these before you type a clause, because each one is a decision you cannot draft around later:

• The project brief — whatever the client sent, including the messy version.
• A written scope of work — deliverables, platforms, technical assumptions and explicit exclusions.
• A quotation or budget — the total fee, the rate, or both.
• A schedule — start date, target delivery date, and review windows.
• Payment milestones — which amount lands at which build stage.
• Revision limits — a number of rounds per deliverable, not the word “unlimited”.
• Usage rights — who owns what, where, for how long, and what transfers at handoff.
• The contracting parties — full legal names, addresses and a named contact on each side.

For interactive projects, add the items that generic freelance templates leave out: whether the deliverable is a prototype or a production build, whether staging or production hosting is included, which design and source files transfer at handoff, which third-party assets and open-source libraries are in play, and whether there is a support window after launch.

A template is a starting point. Freelance designers tend to describe a workable contract as “simple but clear” — scope, timeline, payment, revisions, ownership, nothing copied wholesale from the proposal. That advice holds. A reusable template saves you an hour; it does not replace a review by someone who knows the law where you and your client sit.

Producers building embedded or physical prototypes hit the same wall in a different place. People working with Arduino hardware stress fixing the scope documents first — a scope sheet, a flow diagram, a prototype bill of materials, mock UI screens — before writing contract terms at all. Agreeing what the thing is makes the contract easy.

How to Write a Freelance Contract for Interactive Work: Step by Step

Eight sections, in the order below. Each one produces a specific clause or output, and each has a simple test for whether it is finished.

1. Define the Parties, Project, and Working Relationship

Open with the legal names and contact details of both sides. An individual contracting as a sole proprietor, a registered company, and an agency all need to be named precisely, because a contract signed by the wrong entity is a contract you may not be able to enforce.

Describe the project in one short paragraph: what it is, what platform it runs on, what audience it serves, and the working name both sides will use in emails. Then state who owns the commissioned work, and whether the relationship is independent contractor or employment.

Add a notices clause. Say that notices are valid when sent to the email addresses listed, and that a change of address has to be communicated in writing. It sounds bureaucratic until the client goes quiet and you discover the person you emailed three weeks ago left the studio.

How to know it is complete: both parties are named with legal entities and addresses, the project can be identified from the description alone, and there is a named contact for notices on each side.

2. Turn the Project Brief into a Detailed Scope of Work

A brief describes intent. A scope describes deliverables. Convert one into the other: list each artefact by name, then add the assumptions it rests on and the things it deliberately does not include.

A scope of work answers six questions: what is delivered, in what form, on what platform, against what technical assumptions, with what excluded, and who does what.

Itemise rather than summarise. “Primary logo, secondary logo, icon mark, colour palette and a six-page usage guide” is enforceable. “Brand identity package” is not. The same applies to interactive work: “responsive navigation prototype covering four key screens, delivered as a clickable staging build and a documented interaction spec” beats “help with the website”.

Include an exclusions list. It is the section most freelancers skip and clients most need. Write down what is out of scope — content migration, custom animation beyond the agreed set, accessibility audit, ongoing maintenance after the support window closes, additional platform builds, native app versions, copywriting, photography.

Add technical assumptions. Interactive work inherits whatever the client already has: an existing component library, a CMS with specific plugins, a hosting account, analytics, a design system, third-party API access. Name them. If an assumption fails, that becomes a legitimate reason to reprice rather than absorb the difference.

Add a change-control process. State that any request to add, remove or alter a deliverable goes through a written change order, and that work on that change starts only after the order is signed by both parties.

Worked example. A newsroom asks for an interactive map. The scope names: a Leaflet-based map build with six data layers, a responsive legend, a filter panel, keyboard navigation, a source and methodology note, and a one-hour handover session with the graphics desk. It excludes: additional map layers beyond six, custom cartography, translation into languages other than Spanish, and data cleanup beyond the two supplied files. Each deliverable has a file format, a platform and an owner.

A clear scope prevents unpriced expansion, because “not in the scope of work” becomes an answer you can point at instead of a negotiation you have to win every time.

How to know it is complete: every deliverable can be ticked off individually, an exclusions list exists, technical assumptions are named, and a change-order route is written down.

3. Set the Fees, Invoices, and Payment Schedule

Decide the pricing model first, and know what each one does to you when the work changes. A fixed fee rewards efficiency and punishes scope creep. An hourly or day rate absorbs change but rewards slow work. Phased or staged pricing splits the difference and is the most common fit for interactive builds. A retainer suits ongoing support rather than a project.

For interactive work, staged payment is the practical default because it protects both sides. Deposit on signature, a payment at each build stage, and a final payment before handover of production files.

A milestone schedule for a typical 12-week interactive engagement could look like this:

Milestone	Timing	Share of fee	Acceptance criteria	Client feedback window
Deposit	On signature	20%	Contract countersigned, kickoff scheduled	None — start condition
Concept and flow	Week 3	15%	Signed-off flow diagram and annotated wireframes	5 working days
Clickable prototype	Week 6	20%	All core paths clickable on staging, no blocker bugs	5 working days
Production build	Week 10	30%	All six layers live, responsive at three breakpoints, QA list closed	5 working days
Handover and support window opens	Week 12	15%	Source, editable files and documentation delivered; support period begins	None — close condition

Then write the mechanics: currency, invoice dates, payment window (net 14, net 30), who pays taxes and whether they are included, which expenses are reimbursed and against what receipts, and what late payment triggers. Interest on overdue amounts is worth including. It is often never used, and its presence changes the conversation.

Decide what happens when an invoice is disputed. A workable approach: the freelancer flags the dispute in writing within a set number of days of the invoice date, undisputed amounts still fall due on the original date, and the parties meet to resolve the difference. Without that split, a disputed invoice becomes a reason not to pay anything.

State what happens if a client stalls on feedback. The dates in the schedule should slide by the length of the delay, and the freelancer should not owe a refund for a timeline the client caused.

How to know it is complete: the currency, model, total, deposit, milestone amounts, invoice dates, payment window, tax treatment, expenses, dispute route and late-payment consequence are all written.

4. Build a Realistic Schedule and Approval Process

Dates in an interactive contract are usually estimates, and pretending otherwise creates a trap. Write them as target dates with dependencies attached.

Name the dependencies that are not yours: content supplied by the client, API keys, domain access, brand assets, editorial sign-off, legal review of copy, data files, and internal approval latency. Each dependency gets a required-by date. When one slips, the schedule shifts and the freelancer is not at fault.

Define the review process. Specify how many review rounds are included per deliverable, what counts as a round (one consolidated set of feedback per round, not one message per person), and who delivers it. Feedback consolidated by one designated person is the single most useful clause on this page — multiple stakeholders sending separate comments is how a two-day review turns into two weeks.

Write approval criteria. “Approved” should mean acceptance against the criteria in the scope of work, confirmed in writing by the named approver. Silence should not count as approval unless you deliberately write that it does, with a stated number of days.

Build in a stall clause. After the feedback window passes with nothing received, the milestone is deemed approved, or the schedule shifts by the number of days elapsed. Pick one, and be consistent — a contract that says both “silence means approval” and “client may take as long as they like” is worse than no clause at all.

How to know it is complete: start and target dates exist, dependencies have required-by dates, feedback rounds are capped and consolidated through one person, and approval has a definition and a deadline.

5. Define Revisions, Acceptance, and Change Requests

Separate three things that clients routinely blur together: revisions, changes, and new work. Revisions are corrections that bring a deliverable closer to what was already agreed. Changes alter the agreed deliverable itself. New work was never in scope.

Put a number on revisions. Two rounds per deliverable is a common starting point; one for fast-turning work; three where design exploration is genuinely part of the job. Say what a round is: one consolidated set of comments per deliverable, delivered in a single pass.

Define acceptance in writing. Something like this works: the client has five working days from delivery of a milestone to accept it or provide one consolidated set of revision requests. Acceptance is deemed given if no response arrives within that window. A deliverable is accepted when it meets the acceptance criteria in the scope of work, not when the client says it feels right.

Now write the change request process. Define a change order as a written document that states the change, its effect on fee, its effect on timeline, and both signatures, and that work begins only when it is signed. Some studio blogs publish a copy-paste change-request format worth adapting: what is being asked, why, the hours or days it adds, the schedule impact, and the revised fee.

Know the difference between a revision and a change. The client asked for a prototype showing a filter panel; you delivered it and the filter is wrong because the agreed spec said one filter. That is a revision. The client now wants a second filter type on a new screen. That is a change, and it gets a change order.

Keep a timer for out-of-scope tasks, as experienced freelancers suggest. It is the cheapest evidence you will ever have, and it turns “you are being difficult about money” into a list with hours on it.

How to know it is complete: revisions are counted per deliverable, a round is defined, acceptance has criteria and a deadline, and the change-order route requires a written and signed document before work begins.

6. Allocate Intellectual Property and Usage Rights — How to Write an Assignment That Holds Up

This is the section where interactive projects get complicated, because a build is assembled from parts with different owners. Your code, your design files, the client’s content and data, third-party assets, fonts, plugins, audio, and open-source libraries each carry their own terms.

Start with the framework. A work-for-hire or work-made-for-hire clause says the client owns the deliverable from the start. A written assignment transfers ownership later, on a stated trigger. Legal commentary aimed at independent game developers makes the point that work-for-hire language on its own is not sufficient in every jurisdiction and an express written assignment is needed. Jurisdictions also differ on what falls inside the work-for-hire category, so treat the label as unreliable and use an express written assignment.

Most freelancers prefer a delayed transfer. Ownership passes on final payment, or per milestone as that milestone is paid. That way an unpaid invoice never leaves the client owning your work outright.

Add a moral rights waiver where one applies in your jurisdiction. Creative work carries moral rights in many countries, and they can otherwise restrict editing, localisation, porting or updating. Say the client waives them to the extent permitted, and that the waiver is a condition of the assignment.

List what transfers at handoff and what does not. A typical split: the client receives source files, the editable project file, built assets, documentation, and third-party components with their licences. The freelancer keeps their pre-existing tools, general libraries, internal code snippets and boilerplate.

Handle third-party material explicitly. Fonts, icon sets, stock art, music and sound effects each have their own licence, and most do not permit unlimited commercial redistribution. State that every third-party component is either (a) licensed in perpetuity for the agreed use, with the licence recorded, or (b) replaced with a client-supplied equivalent before launch. For open-source code, record the library, version and licence, and note that copyleft licences can impose conditions on how the project is distributed — a question for the attorney, not for you.

Give yourself portfolio and credit rights. Ask to show the work publicly once it is live, with an agreed form of credit. Threads about contract templates for illustrators and game artists turn up a recurring worry: getting permission to show work that is under NDA. Write the permission in now, while both sides are still pleasant.

How to know it is complete: the transfer trigger is explicit, moral rights are handled where applicable, handoff artefacts are listed both ways, third-party licences are accounted for, and portfolio and credit rights are stated.

7. Address Confidentiality, Data, Security, and Independence

Write obligations, not promises. “The freelancer will protect confidential information with reasonable care” is an obligation you can meet. “The freelancer guarantees complete data security” is a promise you cannot make and should not.

Define confidential information: unpublished editorial material, source documents, embargoed data, unreleased product plans, credentials, the client’s internal communications. Add an exclusion for anything already public, independently developed, or lawfully received from a third party.

If the build collects personal data, say who is the controller and who processes, where data is stored, whether it leaves the country, how long it is retained, and what happens to it at handoff. Then say who signs off on the privacy documentation. Interactive work that handles user data pulls a legal review into your timeline whether you plan for it or not.

Add practical security terms instead of vague ones: use a password manager, keep credentials in a separate workspace, use two-factor authentication, and notify the client within a defined period if a credential tied to the project appears to be compromised. A number is better than “promptly”.

Cover public statements. Many interactive clients want a confidentiality period and a rule about naming the project publicly before launch. Ask for a named person whose sign-off counts, because “the client’s legal team” is a slow queue.

Handle independence. State that the engagement is an independent contractor relationship and that both parties are responsible for their own taxes, insurance and equipment. Games trade press has summarised the classification risk for a studio audience using the California Labor Code definition, and the practical red flags are consistent across jurisdictions: employer-set hours, control of the means of work, training rather than direction, exclusivity, and a bar on working for others.

Those five are worth reading before you sign. If your day-to-day reality matches them, the contract wording matters less than the working pattern, and changing the pattern is usually faster than defending the contract.

How to know it is complete: confidentiality is defined with exclusions, data handling is assigned, security terms name concrete practices and a notification period, public statements have a rule and a named approver, and contractor status is stated with the classification risks acknowledged.

8. Add Cancellation, Termination, and Final Handoff Clauses

A finished contract makes both the normal exit and the unsuccessful one predictable. That means writing down what happens when a project dies halfway.

Cover cancellation by the client. State that the client may cancel for convenience on written notice, that the deposit is non-refundable once work has started, that completed and in-progress work is invoiced pro rata, and that a kill fee applies to the remainder. Define the kill fee as a stated percentage of the unpaid balance — a third is a common starting point, and it should reflect how much of your capacity the cancellation actually consumes.

Cover termination for breach by either side: a written notice, a cure period of a stated number of days, and termination if the breach is not cured. Cover insolvency or disappearance of the client, and what happens to files you are holding.

Write the handoff clause. On final payment, deliver source files, editable project files, built assets, documentation, and any third-party component records. State that delivery of production source files is conditional on receipt of final payment, and that working files or intermediate drafts stay with you unless listed. Freelance communities note that the governing-law and jurisdiction clause is the piece most often forgotten. It belongs here, alongside a dispute-resolution line: which courts, and whether the parties meet before escalating.

List what survives termination. Confidentiality, IP and licence terms, portfolio rights, payment obligations and dispute resolution all continue after the engagement ends.

How to know it is complete: both cancellation routes are priced, breach and cure are defined, the handoff list and its payment trigger are written, the governing law and jurisdiction are named, and the surviving clauses are listed.

Common Mistakes

Vague deliverables. “Design and build an interactive experience” cannot be signed off. Replace outcome language with itemised artefacts, formats, platforms and acceptance criteria.

Unlimited revisions. It sounds generous and it destroys the margin, because the revisions still consume hours. Replace it with a number of rounds per deliverable and a definition of what a round is.

Unclear payment triggers. “Payment on completion” with no definition of completion is an argument waiting to happen. Tie payments to named milestones with written acceptance criteria and a feedback window with a deadline.

Overbroad IP assignment. A clause that assigns everything you will ever create, including pre-existing tools, is rarely what you meant and is hard to unwind later. List what transfers, when it transfers, and what stays with you. Include the moral rights waiver where it applies.

Missing client duties. If the contract only describes what you must deliver and never what the client must provide, every delay becomes your delay. Name the content, access, approvals and decisions the client owes you, with dates.

Contradictory approval language. Silence counts as approval in one clause and does not in another. Pick one rule, give it a number of days, and use it consistently everywhere, including the revision clause.

One-sided termination. If only the client can walk away, the contract is a risk instrument, not an agreement. Give both sides a route out, and price the client’s.

A few habits help more than any clause. Redline the client’s version rather than rewriting it from scratch, so each change is visible and negotiable. Keep one version of the document; freelancers routinely lose hours to a “final_v3_signed” file that is not the final one. Write in plain language, because a clause a client does not understand is a clause they will not follow. Send a short plain-English summary alongside the contract, not inside it.

And get a lawyer to look at it before you sign. Not because your contract is unusually risky, but because the law where you live decides which of these clauses will hold up. An hour of review routinely prevents a month of chasing.

Frequently Asked Questions

Conclusion

To write a freelance contract for interactive work, do the same eight things in the same order every time: name the parties, turn the brief into itemised deliverables with exclusions, set the fee and the milestone schedule, build a schedule with feedback deadlines and one named approver, cap revisions and define acceptance, assign IP on payment with a moral rights waiver, write confidentiality and contractor status as obligations, and price the exit.

Start with the project brief. Rewrite every promise in it as a specific written obligation with an owner, a date and a price attached, and the contract writes itself out of that list.

Then have an attorney in your jurisdiction review it before either side signs. Last updated for 2026.