How do you stop your code spreading down a chain of subcontractors?

You built a routing and scheduling engine. A prime contractor wins a large public project and wants to use it. They need two subcontractors to adapt it for different regions, and one of them brings in a small specialist firm for the reporting module.

Your contract is with the prime. The prime’s contract passes your code to the subcontractors, subject to the same confidentiality terms. The specialist firm uses a freelancer for two months.

Eighteen months later you cannot list who has a copy.

Each level passes down a full copy, because it is the easy way to give people what they need to work. Your confidentiality terms bind the first level. Past that, it depends on contracts you never saw.

People change firms. A freelancer or an employee of a small subcontractor moves to a company that competes with you, and with a readable copy, an AI tool can turn it into code that no longer looks like yours.

Your core engine is known, and reusable, by firms outside your control. A prime contractor can swap you out, because they and their chain already hold what makes you valuable. And you cannot show, after the fact, who had it.

Confidentiality terms flowed down in contracts give you a legal claim against each party, but you cannot see or enforce past the first level. Naming approved subcontractors says who is allowed, not what each one holds.

A secure shared workspace covers where work happens, not copies made to work offline or on a deadline. Return and deletion at the end cover the first level, not everyone below it.

First, lock your business logic. Most of a codebase is boilerplate: screens, logins, forms, reports, connections to other systems. It looks much the same in every product. Your business logic, the rules that make your product yours, sits separately in its own files. NakodaX scans your repository and suggests those files. You review the list and decide what to protect.

NakodaX does not change your original repository. It builds a new, protected repository next to it, where the locked files are replaced by stand ins and no history of those files is kept. Your team runs a switch over: the prime, every subcontractor and every freelancer stops working in the original repository and moves to the protected one. A developer licence opens the stand ins and never the real code, whichever machine it runs on.

The prime, each subcontractor and each specialist gets its own licence. You can see them, and revoke any one without affecting the others. If a subcontractor must change the real logic, a named person asks, a different admin approves, the window has an end date, and it is logged.

Each repository has its own key, so a key lost by one party does not open the rest of your code.

Copies made before the switch are not changed: code a subcontractor already holds in readable form stays readable. NakodaX protects from the day you switch. People in an approved change session can read the real files during that window.

Files you did not lock stay readable. Today it works with Python, JavaScript, TypeScript and SQL.