How to Hire a Contract Developer: Freelancer, Agency or Dedicated, Plus a Contract Checklist

Most people looking up how to hire a contract developer already have the project in their head. What they don't have is a feel for the risks. Will the developer vanish halfway through? Who owns the code once they leave? What happens when the invoice and the original agreement stop matching? Below: the common ways to get development done, how to choose, how to test a developer first, and the 12 clauses we'd want in any contract.

Freelancer, agency or dedicated contract developer

The three arrangements differ less in skill than in who carries the risk when something goes wrong.

Freelancers

A freelancer is one person, usually working for several clients at once. You talk directly to whoever writes the code, which is the main appeal. No account manager relays your messages. Freelancers tend to bill by the hour or quote a fixed price per job.

Continuity is the weak spot. If your freelancer gets ill, takes on a bigger contract or just stops replying, the work stops too, and nobody else knows the codebase. The management falls on you as well: you write the tasks, check the output and decide when something is finished. For a well-defined job with a clear end date that's a fair trade. For a product you'll keep changing for two years, it gets tiring.

Agencies

Agencies sell an outcome. You agree a scope, they quote a fixed price or a phased estimate, and a project manager deals with the people. You get less control. You'll usually see the work at milestones and may never speak to the developers directly. In return, staffing problems belong to the agency, and if someone leaves, replacing them is their job.

Fixed-price work has a catch that both sides understand. Anything outside the agreed scope becomes a change request with its own price, so an agency is strongest when you know exactly what you want before work starts, and weakest when you're still working it out as you go.

Dedicated contract developers

Picture a developer who works only on your project, commits to your repository, turns up to your stand-up and is paid by the month. You set priorities week to week, much as you would with an employee, without the hiring process or the employment contract. The cost is predictable too: a monthly fee for an agreed number of hours, or prepaid blocks of hours for smaller pieces of work.

Whether you get continuity depends on who supplies the developer. A solo contractor has the same single point of failure as a freelancer. A company that provides contract developers can review their code and cover absences, and it's worth asking directly whether they do. Management sits somewhere in the middle. You decide what gets built; the developer, or their lead, decides how.

Cost structure shapes behaviour too. Hourly billing pays for time, so it suits small or unpredictable tasks. With a fixed price you're buying an outcome, and the quote includes the agency's allowance for risk. A monthly arrangement buys capacity, which only makes sense if there's always more work waiting. No model always costs less. A fixed price on a vague brief gets padded, and hourly work on a vague brief can run on for months.

Which one fits your situation

A few common situations, and what we'd pick in each.

A new consultancy needs a five-page website. The copy is written and there's a launch date. Take a freelancer or a fixed-price package. There's little to manage after launch, so continuity barely matters.

You run an online store and want a new checkout, a loyalty scheme and better product search over the next six months, and the list keeps growing. That's a backlog. Backlogs suit a dedicated developer on a monthly arrangement, because you can reshuffle priorities every week without asking for a new quote.

A different case: your one in-house developer is swamped. Adding a contract developer who works in the same repository, under the same code review, is usually smoother than handing a chunk of the product to an agency that builds in its own systems and hands it back at the end.

Or you don't know yet what you need. In that case, pay for a short, defined piece of discovery first: a few days of an experienced developer's time to read your requirements (or your existing code) and write a plan with an estimate. Then choose.

How to check a developer before you commit

A CV shows what someone has shipped. It says nothing about how they work, and how they work is what you'll be living with.

Read their code

Ask for a repository or a code sample they wrote themselves, ideally from the last year or so. If you can't judge code yourself, pay an independent developer for an hour to look through it. Things to check: whether a stranger can follow the file and function names, whether there are tests, whether secrets such as API keys are kept out of the code, and whether the commit messages say what actually changed.

Pay for a short trial

A paid trial on a real task tells you more than any interview. Pick something small with a clear finish, like a bug that's been annoying customers, and watch the whole loop: the questions they ask, how long it takes, what the pull request looks like when it arrives. Paying matters. Unpaid test work attracts people with spare time, and it gives you no clear right to use what they produce.

Ask how they work

• Who reviews your code before it's merged?
• What tests do you write, and do they run automatically on every change (continuous integration, or CI)?
• Will you work in our repository, through pull requests we can see and approve?
• How do you report progress, and how often?
• When the work ends, what do we get: documentation, credentials, deployment notes?
• What happens if you're ill for two weeks?

