For years, the software industry has embraced a culture of installing dozens—or even hundreds—of external libraries into nearly every project. Modern frameworks often rely on thousands of transitive dependencies, meaning a single application may ultimately depend on code maintained by hundreds of unknown contributors.
While this ecosystem has accelerated software development, it has also introduced a new class of risk: the software supply chain.
The 0deps Movement begins with a simple question:
What if an application depended only on code that it actually controls?
The Dependency Problem
Every dependency expands the attack surface.
It can:
- Introduce security vulnerabilities.
- Become the target of a supply chain attack.
- Be abandoned.
- Change its public API.
- Remove functionality.
- Break backward compatibility.
- Introduce new transitive dependencies.
- Publish incompatible releases.
In practice, developers lose control over a significant portion of the code that runs in production.
The larger the dependency tree, the larger the potential attack surface.
The Proposal
In the 0deps model, every required dependency is incorporated directly into the project repository.
Dependencies are no longer downloaded dynamically by package managers during installation or build.
Everything required to build and run the application already exists inside the repository from the moment it is cloned.
This provides several important benefits:
- Reproducible builds.
- Reduced dependency on external package registries.
- Centralized security auditing.
- Greater predictability.
- A smaller software supply chain attack surface.
Immutable Public Contracts
The core principle of 0deps is not immutable implementations.
Implementations evolve.
Algorithms evolve.
Security patches evolve.
What remains stable is the public contract.
Every library exposes a carefully designed public interface.
For example:
authenticate()
createSession()
verifyPasskey()
sendMagicLink()
These functions define a contract.
That contract never changes.
The underlying implementation can be completely rewritten.
Algorithms may change.
Internal libraries may be replaced.
Protocols may evolve.
Data structures may be redesigned.
None of these internal changes affect how the rest of the application interacts with the library.
Security Updates Without Breaking Applications
Whenever a security vulnerability is discovered, developers typically face two concerns:
- Fixing the vulnerability.
- Determining how many applications will break after the update.
Within the 0deps architecture, the second concern is largely eliminated.
Updates happen internally.
The implementation behind the interface is modified.
The public API remains exactly the same.
Applications continue working without requiring any code changes.
In other words, implementations evolve while contracts remain stable.
Internal Adapters
Every external integration is isolated behind an internal adapter.
Application
↓
Public Interface
↓
Adapter
↓
Implementation
If an external library becomes deprecated or unsupported tomorrow, only the adapter needs to change.
No other part of the application is affected.
This isolation dramatically reduces the impact of technology changes over time.
Invisible Versioning
Applications built on 0deps never interact directly with external library APIs.
They communicate exclusively with stable internal contracts.
Library versions become an implementation detail.
Framework maintainers assume responsibility for upgrades.
Application developers continue using the exact same interface regardless of internal implementation changes.
Software Supply Chain Security
The goal of 0deps is not to claim that software becomes invulnerable.
Its objective is to significantly reduce software supply chain risk.
By eliminating dynamic dependency installation during builds, the architecture reduces exposure to threats such as:
- Malicious package releases.
- Compromised package registries.
- Dependency confusion attacks.
- Typosquatting packages.
- Unexpected changes in transitive dependencies.
Every line of executable code becomes part of the project itself, allowing centralized auditing, version control, and security review.
Long-Term Stability
The greatest benefit of 0deps becomes evident years after a project is released.
Projects live for decades.
Libraries disappear.
Frameworks change.
Programming ecosystems evolve.
Despite all of that, applications continue interacting with the exact same public contracts.
Responsibility for adapting to ecosystem changes is centralized within the project's internal adapters instead of being distributed across every application that depends on those libraries.
Potentially disruptive upgrades become simple implementation replacements.
The Movement
The 0deps Movement is not opposed to open-source software.
Quite the opposite.
It recognizes the enormous value of open source while proposing a different consumption model.
Libraries are no longer treated as dynamically installed dependencies.
Instead, they become audited, version-controlled components encapsulated behind stable public contracts.
The result is software that is more predictable, more resilient, easier to maintain, and significantly less exposed to software supply chain risks.
Implementations may evolve indefinitely.
The contract remains unchanged.
And that stability allows applications written today to continue functioning exactly the same way many years into the future.