In this guide 6 sections
A staff augmentation agreement should name the people, set replacement and notice terms, assign code ownership to you, limit access to live data and describe the exit. Settle these before anyone starts. GullySystem signs a confidentiality agreement and an IP assignment first. Have your lawyer review the wording for your situation.
Name the people, not the roles
The agreement should list the engineers you interviewed by name. A role title alone lets a supplier swap in someone with less experience after the sales stage.
Write down what happens if a person has to change. You should hear first, meet the replacement and get an overlap so context passes across.
Cover illness and resignation too. These happen. A plan written early is easier than one argued later.
- Named individuals with their experience stated
- Advance notice before any substitution
- Your right to interview the replacement
- An overlap period and who pays for it
Put ownership in the contract and in the accounts
A clause assigning intellectual property to you is the starting point. Your lawyer can advise on the wording that holds where you operate.
Ownership also has to be true in practice. The repository, cloud accounts, app store listings and documentation should sit in your name from the first commit. Supplier staff are added as users.
Check this on day one. A clause is harder to enforce than a setting.
Term, notice and the ramp-up period
Agree a minimum term that covers ramp-up. An engineer joining an unfamiliar codebase needs time to become useful, so very short terms rarely pay back.
Set notice periods in both directions for reducing or ending the arrangement. Note how overlap hours are agreed, especially if your team works in another time zone.
- Minimum term and how it renews
- Notice to reduce, add or end
- Agreed overlap with your working hours
Confidentiality and access to live data
A non-disclosure agreement should be signed before any code is shared. Decide early who may touch production and on what terms.
A masked copy of the data keeps the shape of real records without exposing names or phone numbers. Where live access is unavoidable, limit it to named people and log it. Remove it on the last day.
If your own policy requires work inside your environment, say so in the agreement.
Write the exit in at the start
Every engagement ends. The agreement should describe how: knowledge transfer sessions, finished runbooks, an access handover sequence and an overlap with whoever takes over.
Ask for documentation as part of the regular work, not a final-week task. Runbooks, architecture notes and decision records should build up in your repository as the work happens.
Augmentation agreement checklist
A one-page list of the clauses covered here, with space to note where each appears in the draft. Mark any that are missing before you sign. Hand the list to your lawyer along with the draft.
Open a blank worksheet to printQuestions owners ask
Does a signed IP clause alone keep our code safe?
Not on its own. The clause matters, but so does where the code lives. If the repository and cloud accounts sit with the supplier, getting them back is still work. Hold the accounts yourself from the start.
Should rates be fixed for the whole term?
Agree how and when rates can change, and in writing. Monthly rates usually vary with seniority and skill. Third-party and cloud costs are better billed to your own accounts directly.
Can augmented engineers work under our brand with our clients?
Often yes, if agreed in writing. Agencies use this arrangement. Spell out whose email addresses they use and who speaks in client meetings, so nothing is unclear later.