Skip to content
{} zero dependency

72-hour hackathon

ZERO DEPENDENCY

Standard library only. No packages. No supply chain. Just skill.

  • August 28-31, 2026
  • Online
  • Free
  • 6 tracks

Half your code is written by an AI that hallucinates the other half's package names. The registry it pulls from added 454,600 malicious packages last year alone. This hackathon is the counter-move: build something real using nothing but the language you already have.

// four numbers

By the numbers

Why an empty manifest is the point.

1,200+

dependencies in a typical modern web application, once the full transitive tree is counted. [7]

19.7%

of packages suggested by AI coding models don't exist. Attackers register the names the model reliably invents. [13][14]

1.2M

malicious open-source packages now catalogued across public registries, up 75% year over year. [1]

72h

to ship something genuinely useful with none of them.

// how we got here

Every dependency is a stranger

In 2016 a developer unpublished left-pad, eleven lines that pad a string, and broke Babel, React, and thousands of builds across the internet.[8][9] The lesson everyone took was "don't let one package vanish." The lesson nobody took was "why did a string-padding function need to be a package?"

Ten years later the answer is worse than we thought. The average npm project carries 49 direct and 79 transitive dependencies.[6] Count the full tree and a modern web app pulls in 1,200 or more.[7] Roughly 16.8% of all npm packages are trivial one-liners, and the proportion keeps rising.[10] We outsourced String.padStart() to a stranger and called it engineering.

Then the bill came due. In September 2025, an attacker phished the maintainer of chalk and debug, utilities with a combined 2.6 billion weekly downloads, and shipped a crypto-clipper that rewrote wallet addresses in memory.[2] Days later the industry met Shai-Hulud, the first self-replicating npm worm: it stole tokens, republished itself into other packages, and hit around 500 of them before anyone caught up.[3] And in 2024 the world came within one code review of catastrophe when a patient attacker spent two years earning maintainer trust on xz, a compression library run by a single unpaid volunteer, and planted an SSH backdoor that nearly shipped to every Linux server on earth.[4]

Now add the accelerant. Roughly 46% of new code on GitHub is AI-generated, and between 45% and 62% of it ships with a known class of vulnerability.[11][12] Worse, the models invent dependencies: across 576,000 samples, 19.7% of the packages AI suggested did not exist.[13] The fake names repeat, so attackers pre-register them and wait, a supply-chain attack where the victim never even makes a typo. The machine does it for them.[14]

Zero Dependency is a 72-hour hackathon with one rule underneath everything else: the dependency manifest ships empty. Standard library only. Build a real tool, a parser, a server, a datastore, a password manager, the way you would have before we forgot how. Every line is yours. Nothing to audit but your own craft.

The antidote to "the AI added a package that doesn't exist" is adding no packages at all. You have 72 hours.

// A through F

Six tracks

Six categories of genuinely useful software, each buildable in 72 hours on a laptop, each normally drowning in dependencies. Pick one.

A

Developer Tools & CLI

The daily-driver track. A linter, formatter, task runner, git helper, or file utility, the kind of tool most people reach for a dozen packages to build. Do it with the standard library.

  • Solves a real workflow annoyance you actually have
  • Ships as a single runnable artifact with a clean CLI surface (flags, exit codes, sane stdout/stderr)
  • Uses only stdlib for argument parsing, file walking, and output, no helper packages
  • Reads as idiomatic to a senior reviewer in your language
Tooling authorsDX engineersCLI builders
B

Parsers & Data Formats

The from-scratch track. A JSON, CSV, Markdown, or config parser. A template engine. A regex engine. A serializer. The things everyone imports and almost nobody has written.

  • Correctly handles the ugly edge cases, not just the happy path (escaping, nesting, malformed input)
  • Reports useful errors with position information
  • Has a test suite that proves the edge cases pass
  • Implements the format by hand, with no parsing or serialization package
Language nerdsCompiler folksCraftspeople
C

Web & Network

The stdlib-net track. An HTTP server or router, a static-site server, an HTTP client, a DNS tool, a chat over raw TCP. Built on your language's networking primitives and nothing above them.

  • Handles concurrent connections without a framework
  • Speaks the protocol correctly enough to interoperate with real clients or servers
  • Uses only the stdlib networking layer (net / http / sockets), no framework or client library
  • Documents its concurrency model honestly
Backend engineersSREsProtocol enthusiasts
D

Data & Storage

