Agreement for hiring a freelance developer
Alex Shi
Use an independent contractor agreement paired with a detailed statement of work, or a services agreement with SOW if you expect follow-on projects. The one clause you cannot compromise on: present-tense IP assignment ("Contractor hereby assigns"), plus contractual control of the repository and accounts from day one. Have a lawyer review the IP and liability sections before you sign anything.
TL;DR:
- Use an independent contractor agreement paired with a detailed statement of work for a single MVP build, ensuring scope clarity and fixed timeline.
- Insist on present-tense language for IP assignment and repository ownership from day one to secure automatic transfer of rights.
- Tie milestone payments and a holdback to objective acceptance criteria to maintain leverage and prevent disputes over vague deliverables.
- Require full source code, deployment scripts, and documentation in the handover, with the repository created under your organization from the start.
- Watch for contract clauses that rely on "will assign" language or delayed ownership transfer, and engage legal review to prevent IP and ownership issues.
Table of Contents
- What agreement should I use when hiring a freelance developer to build an MVP?
- The contract clauses you must include
- How IP ownership actually works for custom software
- How to set milestone payments, holdbacks, and acceptance tests
- Repository, accounts, and handover checklist to contractually require
- Negotiation tips and red flags that should make you walk away
- How Formable speeds up drafting, review, and signing these agreements
- What I insist on when I review a freelance developer agreement
- Get your freelance developer agreement signed faster with Formable
- Sources
- FAQ
What agreement should I use when hiring a freelance developer to build an MVP?
The answer depends on how long you expect the relationship to last and how much scope might shift after kickoff.
For a single, well-defined MVP build with a clear end date, an independent contractor agreement plus a Statement of Work (SOW) is usually the cleanest structure. The contractor agreement handles the legal boilerplate (IP, confidentiality, liability), and the SOW carries the specifics: features, timeline, and price.
If you expect the same developer to keep working with you after launch, whether that's maintenance, a v2, or ongoing feature work, a master services agreement (MSA) with a per-project SOW saves you from renegotiating boilerplate every time. You sign the MSA once, then issue new SOWs as new projects come up. Guides on how to structure a master service agreement break down when this structure makes more sense than a one-off contract.
A pilot agreement or paid discovery SOW is worth considering when your own scope is still fuzzy. Paying a developer for a short, bounded discovery phase before committing to the full build limits your downside if the fit is wrong.
Run through this checklist before choosing:
- How long is the engagement expected to run, weeks or months?
- What happens if this developer disappears mid-project? (Your "bus factor.")
- Will you reuse this code or this contractor again?
- How likely is scope to change once development starts?
The contract clauses you must include
Founders tend to focus on price and timeline and skim past the clauses that actually determine who owns the product. Here's the priority order for what to check, or insist on, before signing:
- Present-tense IP assignment. The contract must say "Contractor hereby assigns" all rights in the work product to you, not "will assign" or "shall assign." That single verb tense determines whether ownership transfers automatically or requires a future action that might never happen.
- Work-for-hire language as a backstop. Include it, but don't rely on it alone. Courts have limited how far work-for-hire doctrine extends for custom software.
- A background IP schedule. List any code, libraries, or tools the developer brings in that they still own, along with the license terms for your use of it.
- A detailed SOW with acceptance criteria. Vague scope is the single biggest driver of freelance disputes, according to Upwork's contract guidance. Define objective, testable deliverables per milestone.
- Milestone payments with a holdback. Tie a portion of payment, typically 10 to 20 percent, to final delivery and acceptance.
- Repository and account ownership. Spell out who owns the GitHub org, hosting accounts, and credentials, and when they transfer.
- A warranty or bug-fix period, with a clear definition separating a "bug" from a "change request."
- NDA, subcontractor flow-down, indemnity, and liability caps. If your developer subcontracts any work, the confidentiality and IP obligations need to flow down to that subcontractor too.
- Termination and dispute escalation terms, including what happens to partial work and payments if either side walks away early.
Pro Tip: Ask for a redline, not just a signature. If a freelancer pushes back hard on present-tense assignment or refuses to name their background IP, that reaction tells you more than any resume.
Arc's guidance for engineering managers treats contract terms as a starting point for negotiation, not a take-it-or-leave-it document. Founders who skip that step often find out too late that "standard" boilerplate favored the contractor, not them.
How IP ownership actually works for custom software
Here's the part that surprises most first-time founders: paying a developer does not automatically make you the owner of the code they write. Under US copyright law, the person who writes the code owns it by default, unless a valid assignment or a qualifying work-for-hire arrangement transfers that ownership to you.
Work-for-hire status is narrow and often does not cover independent contractor software work at all, which is why relying on it alone is a mistake. The safer path is a present-tense assignment, language stating the contractor "hereby assigns" all rights immediately upon creation, not at some future date tied to final payment. Guidance on structuring MVP agreements is direct on this point: assignment must be present-tense to be effective on signing.
A few practical additions strengthen this further:
- A covenant requiring the contractor to sign any additional documents needed to "perfect" the assignment later.
- A limited power of attorney letting you execute those documents if the contractor becomes unreachable.
- A written schedule of background IP and an open-source bill of materials listing every third-party component and its license.
Skipping the open-source disclosure is a common and expensive oversight. Some open-source licenses carry copyleft obligations that can force you to release your own source code if you're not careful about what got baked into your MVP.
How to set milestone payments, holdbacks, and acceptance tests
A payment structure with too much money paid upfront gives you no leverage if the work stalls. Too little upfront, and no serious developer will take the job. A workable middle ground looks like this:
- An initial portion of the payment at kickoff, treated as a commitment fee, not a refundable deposit.
- Staged payments tied to milestones defined in the SOW, each with its own acceptance criteria.
- A 10 to 20 percent holdback, released after a short post-launch warranty window closes.
- IP transfer tied to each milestone payment, where practical, rather than withholding all ownership until the final invoice clears. This limits how much leverage either side holds at any one point, according to founder-focused MVP contract guidance.
Define acceptance with objective tests, a feature works or it doesn't, rather than subjective language like "client approval required," as detailed in our structured delivery process and phase-based milestones. Add invoice terms, a late fee, and a clear escalation step (a named point of contact, then mediation) before anyone needs to use them.
Repository, accounts, and handover checklist to contractually require
Insist the repository is created inside your organization's account from the start, not transferred later "if things work out." That single requirement prevents most post-project ownership fights.
Your handover deliverables should include:
- Full source code and complete commit history, not a final zip file.
- Deployment scripts, environment variables, and a documented secrets-handling plan.
- Written documentation plus a recorded handoff call walking through the architecture.
- A defined number of transition support hours, with a stated hourly rate for anything beyond that.
- An open-source bill of materials with license terms for every third-party package used.
| Handover item | Why it matters |
|---|---|
| Repo ownership from day one | Prevents access disputes after final payment |
| Commit history included | Confirms authorship and timeline for IP purposes |
| OSS bill of materials | Flags copyleft or licensing risk before launch |
| Recorded handoff call | Preserves institutional knowledge if the developer disappears |
Buyer-side checklists on scoping an MVP development contract treat these as baseline deliverables, not extras to request later.
Negotiation tips and red flags that should make you walk away
Every clause in a freelance contract is negotiable, and the SOW is your best tool for locking down scope before work starts. Ask for present-tense assignment and repository ownership explicitly, in writing, before you sign.
Watch for these red flags:
- Contract language reading "will assign" or "shall assign" instead of "hereby assigns."
- The repository stays under the contractor's personal account with no transfer commitment.
- Ownership only transfers on final payment, with no milestone-based transfer along the way.
- Refusal to disclose open-source components or background IP.
- No acceptance criteria, no exit assistance, and no defined warranty period.
Pro Tip: If a freelancer resists adding a simple assignment clause, ask why directly. A legitimate developer has no reason to fight language that just confirms you own what you paid for.
Any of these on their own is a conversation. Two or more together is a reason to pause and get counsel involved before you commit budget.
How Formable speeds up drafting, review, and signing these agreements
Formable maps directly onto this workflow. Start from a ready-made independent contractor agreement template, attach your SOW, and use the redlining tool to negotiate terms with your developer in one place instead of email threads. Formable's contract creation tool combines templates with generative drafting, so building out assignment language and milestone schedules doesn't start from a blank page.
Before signing, run the draft through Formable's review engine, which checks for missing IP assignment language, undisclosed open-source risk, and other gaps against a playbook you set. Once both sides agree, collect signatures directly through Formable's e-signing tools, or its embedded signing API if you're building this into your own hiring workflow.
What I insist on when I review a freelance developer agreement
The clause founders skip most often is the present-tense assignment. I've seen agreements with airtight payment terms and a vague "contractor agrees to transfer rights upon completion" line that never actually transfers anything. That's not a technicality. It's the difference between owning your product and licensing it from someone who can walk away with it.
My checklist starts with assignment language, then repo ownership, then acceptance criteria. Everything else is negotiable. Get a lawyer to confirm the IP language actually does what you think it does.
— Alex
Get your freelance developer agreement signed faster with Formable
Formable is built for exactly the moment you're in right now: you have a developer ready to start, a scope you need locked down, and no interest in spending days assembling contract language from scratch. Instead of drafting an independent contractor agreement and SOW from a blank document, or hunting down a template that may be missing present-tense assignment language altogether, you generate one, attach your milestones, and send it for redlining in the same platform.
Founders coming out of this article already know what to check for: assignment wording, repo ownership, acceptance criteria, OSS disclosure. Formable's review engine checks drafts against exactly those risks automatically, flagging gaps before you sign rather than after a dispute starts. If you're negotiating terms back and forth with a freelancer, the redlining tool keeps both sides working from one document instead of scattered email edits.
Start by generating your independent contractor agreement on Formable, attach your SOW, and see how much faster you get from draft to signature.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Sources
For deeper reading on assignment mechanics, see Adam Arant's decision framework on agency versus freelancer hiring. Upwork's freelance contract guide covers core clause checklists. For a real-world staged payment example, review this SEC-filed software development agreement. Formable's services agreement template covers the MSA-and-SOW structure directly.
FAQ
What should a freelance developer contract include?
At minimum, a detailed SOW, present-tense IP assignment, milestone payment terms with a holdback, repository and account ownership, a warranty period, and termination and confidentiality terms.
How do I hire a freelance developer for an MVP without losing ownership of the code?
Require present-tense assignment language ("hereby assigns"), keep the repository under your organization's account from the first commit, and tie final payment to a holdback released after acceptance testing.
Can you use a sample contract for freelance developer work?
Yes. Formable offers an independent contractor agreement template and a services agreement template you can adapt with your own SOW and milestones rather than starting from scratch.
How do I build an MVP with a freelancer instead of an agency?
Scope a single, well-defined feature set in a SOW, hire under an independent contractor agreement with milestone payments, and require acceptance testing at each stage so the product ships against clear, objective criteria rather than open-ended revisions.
Do I need an NDA in addition to my developer contract?
Yes, if you're sharing proprietary business details before the developer signs the main agreement. A mutual NDA covers that gap during early discovery conversations.