Vague answers to the last two are the ones to worry about. Plenty of capable developers have never thought hard about handover, and the client pays for it later.

A contract between web developer and client: 12 clauses

Whichever arrangement you choose, put it in writing. This is the checklist we'd use for any contract between a web developer and a client. It isn't legal advice, and a lawyer where you're based should review the final version, but it covers the gaps that tend to turn into arguments.

1. Scope and change process. What's being built, in enough detail that both sides could agree whether it's done, plus how changes are requested, estimated and approved before anyone starts on them.
2. Payment terms and milestones. Hourly, monthly or fixed; when invoices go out and when they're due; what's paid upfront; and what happens to payment if a milestone slips.
3. Intellectual property. A written assignment of the code and all related IP to you, stating that it applies worldwide and for the full term of copyright. In some jurisdictions an assignment that doesn't state its duration and territory is read narrowly, so spell both out even if it feels redundant.
4. NDA and confidentiality. Covers your code, data and business plans, is signed before you share any of them, and keeps applying after the contract ends.
5. Pre-existing code and open-source licences. Developers often reuse their own libraries. Say whether you own those or get a permanent licence to use them, and ask for a list of the open-source packages used, with licences that fit how you plan to use the product.
6. Acceptance criteria. How each deliverable is tested and approved, and how many days you have to raise problems before it counts as accepted.
7. Bug-fix warranty. A period after acceptance, for example 30, 60 or 90 days, during which defects in the delivered work are fixed at no extra charge.
8. Handover. On completion or termination you receive the repository, every credential and API key, admin access to hosting and domains, and documentation good enough for another developer to carry on.
9. Notice and termination. How much notice each side gives, what gets paid for work in progress, and a line confirming that handover still happens if the contract ends early.
10. Subcontracting. Whether the developer may pass work to someone else, and if so, that the same confidentiality and IP terms bind that person.
11. Data protection. Which personal data the developer will process (customer records, order history, staff accounts), why, where it's stored and who can reach it. If real personal data is involved, your own legal obligations come with it, so agree how access is handled before it's given. Working with test or anonymised data avoids most of the question.
12. Governing law and disputes. Which country's law applies, and how a disagreement gets resolved: negotiation, mediation, arbitration or the courts, and where.

Clause 3 answers the question that matters most later: who owns the code? Without a written assignment, in many places the person who wrote the code keeps the copyright even though you paid for it. An invoice marked paid doesn't transfer ownership. Get the assignment signed and keep a copy with your repository.

Clause 8 is the one people skip. A developer can hand over a repository and still hold the only login to the hosting account, the domain registrar or the payment gateway. List each one by name.

Working across time zones

Time zones cause trouble when overlap is left to chance. Before work starts, agree which hours of your day the developer will be online (two to four hours is plenty for most teams) and put stand-ups and reviews inside that window.

Everything else can happen in writing: task descriptions clear enough to start on without a call, pull requests that explain what changed and why, and a short note at the end of the developer's day that you read at the start of yours. Done like this, the gap helps. A bug you report late in your afternoon can be fixed by the next morning.

If you want to see how these terms look in a real arrangement, with rates, notice period and IP assignment spelled out, our contract developers page has the details, and you can send us a message through the form there.

Questions people ask

Are dedicated developers better than freelancers?

For ongoing product work, usually yes, because one person stays on your codebase and you set the priorities. For a one-off job with a clear end, a freelancer is simpler and you avoid a monthly commitment.

Who owns the code a contract developer writes?

Whoever the contract says. Without a signed IP assignment the developer may keep the copyright, so get one in writing that covers the code worldwide and for the full term of copyright.

Should a trial period be paid?

Yes. Payment attracts developers who take the work seriously, and it makes clear that what they produce during the trial is yours to use.

What notice period should a developer contract have?

There's no single standard. Choose one long enough to finish a proper handover, and write down what happens to work in progress when notice is given.

Do I need a lawyer to review a developer contract?

For a small fixed-price job, a clear written agreement covering the 12 clauses above is often enough. If the project involves personal data, large sums or a product your business depends on, have a lawyer in your jurisdiction read it before you sign.