The storage-engine track. A key-value store, an embedded database, a cache, a log-structured store, a search index. The layer most apps rent from a library and never look inside.

  • Persists and retrieves correctly across process restarts
  • Documents its durability and consistency guarantees, and where it cuts corners
  • Uses only stdlib file, buffer, and hashing primitives, no storage or serialization dependency
  • Survives a basic crash or concurrent-access test
Backend engineersDatabase curiousSystems folks
E

Security & Crypto Utilities

The trust-nothing track. A password manager, a TOTP/2FA generator, a file encryptor, a hasher, a secrets scanner. Security tools, ironically, are where a stray dependency hurts most, so build one with none.

  • Uses only the standard library's crypto primitives, never a third-party crypto package
  • Never rolls its own cipher: compose stdlib primitives correctly, don't invent them
  • Handles keys, salts, and secrets with documented, defensible choices
  • Fails safe, with honest notes on its threat model in the README
Security engineersBackend engineersPrivacy builders
F

Open / Wildcard

Surprise us. A game, a visualizer, an interpreter, a compression tool, a scheduler, anything genuinely useful that a reasonable engineer would assume needs packages. Pick it, build it stdlib-only, and justify the build in your README.

  • Solves a real problem people would actually use
  • Would normally be assumed to require third-party dependencies
  • Ships with an empty manifest and a README explaining how you avoided the usual imports
  • Reads as idiomatic and intentional, not a stunt
PolyglotsGeneralistsAnyone with something to prove

// verifiable at a glance

What counts as "zero dependency"

The one rule that defines the event. Read this before you pick a track.

Zero third-party runtime dependencies. Your shipped artifact's dependency manifest is empty. That's the line, and it's verifiable at a glance:

JavaScript / TypeScript
Node (or Deno/Bun) built-ins only. package.json dependencies is {}. No npm installs.
Python
The standard library only. No pip install. requirements.txt empty or absent.
Go
stdlib only. go.mod has no require block (the toolchain and golang.org/x are not a free pass, stdlib means stdlib).
Rust
std only. Cargo.toml [dependencies] empty. No crates, including no serde.
C / C++
libc and POSIX only. No vendored third-party libraries.
Java / Kotlin / C#
The platform standard library (JDK / BCL) only. No Maven/NuGet runtime deps.

Allowed, and not counted against you: your language's own compiler, build tool, and formatter; a standard-library test tool where one exists.

The one grey area, ruled: if your language ships no test framework at all, a dev-only test dependency is permitted, but it must never appear in the runtime artifact, and you must disclose it in STDLIB.md. Test tooling is the only exception. Everything the program actually runs on must be standard library.

And the obvious loophole, closed: copying a library's source into your src/ to fake an empty manifest is a dependency with extra steps. If you vendor any code you didn't write this weekend, disclose it in STDLIB.md or it scores against you, under Scoring.

// the receipts

What you ship after 72 hours

A working tool with an empty manifest. Not a proof of concept. Not a slide deck.

A working, useful program. It builds with one command and does something a real person would want. "Technically zero-dep but does nothing" is not the assignment.

An empty dependency manifest, verifiable on sight: package.json deps {}, empty requirements.txt, go.mod with no require, Cargo.toml with no dependencies.

A dependency proof. The output of the command that lists your dependencies (or your CI log), showing zero third-party runtime deps. Make it trivial for a judge to confirm.

Honest documentation. A STDLIB.md that names each package you would normally have installed and the standard-library feature you used instead. This is the receipt that makes the constraint judgeable, and it counts toward your score.

You'll submit:

  • Public GitHub repo with the tool
  • Build command that produces a runnable artifact in one step
  • Empty dependency manifest for your language
  • Dependency proof (command output or CI log showing zero third-party deps)
  • README.md: what it does, how to run it, its limits
  • STDLIB.md: every stdlib-for-package substitution you made
  • 5-minute demo video showing the tool working and the manifest being empty

// the file tree

Anatomy of a zero-dep submission

What a serious submission looks like on disk.

your-tool/
your-tool/
├── README.md
what it does, how to run, honest limits
├── STDLIB.md
every "I'd normally import X, instead I used stdlib Y"
├── Makefile / build
one command to a runnable artifact
├── src/
your code, all of it written this weekend
├── tests/
proves the edge cases pass
├── package.json
dependencies: {} (or go.mod / Cargo.toml / requirements.txt, empty)
├── deps-proof.txt
output showing zero third-party deps
└── .zero-dep.toml
track letter, one-line pitch
01

One command builds.

make, cargo build, go build, docker compose up. If a judge has to read your CI to figure out how to run it, you've failed this rule.

02

The manifest is the rulebook.

