NakodaX

NakodaX blog/Source Protection·2 min read

How do you stop an engineer taking your code to a competitor?

You cannot stop someone remembering code, but you can stop a copy working. With NakodaX Source Protection, the files that carry your business logic are encrypted and need a license key to run. Developers build against stand ins. When an engineer leaves, you end their license and those files stop working at the next key request.

NakodaX Engineering team

By NakodaX Engineering team

NakodaX · · Updated

A person leaving with a bag while the protected code files stay sealed and glowing behind them.
Remove their access, and also make the code they hold stop working.

An engineer with access to your code accepts an offer from a competitor. On the last day you remove them from the repository and collect the laptop.

The copy on their home computer, a personal account or an old backup is untouched. Removing access stops new copies. It does not close the ones that exist.

What can an engineer take?

Anyone who works on the product can read the files that carry the real advantage: the pricing rules, the scoring, the matching, the integration that took two years to get right. A competitor with those files can rebuild a similar product in weeks. An AI tool can rewrite the code with new names so it no longer looks like yours.

A contract gives you a legal claim. It does not remove a copy.

What does NakodaX change?

Source Protection encrypts the few files that matter in a protected release. The rest of the code stays open and ordinary. Developers get a developer license that opens stand ins, which are placeholder versions with the same interface, never the real code.

If someone must change the real protected code, a change session is needed: a time limited window that a second person on your team approves, with a record of everything done in it.

What should you do before someone leaves?

  1. List the files that carry your business advantage. Keep the list short.
  2. Protect those files in a protected release. Developers keep working on the rest of the code and on stand ins.
  3. Give each developer their own license, so one person can be ended without touching the rest.
  4. When someone leaves, revoke their license. The protected files stop working at the next key request.
  5. Check the activity record for which machines asked for keys and when.

What does this not do?

While software runs on a licensed machine, the protected code is readable in that machine's memory. Revoking takes effect at the next key request, and a running process can continue until its cache refreshes, which can take hours. It cannot recover logic someone has already copied or learned. The story of the engineer who joined a competitor shows the whole case.

The takeaway

Protect the few files that matter, give each engineer their own license, and revoke it when they leave.

Related product

NakodaX Source Protection

Let vendors and customers build or run software without receiving selected proprietary source code in readable form.

See how it works

Common questions

Does removing a developer from the repository remove their copy?
No. The copy on their machine stays. With Source Protection, the key files in it stop working once you revoke their license.
Can developers work without the real protected files?
Yes. They build against stand ins that have the same interface. Changes to the real code go through an approved change session.
How quickly does revoking take effect?
At the next key request. A process already running can continue until its cache refreshes, which can take hours.

Try this on your own code.

Start a free trial, or tell us what you share and with whom, and we will show you how NakodaX handles it.