The Disappearing Moat in Software

Five years ago, I would have told a founder to build in public. Today, if the work is genuinely original, I think that advice is reckless.

The old advice made sense in a different time. Sharing the process could attract early users and customers, sharpen the product, build trust, and give a company distribution before it had a marketing budget. Implementation still took long enough for an audience to become an advantage before a spectator became a competitor.

That deal has inverted. Public attention no longer arrives alone. A detailed thread, architecture post, benchmark, or demo can give a fast follower the problem, the shape of the solution, the dead ends to avoid, and proof that somebody will pay. LLMs and agentic harnesses make acting on that information way too easy, cheap, and fast. Abundant capital makes acting on it at scale possible.

The valuable stack now sits before the repository: the investigation that identifies the genuine problem, the research that exposes the pressure points, the vision that connects them, the architecture and primitives that make the vision consistent, the math that makes it plausible, and the experiments that prove it can work.

Code is the residue of resolved uncertainty. The vision, risk tolerance, and sheer will to keep working on the problem while other teams close billion-dollar deals for services wrapping open-source databases… this is where the value now lies.

I am applying this conclusion to my own work in data infrastructure, where I am keeping the underlying research and architecture private.

A technical moat must now be built under the cover of night.

Why the Economics Changed

The software we all grew up with used to borrow defensibility from friction. Implementation took time and huge sums of cash. Migrations were miserable. Contracts, procurement, integrations, and user habits slowed movement. A competitor could understand the product and still need years to reproduce it, sell it, and move customers onto it.

Some of those switching costs remain real. Data gravity, trust, regulation, operational knowledge, and deeply embedded workflows do not evaporate because a model can write the code… but much of what software companies called a moat was simply the cost of rebuilding what they had already built. Our industry is mistaken: expensive substitution is no longer a durable advantage.

I use LLMs to code every day; they make me much faster. In the hands of a professional who can frame a problem, inspect the result, and reject garbage… the current models and harnesses accelerate research, exploration, implementation, testing, migration, and iteration in a way that must redefine what we view as possible.

There is no universal multiplier. In a 2026 follow-up investigation, METR said selection effects, withheld tasks, and concurrent agents prevented a trustworthy task-level estimate. A separate field study across 4,867 developers found 26% more completed tasks with a coding assistant. If you work in software, you know this already.

There is a substantial win in using LLMs effectively.

The Substitution Model

The competitive change becomes easier to see when the cost of copying is decomposed into clear jobs:

time to substitute = problem selection + investigation + solution design + validation + implementation + distribution

This conceptual model shows which costs move from the follower to the originator.

Public disclosure can transfer problem selection, investigation, solution design, and validation before a competitor writes a line of code. LLMs can compress implementation. A well-funded incumbent may already own distribution. No agent needs to recreate a company from a blog post; a capable team only needs to become faster after somebody else has reduced the solution space.

Execution still matters. An original idea without it is a journal entry, not a company… but execution multiplies the insight; it does not replace it.

Publication Is Now Part of the Attack Surface

As founders, we already treat credentials, customer data, source access, and production infra as security decisions. Original technical insight now deserves the same treatment.

“Build in Public” can mean publishing revenue, documenting failures, sharing a roadmap, posting screenshots, releasing source, or explaining the architecture. It’s a continuum.

The safe point on that continuum has shifted. A progress update is no longer harmless when it makes the destination clear. A benchmark can reveal the constraint or problem worth solving. A diagram can expose the primitives necessary for the breakthrough. A thread can validate demand before the originator has a product. A demo can prove that an impractical architecture is now within reach.

A founder can leak the company one progress post at a time and call it marketing. The source can remain private while the expensive upstream work becomes public.

That is why I keep my own data-infrastructure work private. More than a year of testing, benchmarking, and discarded ideas should not become somebody else’s specification before I can convert it into an advantage that survives disclosure.

Building quietly does not have to mean building alone. A founder can work with narrow design partners, trusted domain experts, private evaluators, and advisors. The team can run controlled experiments, learn from customers without disclosing the mechanism, and reveal only what a specific relationship needs. Private validation is slower and less flattering than broadcasting every insight. That is the cost today.

The new rule: publish when you can turn attention into a genuine compounding advantage faster than competitors—real or perceived—can turn disclosure into a substitute. Funding, distribution, operating capacity, accumulated data, physical infrastructure, or a growing ecosystem can create that threshold. Until then, silence is time purchased for the original team.

What Survives Imitation?

My argument isn’t that every founder should take an ordinary product underground. Secrecy can’t save an ordinary idea. A useful product, a novel idea, and a defensible business are three different things.

Defensibility has two layers: advantages that survive disclosure, and protected insight that buys time to build them.

original insight → information asymmetry → protected time → compounding advantage → moat

In my opinion, there are three especially important forms of defensibility that survive imitation:

1. Data. Legally and ethically usable proprietary data can improve a product in ways a competitor cannot reproduce. Public data and raw volume are not enough. A 2026 study of data and firm market power found that AI disproportionately benefits data-rich firms, but raw data can have negative returns without sufficient processing capability. The defensible asset is the learning loop: collection rights, exclusive observations, processing, and a product that improves through use. There is a lot of room here, too. I don’t think many companies are doing this well today.