Empty is empty. A judge should confirm zero deps in five seconds, not five minutes.

03

STDLIB.md counts.

It feeds directly into Zero-Dependency Craft (30%). Empty bullets don't count; real substitutions do.

04

Numbers are honest.

If your parser is slower than the one you'd normally import, say so. A naive but honest implementation scores above a fast one that hides its corners.

Layout is advisory. Judges read what you actually ship.

// +5 or +3

Bonus points

Optional. Pick one and nail it. Don't half-do all four.

Single File

+5
Hard

Ship the entire project as one source file that is still genuinely useful. No src/ tree, no modules, one file a person could read top to bottom and understand.

Reproducible Build

+5
Hard

Build your artifact twice and produce byte-identical output. Publish both hashes. Determinism is the discipline that most dependency-heavy stacks quietly lost.

Package Killer

+3
Medium

Cleanly reimplement a specific package that people actually install (left-pad, is-even, a chalk-style colorizer, a requests-style client) and document the replacement in STDLIB.md. Bonus weight for killing something with millions of weekly downloads.

STDLIB Log

+3
Medium

Submit a STDLIB.md with at least 10 real, non-trivial stdlib-for-package substitutions, each with a one-line rationale. Judges will read it. Empty bullet points won't count.

// what to skip

Out of scope

Save yourself the trouble. These won't score well.

We're not against libraries. We're testing whether you still know what's underneath them.

// pre, during, after

Timeline

All times UTC.

Pre-Event

  • July 31, 2026
    Registration opens

    Join the Discord, start thinking about what you'd build.

  • August 24, 2026
    Team formation

    1-4 people per team. Solo welcome.

  • August 26, 2026
    Cheat-sheets posted

    Standard-library cheat-sheets and per-track guidance posted.

Hackathon · 72h

  • August 28, 2026 · 18:00 UTC
    Kickoff

    Hacking begins.

  • August 31, 2026 · 18:00 UTC
    Code freeze

    Submissions due. Empty manifests verified.

Post-Event

  • Aug 31 to Sep 10, 2026
    Judging window

    Each project reviewed independently by multiple judges on structured forms across the one-week window. Weighted scores and written feedback to every team.

  • September 11, 2026
    Winners announced
  • Sep 11 to 18, 2026
    Community voting
  • September 19, 2026
    Community Choice announced

// how judges rank

Scoring

Each project is rated on a 5-point scale across four weighted criteria. Final ranking is the weighted average across all judges who evaluated the project.

Functionality & Usefulness

35%

Does it build with one command, run, and do something a real person would want? A useful tool with a rough edge beats a polished thing that does nothing. This is the largest weight for a reason: the constraint is the point, but the software still has to matter.

Zero-Dependency Craft

30%

How well did you replace what you'd normally import? Empty manifest verified at submission. STDLIB.md quality lives here: the depth and honesty of your stdlib-for-package substitutions. Vendoring source to fake an empty manifest is penalised here.

Code Quality & Idiom

25%

Does the code read as idiomatic to a senior reviewer in your language, or as a fight against the standard library? Elegance of the hand-rolled implementation, clarity of error handling, sensible structure.

Innovation

10%

Creative wildcard picks. A genuinely surprising thing built with nothing but stdlib. The submission that makes a judge say "I didn't know you could do that without a package."

Bonus challenges

Challenge Difficulty Pts
Single File Hard +5
Reproducible Build Hard +5
Package Killer Medium +3
STDLIB Log Medium +3

// five ways to win

Prizes

$1,800 total prize pool.

1st Place Grand
$800

Grand Prize

The tool that was genuinely useful, provably zero-dep, and read as if the standard library were plenty all along. The one a judge wanted to install.

1st_place.installed = true
2nd Place
$400

Runner-Up

Exceptional execution across the board. Real utility, clean stdlib craft, an honest STDLIB.md. Almost took the crown.

3rd Place
$200

Third Place

A standout, either for the surprising thing it built or the popular package it made look unnecessary.

Package Killer
$100

Best Reimplementation

For the team whose stdlib reimplementation most convincingly replaced a package people actually install, documented in STDLIB.md, ideally something with real download numbers behind it.

Community Choice
$300

Voted by fellow participants

The zero-dep tool other engineers most want to use, fork, or keep.

// nine of them

Rules

What counts as a valid submission.

Zero Third-Party Runtime Dependencies

The core rule. Your shipped artifact's dependency manifest is empty. Standard library only. See What counts as zero dependency for the per-language definition.

What Counts as Standard Library

