A resignation letter is not when the risk starts. It starts weeks earlier, while the engineer is still logged into every repository, still has full access to the design docs, and has already started thinking about what comes next. That window is quiet, unflagged, and looks like an ordinary Tuesday. It is also where a startup loses the clearest record of who actually built what.
What actually walks out the door
It is rarely the finished product. The production repo is usually fine: it has commit history, a real changelog, and more than one person who can vouch for it. What walks out is everything around it. A private repo spun up for an early prototype before the "real" one existed. A design doc pasted into a personal email because Slack was down that day. A branch nobody merged because the feature got deprioritized, but which still holds the first working version of an idea the company later shipped under a different name. None of it looks important while the person is still on the team. All of it becomes contested the day they are not.
A technical co-founder walking away from a disagreement is the sharpest version of this. Two people can remember the same six months completely differently, and once the relationship has broken down, there is no longer a shared account of who wrote which line first, whose sketch became the architecture, or when a given idea actually took shape. What is left is memory against memory, which is not evidence.
It is not only founders. A contractor who built the first version of a feature before joining full time, an intern whose summer project quietly became a core piece of the product, a freelancer who drafted the original architecture diagram: all of them leave the same kind of gap behind, usually without anyone noticing until a dispute forces someone to go looking for proof that was never kept.
Why sealing "at major milestones" leaves the gap open
Most engineering teams that think about this at all think about it at the wrong moments. A release gets tagged. A contract gets signed. Those get sealed, if anything does. The exploratory branch that shaped the release, the early prototype that proved the idea was even possible, the internal design doc that the release is actually based on: those rarely get the same treatment, because nobody was thinking about a departure while they were still writing code together. That is exactly backwards. The material with the weakest paper trail is the material a departing engineer has the clearest personal memory of and, often, the strongest instinct to claim credit for.
What continuous sealing actually establishes
The fix is not a bigger legal team. It is treating sealing as a routine part of how technical work gets saved, not a step reserved for launches and signatures. In practice that means a habit as ordinary as a merge to main: source code sealed on a regular cadence rather than only at release, a design doc sealed the day it is shared with the team rather than the day it is finalized, an early prototype sealed the week it first runs rather than months later, if at all. None of it depends on remembering that a departure might happen. It just needs to already be how the team works. Under Article 41 of eIDAS, a qualified electronic timestamp carries a presumption of accuracy for the date and time it records, and of the integrity of the data it covers. In Switzerland, a signature issued through a ZertES-accredited provider carries the same legal weight as a handwritten one. Neither framework cares who is still employed when a dispute eventually surfaces. Both care about what was recorded and when, which is the one part of the story that does not change depending on who tells it.
Picture two founders who build the first working version of a product together, then split badly eighteen months later. If the early prototype and the design doc that led to it were sealed the week they were written, there is a dated, tamper-evident record independent of either person's memory or their current relationship. If they were not, the dispute comes down to whoever is more convincing, which is not a position either founder should want to be in.
What this doesn't do
Sealing is not a replacement for an employment contract or an IP-assignment clause, and it does not decide a dispute on its own. A company still needs the underlying agreements that establish who owns work product in the first place. What sealing adds is the evidentiary record a dispute actually needs once those agreements are in place: proof of what existed, in what form, and when, that neither side can quietly rewrite after the relationship ends.
Make it routine before the departure, not after
By the time someone hands in notice, it is too late to start sealing the work that mattered most. The startups that avoid this fight are the ones that made sealing part of how they save technical work from the beginning, the same way they made version control part of how they write it. See how this works for software and IP teams before the next departure, planned or otherwise, makes the question urgent.
