Patent or Trade Secret for a Software Company?
Patent the innovation a competitor can see in your product and copy by reverse-engineering it. Keep as a trade secret the advantage that stays hidden in your backend, data, or process and only holds value while nobody else can see it. For most software companies the real answer is both: patent the few things a rival could rebuild by watching your product, and protect everything else, the algorithms, the training data, the infrastructure, as trade secrets locked down with contracts and access controls. The test is not how clever the thing is. It is whether it is visible in what you ship.
Why founders get this wrong
The common mistake is treating the choice as a status contest. Founders want the word patent on the pitch deck because it sounds like a moat, so they file on things that were never going to hold, and skip protection on the parts that actually make the company hard to copy. I have watched teams spend 25,000 US dollars patenting a workflow a competitor could rebuild in a weekend, while the real edge, a data pipeline nobody outside the company understood, sat protected by nothing but a handshake.
The second mistake is not knowing that a patent publishes. File one, and roughly 18 months later your invention is public, indexed, and readable by every rival on earth. If the thing you filed was better kept quiet, you just handed the recipe to the market in exchange for a right that expires in 20 years and costs real money to enforce. Trade secret law protects something forever, as long as it stays secret. Coca-Cola never patented its formula, and that is not an accident.
The framework I use with clients
The decision comes down to four questions, asked in this order. Run each asset through them before you spend a dollar on filing.
- Is it visible in the product? Ship the software, hand it to a sharp engineer, and ask whether they could reverse-engineer the innovation from what they see. If yes, secrecy is already lost the moment you sell, so patent it. If the value lives in a backend model, a data set, or a process the customer never touches, secrecy is intact and worth keeping.
- Is it patent-eligible and non-obvious? Since the Alice decision in 2014, a generic idea on a computer does not qualify. You need a specific technical improvement: lower latency, less memory, a concrete problem solved in a way that is not obvious. If it clears that bar and step one said visible, file. If it fails eligibility, a patent was never on the table, so protect it as a secret regardless.
- Will you actually enforce it? A patent is worth what you will spend to defend it, and software litigation runs into the hundreds of thousands of dollars. If you would never sue, the patent is a plaque, not a moat. Its remaining value is defensive, deterrence and something to trade in a dispute or an acquisition. Be honest about which one you are buying.
- Can you keep the secret secret? Trade secret protection requires proof you took reasonable steps: access controls, need-to-know internally, confidentiality clauses in every employee and contractor contract, and exit procedures that cut access on day one. No steps means no protection when it leaks. If you cannot lock it down, secrecy is a false comfort, and you either patent or accept the exposure.
| Asset | Usually | Why |
|---|---|---|
| User-facing feature or UX flow | Patent (if eligible) | Visible on ship, easy to copy |
| Novel algorithm with a technical improvement | Patent or secret | Depends on whether outputs reveal it |
| Machine learning model weights | Trade secret | Hidden, hard to reverse, not worth publishing |
| Training data and data pipeline | Trade secret | The durable edge, keep it dark |
| Internal tooling and infrastructure | Trade secret | Customer never sees it |
From my operating seat
When I have run IP strategy for companies before an exit, the split above is what a buyer actually pays for. In one diligence process the acquirer barely looked at the two patents on the wall. What they priced was the data asset and the pipeline behind it, and the first question their lawyers asked was whether every engineer who ever touched it had signed a proper assignment and confidentiality agreement. Because we had those contracts in order, the trade secret held up and the number held with it. Loose paperwork there is the single most common way I see a data moat evaporate in the room.
I run this exact audit with founders across NYC, London, and Dubai. We list every asset, mark each one visible or hidden, then file narrowly on the handful that are both visible and defensible and build a hard secrecy perimeter around the rest. The mistake I unwind most often is over-filing: a founder who patented five things, three of which taught competitors more than they protected, and left the actual crown jewel, the training data, sitting behind a password and a hope. Fewer patents, tighter secrets, cleaner contracts. That is the setup that survives diligence.
Can you patent software in 2026?
Yes, but not software as such. You cannot patent an abstract idea running on a generic computer, and since the Alice decision in 2014 that bar has held firm. What survives is a claimed technical improvement: a method that makes a machine work measurably better, cuts memory or latency, or solves a concrete technical problem in a non-obvious way. Granted or rejected comes down to the drafting, claim the technical mechanism, not the business result. Budget 18 to 36 months to grant and 15,000 to 30,000 US dollars per patent.
What are the risks of patenting instead of keeping it secret?
A patent publishes, so about 18 months after filing your invention is public and every competitor can read it, and when the 20-year term ends anyone can use it freely. You also carry enforcement cost, because a patent is only worth what you will spend to defend it and software infringement is hard to prove. The trade secret risk cuts the other way: protection dies the instant the secret leaks or someone independently invents it, with no recourse if they got there honestly. Patent when disclosure is unavoidable anyway. Keep it secret when you can truly keep it secret.
How do I protect a machine learning model or training data?
Trade secret is usually the stronger fit. Model weights, training data, and the pipeline that produces them are rarely visible in the product and rarely worth publishing in a patent, so keep them behind access controls, need-to-know internally, confidentiality clauses in every contract, and a rule that data never leaves your environment. Patent only the narrow, novel methods a competitor could observe or reverse-engineer from your outputs. For most AI companies the winning setup is a small patent wall around the visible mechanisms and a hard secrecy perimeter around the data and weights that actually drive the results.
Decide it asset by asset, not by instinct
This is the exact problem I advise on: auditing every piece of IP, marking it visible or hidden, filing narrowly where it holds, and locking down the secrets and contracts that a buyer will actually pay for. Get the split wrong and you either teach your competitors or lose your moat. See more about how I work on IP and data strategy or book a call.
Book a call →