NakodaX

Situations · IP protection

How to protect source code when a developer leaves

Protected code modules staying behind as an engineer departs.

No tool prevents a departing engineer remembering what they learned, and claims otherwise should be distrusted. What can be prevented is a readable copy of core algorithms leaving with them: if differentiating modules stay locked, most developers build against them without readable access, so a departure takes experience but not source.

Start with what cannot be prevented

An engineer who spent three years on your product understands the architecture, knows which approaches failed, and remembers the shape of the solution. All of that leaves with them, and none of it can or should be stopped.

Any vendor claiming otherwise is selling something that does not exist, and the pitch is worth being suspicious of. Non-competes are narrowing in most jurisdictions, and memory has never been enforceable.

So the question is not how to stop someone taking what they learned. It is whether they also take a readable copy of the thing itself.

Those are very different losses

Understanding conceptually how your matching algorithm works is worth something to a competitor. Rebuilding it from that understanding still takes their team months, and what they produce is their own.

Having the source is a different order of problem. It compresses months into an afternoon, it carries every edge case you discovered the hard way, and it is the version that turns up in litigation.

The first is the ordinary cost of employing people in a competitive market. The second is avoidable.

Most of the team never needs to read it

The realisation that makes this workable: on a team of thirty, perhaps three people ever need the differentiating modules in readable form.

Everyone else calls them. They build features that use the scoring model without reading it, run the full application locally, debug their own code against it, and ship. The protected parts behave exactly as expected, which is the entire requirement.

That is less a restriction imposed on developers than a description of how large codebases already work. Most engineers do not read most of the repository.

A departure that takes experience and nothing else

So when someone leaves, planned or not, they take what they learned, which is theirs, and their references, which they earned.

What does not go with them is a working copy of the modules you would be afraid to see elsewhere, because it was never on their machine. There is no last-day clone to worry about, no forensic exercise on a returned laptop, and no awkward conversation with someone you liked working with.

The honest scope, stated plainly

This protects what you protected. Modules left readable are readable, and a developer with legitimate access to the sensitive parts has legitimate access to them.

It reduces how many people hold the crown jewels from everyone who has ever had a checkout to the handful who genuinely need it. That is a large reduction, and it is not the same as a guarantee.

What changes

The modules that make your product yours are locked, and most of the team never needs them readable to do their work. They build against locked parts that behave exactly as expected. A departure, planned or not, takes experience with it, but not the source of the thing you would be afraid to see in a competitor’s product.

access ended

Related questions

How do you protect source code when a developer leaves?
Keep the differentiating modules locked so most of the team builds against them without readable access. A departure then takes the person's experience, which cannot be prevented, but not a working copy of your core algorithms.
Can you prevent a departing engineer taking code?
You cannot prevent someone using what they learned, and no tool credibly claims to. You can prevent a readable copy of the sensitive modules existing on their machine in the first place, which is the loss that actually compresses a competitor's timeline.
How do you limit developer access to proprietary algorithms?
Protect the small portion of the codebase that is genuinely differentiating and grant readable access only to the few engineers who work on it directly. Everyone else calls those modules and builds normally, since most developers never need to read most of a repository.

This one, or one very like it

IP protection. Start where the problem actually is.