Notes on hiring a contractor

I have worked as an employee inside engineering teams and as an outside contractor, and I am open to contract work now. That gives me a useful view of what makes a contract engagement succeed or fail. Most failures are not about skill. They come from expectations that were never written down.

These are the notes I would give a manager or founder hiring a contractor, and the things I try to do myself when I am the contractor.

Start with the outcome, not the task list

It is tempting to hand over a list of tickets. A better starting point is the outcome you want: customers can pay by invoice, or the nightly import finishes in ten minutes, or the app is in the store by the end of the quarter. A good contractor will help shape the tasks from there, and can tell you early when the goal and the plan do not match.

Agree what done looks like

Write down how you will both know the work is finished. That might be acceptance criteria, a demo, or a checklist covering tests and documentation. Ambiguity about done is the number one source of disagreements over time and money, and ten minutes of clarity at the start prevents most of them.

Make onboarding easy

A contractor is paid by the hour or the week, and the first days often disappear into waiting for access. You can save real money by preparing in advance:

• Repository, staging environment and the tools the team uses
• A short guide to how the system works and how to run it locally
• One person who can answer questions quickly
• A first task that is small, real and safe to get wrong

Agree how you will communicate

Decide upfront how often you will check in and where. A short weekly summary of what happened and what is next is enough for many projects, along with a demo of anything that can be shown. The goal is that you are never surprised by the state of the work.

Be clear about ownership

The code should belong to you, and the contract should say so. So should accounts and credentials: they belong in your organisation, with the contractor added as a collaborator, not the other way round. Put the same care into a confidentiality agreement when the work touches sensitive information.

Plan the ending on day one

Every contract ends, so build the ending in from the start. Ask for documentation as part of the work, not as an afterthought. Ask that decisions are recorded. A good handover means your team can carry on without the contractor, and that is a sign of a good engagement, not a bad one.

Questions worth asking a contractor

1. How will we know the work is going well, week to week?
2. What would make you tell me the plan needs to change?
3. How do you handle work you have not finished when the contract ends?
4. Which part of this project worries you most?

The last question is my favourite. Someone who names a genuine risk is thinking about your project. Someone who says there are no problems has probably not looked closely yet.

A closing thought

The best engagements feel like a short, focused partnership: a clear goal, honest communication and a clean finish. If you are hiring, I hope these notes save you some pain. And if you are looking for a full-stack engineer for a contract, I would be glad to talk.