The question behind this one is usually unspoken: if I stop, does something expensive happen? For a properly structured nearshore engagement the answer is no, and the reason is worth understanding, because it is the same reason the structure matters at the start.
The three-line version
- You give the notice in the contract — thirty days is the reasonable norm — in writing.
- You pay the final invoice, prorated by calendar day for the partial month.
- Access is revoked, the handover document is delivered, and the engagement is over.
No severance, no thirteenth salary, no FGTS, no labour court. Those are obligations of a Brazilian employer, and in this model the employer relationship — to the extent one exists at all — sits with the studio, not with you. The piece on PJ contractors explains the structure and where the exposure actually lives.
Where it does get expensive
One structure carries real risk: a U.S. company contracting a Brazilian individual directly, exclusively, on a fixed schedule, under direct supervision, for a long period. Brazilian labour law looks at the substance of a relationship rather than its label, and a court can rule that an employment relationship existed regardless of what the contract said — with the entitlements that were never paid falling due at the end.
That risk is not created by ending the engagement. It is created at the beginning, by the structure, and ending it is simply when it surfaces. If you hold a direct contract with an individual in Brazil and you are about to end it, that is the moment to take five minutes with a Brazilian labour lawyer rather than the moment to move fast. Contractor versus employer of record lays out the three structures side by side.
What good notice looks like
Thirty days, symmetrical, either direction. Symmetrical matters: a contract where you owe ninety days and the vendor owes none is not a notice clause, it is a lock-in with a polite name. Thirty days is long enough for a handover and short enough that neither side is trapped.
Give it in writing, with a date. "We are winding down in a few weeks" is not notice; it is a feeling. One paragraph naming the last working day is enough, and it starts the clock for everyone, including the engineer, who now has thirty days to line up what comes next.
The handover is the part that decides how much you lose
The money side of an ending is fixed by the contract. The expensive part is knowledge, and it walks out on the last day unless you ask for it earlier. Ask for these, and ask in the first week of the notice period rather than the last:
- A decisions document. Not what the code does — why it does it that way. The three things they would have done differently, and the two things that look wrong but are deliberate.
- The list of things only they know. Every engineer has one: the deploy that needs a manual step, the test that is flaky for a real reason, the customer whose data breaks an assumption.
- Ownership transfer in writing. Which repositories, which pipelines, which alerts route to them today and who they should route to tomorrow.
- A live walkthrough with whoever inherits it. One hour, recorded. Worth more than ten pages.
A departing engineer who is being treated decently will do all of that well. One who found out by having their access cut will not, and the difference shows up in your incident response six weeks later.
Intellectual property, on the way out
This is where a weak contract turns into a real problem, because Brazilian law does not assign work product to a client by default the way a U.S. employment relationship does — the assignment has to be written, and it has to survive the end of the engagement. Check three things before the last day:
- The assignment clause names the deliverables and is not limited to the term of the contract.
- Confidentiality survives termination, with a stated period.
- Anything the engineer built with third-party or open-source components is documented, so you inherit the licence obligations knowingly.
The IP and NDA guide covers the clauses that hold up. If you are reading it for the first time during an offboarding, read it anyway — it is better to find the gap now than during a diligence process.
Access, on the actual last day
Not the last week, and not "when IT gets to it." A short checklist, run on the final day: source control, cloud console, CI, production and staging databases, the observability tool, the password manager, SSO, the shared drive, the project tracker, any API keys issued to them personally, and the VPN. Rotate anything that was shared rather than personal.
This is a process item, not a statement about anyone's character. Run it identically for a beloved engineer finishing a great year and for a replacement in week three, and nobody has to feel anything about it.
What to tell the rest of the team
An ending that is not explained gets explained anyway, usually worse. Say the same thing to everyone, on the same day: what is ending, when, who picks up which surface, and — if it applies — that it is about scope or budget rather than the person. Vagueness here reads to the remaining engineers as "this could happen to me without warning," which is expensive in a way that no contract clause covers.
If the ending is performance-related, do not narrate that to the team. "We are consolidating the work" is true, sufficient and does not require anyone to take a side. The person leaving deserves that, and the people staying do not need the detail to do their jobs.
If you are pausing rather than ending
Worth saying, because teams often want this and do not ask: a pause is a different conversation from an ending, and it is usually possible. A month off the roadmap with a named return date lets the engineer plan, and it keeps the person who already knows your system. What does not work is an indefinite pause — that is an ending that nobody has said out loud, and the engineer will take other work, correctly.
Engagements through HireBrazilDevs are month to month with thirty days notice either way, and the studio holds the Brazilian side of every contract. Ending one is a paragraph, a final prorated invoice, and a handover — which is how it should feel.