IP protection

Your software runs on their servers. It answers to yours.

You sell software that customers install and run themselves. That’s why you win. It also means every customer holds a complete, working copy of the thing you spent years building. NakodaX makes that copy answer to you, and stop when you say so.

Book a demo Talk to an engineer

Locked software cores on a customer server rack, dimming.

Every install is a copy you can’t take back

On-premise deployments. Customer-hosted installs. Software on an appliance in a factory, a hospital, a bank.

You built the business this way for a reason. It’s the only way some customers can buy. And every one of those deals ends with you handing over a working, readable copy of your product.

When the contract ends, the servers don’t. They keep running. Your pricing engine, your matching algorithm, your scoring model: still in there, still working, forever.

A competitor could hire one of their engineers next year and buy your best ideas with a salary.

You didn’t sell it to them. You licensed it. Only one of those has a way to end.

Ship it locked. Switch it off when you’re done.

01
We find what actually matters
Most of a codebase isn’t worth protecting. It’s plumbing everyone has written. A small part of it is the reason you have a business. We find that part.
02
It ships locked
The valuable code goes out sealed. Copy the whole thing, read every file, search every folder. The part that matters isn’t there in a form anyone can read.
03
It opens only when you allow it
When the software runs, it asks your servers for permission. When you stop giving permission, it stops running.

End the contract. The software ends with it.

A software crate with sealed cores on a remote rack.

This isn’t only a security decision

You can say yes to more deals

The customers who insist on hosting it themselves are often the biggest ones. Right now, saying yes means giving your product away. It doesn’t have to.

Renewals get easier

“What happens if we don’t renew” stops being an awkward question and starts being a clear answer.

Your pilots have an end

Evaluations that expire on their own, rather than becoming free installs that quietly run for three years.

Protecting everything is impossible. Protecting the crown jewels isn’t.

Most attempts at this fail for the same reason: they try to lock down an entire codebase, slow everything to a crawl, break the build, and get switched off within a quarter.

Almost none of your code is the reason customers pay you. The routing, the logging, the forms, the config: all of it is fine in the open and always was.

The pricing logic. The scoring model. The matching engine. The thing you’d be genuinely afraid to see in a competitor’s product. That’s a small, findable part of what you ship, and protecting only that is something that actually works, and keeps working.

The team keeps working the way they always have

They write code normally

Nothing changes about how your engineers build. The protection happens when you package a release, not while they work.

Locked code still behaves

Developers who don’t need to see the protected parts can still build against them, because the code they call back works exactly as expected.

No new language, no rewrite

It works with what you already have. There’s no port, no migration, and no “rebuild it our way.”

Your build stays your build

It fits into how you already ship, rather than replacing it.

Control per customer, not just per product

Cut off one customer

End their access without touching anyone else’s.

Set an end date

Access that expires when the contract does, automatically.

See where it’s running

Which customer, which deployment, when it last checked in.

Trials that really end

A pilot that stops working on day 31, without a conversation.

Non-payment has consequences

Renewal leverage that doesn’t depend on goodwill.

Every check is recorded

A full history of what ran, where, and when.

This is for you if…

You sell software your customers install and run themselves
You’ve lost a deal, or won one, because you were willing to deploy on-prem
A small part of your codebase is genuinely irreplaceable
Your contracts say what happens at termination, but nothing enforces it
You’ve been asked “what stops them just keeping it?” and didn’t love your answer

The questions everyone asks

Will this slow our software down?

No. The protection isn’t in the way of your product doing its job.

Do our customers have to change anything?

They install and run your software the way they always have. The permission check happens underneath.

What if a customer’s network goes down?

We design for the real world. Brief outages don’t take your customer’s production system offline, and we’ll walk through exactly how that works on a call.

What happens when we revoke?

Their deployment stops being able to run the protected parts. It’s effective on their side without you needing anything from them.

How much of our code does this apply to?

Usually a small fraction: the part that’s actually yours. We’ll show you which parts on a call, using your own codebase.

Can we start with one product?

Yes. Most companies protect one product line first.

Find out what’s worth protecting

Book a call and we’ll walk through your own codebase, to find which parts are genuinely irreplaceable and what it takes to lock them.