Paying a developer safely: milestones, scope and written agreements

Most payment problems between project owners and developers start with something unclear: what was promised, when it counts as finished, or who owns the result. Being clear in writing, before money moves, prevents most of them. This guide explains how to structure scope, milestones and payments for a takeover project so that both sides know where they stand.

This is general information, not legal or financial advice. Laws on contracts, tax and intellectual property differ between countries. For a large or long contract, ask a lawyer where you are based to review the agreement.

TakeoverWork does not handle project money

TakeoverWork connects people and stops there. It does not hold deposits, release payments, run escrow or settle disputes about money. You and the developer agree the price between yourselves and pay each other directly, off the platform. That means the protection you have comes from what you agree in writing and how you pay. The conversation history on TakeoverWork is useful as a record of what was discussed, so keep important decisions in writing there or in email, not only in calls.

Step 1: Write down the scope

A scope is a short document that says what will be done and, just as important, what will not. For a takeover it should describe the starting point as well as the goal, because the project is not new.

A good scope includes:

• Current state. What works, what is broken and what is missing today. Attaching a review report or the output of the Handover Checklist Generator saves a lot of writing.
• Deliverables. Specific features or fixes, for example "users can reset their password by email" rather than "fix auth".
• Out of scope. Things you have discussed but are not paying for in this agreement, such as a redesign or a mobile version.
• Environments. Where the work happens (staging, production) and who deploys.
• Assumptions. Anything the estimate depends on, such as "the existing Supabase schema stays" or "the client provides copy and images".

If you are not sure how big the work is, the Rescue Effort Estimator gives a rough band to discuss. A paid review as a first step, described in our guide on evaluating developers, turns that rough band into a scope both of you can sign up to.

Step 2: Split the work into milestones

Milestones break the project into pieces you can check and pay for one at a time. Each milestone should deliver something you can see or test, not just "a week of work".

A typical takeover might look like this:

1. Review and setup. The developer gets the project running, documents how, and delivers a written findings report.
2. Critical fixes. Security issues and blocking bugs from the report are fixed.
3. Feature completion. The remaining agreed features are built.
4. Launch and handover. Production deployment, documentation, and a short support window.

Smaller milestones mean less money is at risk at any moment. They also give both sides a natural point to stop if the relationship is not working, without a messy argument over half-finished work.

Step 3: Agree acceptance criteria

Acceptance criteria answer the question "how do we know this milestone is done?" Without them, "finished" means different things to different people.

Write criteria that can be tested by someone who is not a developer:

• "A new user can sign up, confirm their email, log in and log out on the staging site."
• "A test-mode Stripe payment creates an order and sends a confirmation email."
• "The app loads and the main pages work on current versions of Chrome, Safari and Firefox on mobile."

Agree how long you have to test each delivery, and what happens if you do not respond in that time. Agree what counts as a defect (something in scope that does not work as described) versus a new request (something you now want that was not agreed). The Production Readiness Checklist is a good source of criteria for the final launch milestone.

Step 4: Handle change requests properly

Takeover projects almost always uncover surprises. The previous developer may have left a broken migration, or a third-party service may have changed its API. Changes are normal; unrecorded changes cause disputes.

Agree a simple process up front:

• Either side can raise a change in writing.
• The developer states the effect on cost and timeline before starting the extra work.
• You approve or decline it in writing.
• Approved changes are added to the scope or to a new milestone.

This protects the developer from unpaid extra work and protects you from surprise invoices.

Step 5: Decide how much to pay upfront

A partial deposit before work starts is common and fair, especially with a new client. It shows commitment and covers the developer's time if you disappear. What you want to avoid is paying 100% upfront, because then you have no leverage if the work stops or is not what you agreed.

Some common patterns:

• A deposit for the first milestone only, with each later milestone paid on acceptance.
• Payment on acceptance of each milestone, with no deposit, for small and well-defined work.
• For ongoing support after launch, a regular amount billed in arrears for agreed hours.

Whatever you choose, link every payment to a milestone or a time period that is written down.

Step 6: Make code ownership explicit

Do not assume that paying for code automatically means you own it. In many countries the person who writes the code holds the copyright unless a written agreement transfers it. Your agreement should say:

• When ownership of the code (or an exclusive licence to it) passes to you, for example on payment of each milestone
• That the code lives in a repository you own, with the developer added as a collaborator
• Which third-party or open-source components are included, and under what licences
• Whether the developer may reuse general tools or snippets they wrote before your project
• That accounts created for the project (hosting, domains, API keys) are in your name or your company's name

Keeping the repository and accounts in your name from day one is the single most useful protection here. If the relationship ends badly, you still have the code. Our page on what to do when a developer disappears with the code shows how painful the alternative can be.

Step 7: Ask for invoices and keep records

Ask for an invoice for every payment, even small ones. A proper invoice usually shows both parties' names and addresses, the date, a description linked to the milestone, the amount, the currency and any tax details required where the developer is based. Keep a simple folder with the agreement, change requests, invoices, payment confirmations and acceptance notes.

These records matter for your own accounting and tax, and they are what you would rely on if there were ever a dispute.

Step 8: Choose a payment method that leaves a record

Pay in a way that identifies both sides and creates a clear trail. Bank transfers to an account in the developer's or agency's name, card payments through an invoicing service, and established payment platforms all leave a record. Some payment platforms offer buyer protection, but check their terms, because protection for services or digital work is often narrower than for physical goods.

Be very cautious with methods that are hard to trace or reverse, such as cash, gift cards, cryptocurrency or transfers to a third party's account. If you choose to use an escrow service, find a well-known one yourself rather than one the developer sends you a link to.

When to get legal help

A written scope and a short set of terms is often enough for a small fix. Ask a lawyer to review the agreement when the contract is large for your business, runs for several months, involves personal or payment data, or crosses borders in a way that affects tax or ownership. If an agency stops working partway through, our page on an agency that abandoned a project covers the practical first steps.

Payment safety checklist

• Scope written down, including what is out of scope
• Work split into milestones with visible deliverables
• Acceptance criteria agreed for each milestone
• Change request process agreed in writing
• Deposit, if any, covers only the first milestone
• Code ownership clause agreed; repository and accounts in my name
• Invoice received for every payment
• Payment method leaves a record in both parties' names
• Lawyer consulted for a large or long contract