Defined per language under What counts as zero dependency. Your compiler, build tool, and a stdlib test tool are fine. If your language ships no test framework, a dev-only test dependency is allowed but must be disclosed in STDLIB.md and never ship in the artifact.

Standalone & Runnable

Your tool must build with a single command and produce a runnable artifact. No "works on my machine" submissions.

New Code Only

All code written during the 72-hour window. AI assistance and standard-library use are fully expected. A pre-existing project of yours is not eligible.

No Vendoring to Fake It

Copying a third-party library's source into your repo to keep the manifest empty is still a dependency. If you include any code you didn't write this weekend, disclose it in STDLIB.md, or it scores against you.

Team Size

1-4 people. Solo entries welcome. Find teammates on the Hackathon Raptors Discord before or during the event.

Pick a Track

Choose one track A-F. Your submission must clearly target it. Track F (Open) requires a defensible rationale in your README.

Source Code Public

GitHub repo, OSI-approved license, public at submission. Anonymous-username submissions accepted, but the team must be reachable for written follow-up by judges during the evaluation window.

AI Tools Are Expected

Claude Code, Cursor, Aider, Copilot, local models, bring whatever you've got. We don't gatekeep on whether you used AI; we gatekeep on whether the result holds up. The README, STDLIB.md, and empty manifest are the receipts. If the artifact can't be defended in writing, it scores accordingly.

// find your track

Who this is for

If you've ever npm install-ed a one-line function and felt something die inside, this is your hackathon.

Backend & Systems Engineers

You know what a socket and a byte buffer are. Build the server or store you'd normally rent from a framework.

Tracks ACD

Tooling & DX Engineers

You live in the CLI. Build the tool you use daily, with none of the helper packages you'd usually pull in.

Tracks AB

Security Engineers

A stray dependency is your job to worry about. Build a security tool that has none.

Tracks E

Database & Storage Curious

You've always wanted to know what's inside the storage engine. Now write one.

Tracks CD

Language Nerds & Craftspeople

Parsers, regex engines, interpreters, the from-scratch work that a package usually hides. Your home turf.

Tracks BF

Polyglots & Generalists

You've shipped in five languages and have opinions about all their standard libraries. Track F exists for you.

Tracks F

// panel announced jul 31

Judges

Senior engineers, architects, and technical leaders whose work spans systems programming, language tooling, security, and large-scale production software, the people who know exactly what a standard library can and can't do.

Full panel announced July 31, 2026

The judging panel goes live alongside registration. Want to nominate someone, or be nominated?

hello@raptors.dev →

// the short answers

FAQ

What's the team size limit?

1-4 people. Solo welcome. We recommend 2-3 for the 72-hour window.

Can I use AI code generation?

Yes, and you should. Claude Code, Cursor, Aider, Copilot, all expected. We don't score whether you used AI; we score whether the artifact holds up and whether you can explain it. The README and STDLIB.md are the receipts.

What languages can I use?

Any language with a standard library: JavaScript/TypeScript, Python, Go, Rust, C/C++, Java, Kotlin, C#, and more. The zero-dependency rules define "zero-dep" per language.

What exactly counts as the standard library?

See What counts as zero dependency. Short version: whatever ships with the language runtime. Your compiler, build tool, and a stdlib test tool don't count against you. Third-party packages of any kind do.

Can I use the package manager at all?

For dev-only tooling that never ships in the artifact (like a test framework, only if your language has none built in), yes, and you must disclose it in STDLIB.md. For anything the program runs on, no.

Is vendoring a library's source allowed?

Only if you disclose it in STDLIB.md, and it will count against your Zero-Dependency Craft score. Copying a package's code into src/ to keep the manifest empty is not zero-dep.

Can I start coding before August 28?

No code. Planning, sketching, reading standard-library docs, tuning AI prompts, all fine. Any project code committed before kickoff disqualifies the submission.

Does a slower or more naive implementation score worse?

Not automatically. Honest and correct beats fast and hand-wavy. If your stdlib version is slower than the package it replaces, say so, that disclosure scores better than hiding it.

What's the Package Killer bonus?

Cleanly reimplement a specific package people actually install and document the swap in STDLIB.md. Killing something with millions of weekly downloads carries more weight than killing an obscure one.

Can I ship the whole thing as a single file?

Yes, that's the Single File bonus (+5), as long as it's still genuinely useful.

What if my language has a tiny standard library, like C or Rust?

That's part of the challenge, and judges weigh it. A capable tool built on a minimal stdlib is more impressive, not less. Track E aside, you're rewarded for doing more with less.