2. Physical Capability/Hardware. Controlled access to scarce capacity, power, memory, interconnect, custom silicon, and the operational competence to use them can be durable. A rack of commodity GPUs is not. A model can write deployment code; it cannot conjure fabrication, power, or scarce capacity.

3. Accumulated systems. Distribution, embedded workflows, integrations, trust, standards, ecosystem position, and operational knowledge grow through use and investment. They cannot be downloaded from the same upstream provider or reconstructed from a launch post.

Original architectures, primitives, algorithms, and math belong to the second layer. They are not necessarily moats. They are options on moats: asymmetric starting positions that must be exercised before the design travels independently of its inventor.

Vision chooses the hard problem. Drive stays with it long enough to turn protected insight into one of these assets. Without the first, the second mostly produces a polished substitute.

A founder evaluating a supposed moat should ask three questions:

• Could a capable competitor recreate this from public information and the same models or services we use?
• Does our advantage improve through use and investment, or does every competitor receive the same upstream improvements?
• Do we control a scarce input, or merely rent one that anybody with a credit card can access?

If the answers are “yes,” “no,” and “rent,” there is no moat. There is a lead, and the clock is ticking.

Secrecy Is a Window, Not a Business Model

Secrecy protects the head start. It does not compound it. In fact, it likely hurts if held too long.

A private architecture with no product, customer, data, operation, or path to market is hidden, not defensible. Silence preserves time to convert original thought into assets that survive being seen.

Software startups need to start keeping trade secrets. In the US, technical and engineering information can qualify when it derives economic value from secrecy and the owner takes reasonable measures to protect it. Public disclosure can destroy that status; independent invention and lawful reverse engineering remain fair game. The Department of Justice and USPTO describe those lanes. Obviously, this isn’t legal advice. The point is that secrecy buys a window, not a monopoly on thought.

Escaping the Copyable Layer

The useful examples are companies that use an initially replicable product, or an initially private insight, to accumulate assets that become progressively harder to reproduce as the company scales.

Cursor started by forking VS Code. A code editor built by open-source contributors and wrapped around foundation models owned by other labs was not a moat. Someone at Cursor had the vision to recognize that and the consistency and risk tolerance to build beyond the product that made Cursor famous.

The company moved upstream. Cursor built Composer models and a feedback loop around what users accept and keep in a codebase. Its router was trained on more than 600,000 live requests, creating proprietary information about real coding behavior. Cursor describes that loop here. When model training became compute-constrained, a partnership and later acquisition gave it access to SpaceX’s GPU fleet. Cursor’s account and acquisition announcement make the transition real.

Cursor accumulated two important forms of technical defensibility: a differentiated data loop and controlled physical compute. It did not make the wrapper defensible. It moved until the wrapper was no longer the whole company.

Luck does not erase the work. It describes the alignment of timing, capital, adoption, leadership, and acquisition opportunity that let the work compound. Most wrappers will not receive enough time or money to repeat that escape. Treating Cursor’s outcome as a general playbook is a recipe for failure. A ton of smart capital will go up in flames here.

The correct length of silence is not six months, a seed round, or a ritual launch date. It is a state transition. Disclose when the company has enough funding, distribution, data, physical capacity, operating knowledge, standards position, or community momentum to benefit more from openness than imitators do. Until then, build something worth revealing.

Antithesis took the opposite path. It spent five and a half years in stealth building a deterministic simulation platform around a custom hypervisor. It can run an entire distributed system, inject failures, rewind execution, and reproduce the bugs it finds. Jane Street’s first run found two previously unknown bugs in an internal distributed message bus; it later led Antithesis’s $105 million Series A. This is original computer-science work converted into an operational system, customer trust, and a product that becomes more valuable as AI makes code cheaper while verification remains hard. This is the vision I’m referring to. This is the consistency, drive, and tolerance for risk needed today.

Raise the Ambition of the Problem

Founders should lean on LLMs aggressively: search the literature, run experiments, challenge assumptions, build simulations, test architectures, and eliminate dead ends. Use cheap implementation to attack problems that were too uncertain or expensive to investigate before. Do real work against reality and let the results change the plan.

Stop asking what can be shipped this month and start asking what is newly possible to investigate. Pick a real problem. Dig beneath the accepted architecture. Derive the primitive that should exist. Protect the work while it is fragile. Then apply the consistency and risk tolerance required to make it real.

Think for a second about the companies that came out of the 2000s. FAANG companies all exist today because someone had a vision and the stomach to see it through. SpaceX tackles real problems with novel solutions. If the science doesn’t work, they go back to the drawing board and find a way to make it work. Startups today feel stale, repetitive. We see no new entrants into ‘big tech’ because the companies being built are solving for mundane, useless problems.

LLMs have lowered the cost of implementation; they should raise the ambition of the problem, and significantly. This is how the next moats will be built.