What if I genuinely need one thing the stdlib doesn't have?

Then that's the interesting part of your submission: write it, and document it in STDLIB.md. The whole event is the discovery of how much the standard library already gives you.

// 2025 into 2026

The supply chain became the story of the year

Public registries catalogued 454,600 new malicious packages in 2025, pushing the cumulative total past 1.2 million, a 75% jump, against 9.8 trillion open-source downloads.[1] The chalk and debug compromise put a crypto-clipper inside utilities with 2.6 billion weekly downloads.[2] Shai-Hulud became the first npm worm to replicate itself across packages.[3] The xz backdoor showed that the whole edifice can rest on a single unpaid maintainer, two years of manufactured trust, and one obfuscated commit.[4] And years-old holes stay open: Log4Shell was still downloaded 42 million times in 2025, 13% of them the versions with the known hole.[5]

Meanwhile the tooling meant to save us is drowning us. 65% of teams admit to bypassing or delaying dependency fixes because of alert fatigue.[15] The automated fixer resolves less than half of what it flags for most teams.[16] So the alerts get an || true and the vulnerabilities ship.

And now the machine writing half our code[11] reaches for a dependency by reflex, sometimes one that doesn't exist, until an attacker makes it exist.[13][14] Generating code that imports ten packages is trivial. Building something real that imports none is the skill worth proving. That's the hackathon.

// 16 sources

References

  1. [1]
    Sonatype, "2026 State of the Software Supply Chain" (malware +75%, 1.2M cumulative, 9.8T downloads) https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware
  2. [2]
    Sonatype, "npm chalk and debug packages hit in supply chain attack" https://www.sonatype.com/blog/npm-chalk-and-debug-packages-hit-in-software-supply-chain-attack
  3. [3]
    Palo Alto Networks Unit 42, "Monitoring npm supply chain attacks (Shai-Hulud)" https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
  4. [4]
    CrowdStrike, "CVE-2024-3094: the XZ Utils upstream supply chain attack" https://www.crowdstrike.com/en-us/blog/cve-2024-3094-xz-upstream-supply-chain-attack/
  5. [5]
    Sonatype, "2026 State of the Software Supply Chain: Vulnerability Management" (Log4Shell 42M downloads in 2025) https://www.sonatype.com/state-of-the-software-supply-chain/2026/vulnerability-management
  6. [6]
    Snyk, "2024 State of Open Source Security" (49 direct / 79 transitive dependencies) https://ones.com/blog/understanding-transitive-dependencies-npm-simplifying-nodejs-project/
  7. [7]
    OneUptime, "The hidden costs of dependency bloat in software development" (1,200+ full-tree dependencies) https://oneuptime.com/blog/post/2025-09-02-the-hidden-costs-of-dependency-bloat-in-software-development/view
  8. [8]
    Wikipedia, "npm left-pad incident" https://en.wikipedia.org/wiki/Npm_left-pad_incident
  9. [9]
    The Register, "How one dev broke Node, Babel and thousands of projects in 11 lines of JavaScript" https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
  10. [10]
    Socket, "Understanding the risks of trivial packages" (16.8% of npm is trivial) https://socket.dev/blog/understanding-the-risks-of-trivial-packages
  11. [11]
    OX Security, "Vibe coding security: why AI-generated code ships with vulnerabilities" (46% of GitHub code AI-generated; 62%) https://www.ox.security/blog/vibe-coding-security/
  12. [12]
    Veracode, "2025 GenAI Code Security Report" (45% of AI-generated code carries an OWASP Top-10 flaw) https://www.datahogo.com/en/blog/vibe-coding-security-risks
  13. [13]
    Spracklen et al., "Package hallucinations" (USENIX Security 2025) (19.7% of AI-suggested packages hallucinated across 576k samples) https://www.rescana.com/post/ai-hallucinated-dependencies-in-pypi-and-npm-the-2025-slopsquatting-supply-chain-risk-explained
  14. [14]
    Wikipedia, "Slopsquatting" https://en.wikipedia.org/wiki/Slopsquatting
  15. [15]
    Aikido Security, "2026 State of AI in Security & Development" (65% of teams bypass or delay dependency fixes) https://www.aikido.dev/blog/npm-audit-guide
  16. [16]
    Snyk, "2025 State of JS" (npm audit fix resolves fewer than half of vulnerabilities for 62% of respondents) https://www.pkgpulse.com/guides/why-npm-audit-is-broken

// 72 hours. one rule.

Every dependency is a stranger.
This time, invite none.

The standard library and whatever you can do with it.