A product leader who designs freight logistics systems and began his career in strategic sourcing judged the Zero Dependency 2026 hackathon by asking the questions a supply chain manager asks of any vendor: what does this cost to own, what happens if it fails, and does it solve the real problem. The projects he rated highest replaced fragile suppliers with capability the team could stand behind.
Every physical supply chain has a list of single points of failure, and the people who run supply chains spend much of their time shortening it. A component that only one vendor makes, a route that only one carrier serves, a warehouse that handles all of a product’s volume: each is a risk that someone has to price and either accept or remove. Software has the same structure, but it is rarely managed with the same discipline. A modern web application can pull in more than 1,200 dependencies once the full transitive tree is counted, according to figures the Zero Dependency 2026 organisers cited. Each of those is a supplier. Most were never vetted.
The consequences are documented. In 2016 a developer unpublished left-pad, eleven lines that pad a string, and broke builds across the internet. In September 2025 an attacker phished the maintainer of chalk and debug, utilities with a combined 2.6 billion weekly downloads, and shipped code that rewrote wallet addresses in memory. And in 2024 the xz backdoor showed that a library running on servers everywhere could rest on a single unpaid maintainer and two years of manufactured trust. In the language of procurement, these are supplier failures: a single source, an unaudited vendor, a contract nobody read.
Rushikesh Hayatnagarkar has spent his career on the procurement side of that language. He is a Senior Product Manager at Amazon, now on Amazon Freight Partners after three years leading Private Brands products, where he designs and scales logistics systems for supply-demand matching, route optimisation, carrier cost engineering and capacity planning across more than 22 locations. He builds financial models that validate multi-million-dollar freight investment decisions, including statistical testing at 99 percent confidence on savings projections above $60 million, architects load planning systems for new freight types, and runs experiments that turn pilots into platforms. His expertise spans truckload, less-than-truckload, temperature-controlled and enterprise parcel logistics. He started as a Software Development Engineer at Dell in Bangalore, then spent six years at American Airlines as Global Commodity Manager and later Team Lead in Business Analytics, with a strategic sourcing role at Aetna along the way. He holds an MBA from Arizona State University, an MS in Analytics from Georgia Tech and a BE in Information Technology, and mentors founders through Alchemist Accelerator and ADPList on product management, growth and operational clarity. He remains a hands-on builder, writing custom Python implementations and architecting autonomous multi-agent AI workflows.
Zero Dependency 2026, organised by Hackathon Raptors, ran for 72 hours from August 28 to 31 with one rule: ship something genuinely useful with an empty dependency manifest, using only the standard library of the chosen language. 295 projects were submitted and judged. In his judge statement, Hayatnagarkar said he evaluates on three things: unit economics, system scalability, and whether a team is solving the root cause. The event’s own summary noted that he judged usefulness first, which matched the heaviest criterion on the scoring sheet: Functionality and Usefulness, at 35 percent.
The Package Killer he called first
The clearest example of removing a supplier entirely came from zdh, by The Goated Duo, an HTTP/2 server on the Go standard library. The project replaces golang.org/x/net/http2 and its HPACK package outright: all ten frame types, hand-built Huffman tables, flow control and stream state, running over raw TCP with no net/http underneath. It finished fourth overall at 4.66 out of 5 and won the event’s Package Killer award, given to the team whose standard-library reimplementation most convincingly replaced a package people actually install.
Hayatnagarkar’s review identified the craft before the award did. “Hand-rolling an RFC-compliant HTTP/2 frame processor and HPACK dynamic table compression entirely over raw TCP sockets showcases exceptional idiomatic concurrency and bit-level craft,” he wrote. The event recap later published that sentence alongside the award.
From a sourcing perspective, the decision is interesting because HTTP/2 is not a trivial dependency. It is a binary protocol with header compression, multiplexed streams and flow control, the kind of component most teams would never consider building. The Go project draws a deliberate line between its standard library and the extended golang.org/x packages, and the Zero Dependency rules held to that line: the toolchain and golang.org/x were not a free pass. Replacing a supplier of that complexity is expensive. The team covered that cost in engineering time, and in return the protocol layer became something they understood down to the bit.
Ghost inventory and hidden suppliers
In logistics, ghost inventory is stock the system says exists that is not actually on the shelf, or the reverse. Software has its own version: a dependency the manifest lists that the code no longer uses, or a dependency the code relies on that the manifest does not show. Both are failures of record-keeping, and both carry risk.
Darkroom, from Team-Smash-Kart, illustrated the first kind. Hayatnagarkar’s review opened with high praise: “Writing a baseline binary JPEG codec (DHT Huffman tables, zigzag dequantization, and IDCT) in pure Rust std is an incredible display of standard library craft.” Then came the catch: “There is a ghost dependency in the package.json (jpeg-js) that needs to be uninstalled.” The Rust codec did the real work. But a JavaScript manifest elsewhere in the repository still declared a JPEG package, which means anyone running an install against that manifest would still fetch that code from a public registry. A dependency that serves no purpose is the purest form of supplier risk: all of the exposure, none of the value.
The second kind showed up in Gitlens Zero, from Debuggers. “Helpful commit churn and author statistics, but relies heavily on spawning external git CLI subprocesses rather than parsing raw Git packfiles or object trees directly, limiting its zero-dependency craft score,” he wrote. A manifest can be empty while the program still depends on a tool installed separately on the machine. The event’s rules were explicit that this counts as hiding a dependency. For a supply chain manager, it is the equivalent of a vendor who does not appear on the approved list because the work is subcontracted through someone who does.
Usefulness before polish
The scoring rubric said a useful tool with a rough edge beats a polished thing that does nothing. Hayatnagarkar’s comments consistently started from that question. DepCheck-Go, from ZenYukti, drew one of his most complete endorsements of practicality: “Exceptionally practical developer tooling. Masterful orchestration of native go/parser, go/ast, and standard worker pools. It runs deterministically, integrates cleanly into CI pipelines, and solves a real problem with zero third-party AST libraries.”
Every clause in that review maps to an operational concern. Deterministic output means the tool gives the same answer on every run, which is the minimum requirement for anything that gates a deployment. Clean CI integration means it can be adopted without a project of its own. Solving a real problem is the root-cause test from his own judging statement. Using the Go toolchain’s built-in parser and syntax tree packages rather than a third-party library is the substitution the event was designed to reward.
Sysgaze, from nescio, a terminal telemetry monitor, earned credit for a similar reason. “Reading virtual filesystem counters directly (/proc/stat, /proc/meminfo, /proc/diskstats) and rendering an interactive TUI purely through raw ANSI escape sequences eliminates dependencies on gopsutil or tview,” he wrote. The project went to the source data the operating system already exposes, rather than buying it through an intermediary.
Mesh, from OneAbove, showed what happens when the substitution goes deep into infrastructure: “Implementing an append-only WAL with CRC32C frame checksums, atomic manifest commits, and native peer replication primitives in pure Go std sets the gold standard for the track.” Write-ahead logs, checksummed frames and atomic commits are the mechanisms that let a storage system recover from failure. Building them from standard-library primitives means the team owns the guarantees rather than renting them.
Replacing the packages that actually failed
Some of the most practically useful substitutions in his batch replaced exactly the kinds of packages the event’s brief warned about. Ward, from Team Paradox, a developer workflow CLI built with zero npm packages, replaced nodemon, chalk, execa and chokidar with modern Node built-ins: fs.watch, util.styleText and child_process. His review called it a “Polished, comprehensive CLI dev-loop tool.” Chalk is one of the two packages compromised in the September 2025 phishing attack. Node now ships a built-in function for styling terminal text, so a team that knows its runtime can drop that supplier entirely.
Repotool, from Team Apex, did the same for file traversal. His review noted that it “Eliminates heavy glob and traversal packages (globby, fast-glob, rimraf) by implementing recursive directory walking and pattern matching directly with standard library filesystem APIs.” MotionLab, from Control Alt Defeat, went further than most would expect for front-end work, hand-rolling Bézier curve solvers, spring dynamics and timeline sequencing over native Canvas 2D and requestAnimationFrame, which his review said “removes all need for GSAP or Framer Motion.”
Each of these is a small procurement decision. A package that styles text, watches files or walks a directory tree is cheap to adopt and easy to forget. The cost only shows up when the supplier fails, and the September 2025 incident showed how large that cost can be when the supplier is installed billions of times a week.
Production-ready is a specific list
As a mentor, Hayatnagarkar has said his goal as a judge is not only to hand out scores but to give feedback that helps teams keep building after the event ends. His reviews follow through on that by naming the next concrete step rather than leaving teams with a number.
For Repotool: “Adding visited-inode cycle detection to handle circular symlinks and streaming output for large monorepos will make it production-ready.” For hookd, from Ciggzy, a local webhook capture and reverse proxy built strictly on net/http and net: “adding explicit recovery for malformed or interrupted chunked transfers would make it production-ready.” For Cipherops, from Cicada 3301, a cryptographic operations CLI: “Excellent code hygiene with constant-time equality checks and zeroed memory buffers; adding formatted JSON/env export flags will enhance scripting ergonomics.” For Pith, a minimalist static site generator: “Expanding support for nested lists, blockquotes, and a basic built-in local development server will round out its utility.”
This is how a product manager turns a pilot into a platform. A prototype that works on the happy path is a starting point. What turns it into something an organisation can depend on is a short, specific list of the failure cases it does not yet handle: a symlink loop, an interrupted transfer, a missing export format. Naming those cases is more useful to a team than any score, because it tells them where the next week of work should go.
The unit economics of a dependency
Hayatnagarkar’s background gives him an unusual way of reading the zero-dependency question. In freight, a decision to bring a capability in-house is a financial model: the cost of building and running it against the cost and risk of buying it, tested against the data until the projection holds at a stated confidence level. Software teams rarely run that model for a dependency. The purchase price is zero, so the decision feels free.
The Zero Dependency 2026 projects that scored highest in his batch made the other side of the ledger visible. The cost of an unvetted supplier is not the install. It is the exposure every time that supplier changes hands, ships an update or disappears. A standard library is the one supplier every project already has, maintained by the language’s own stewards and versioned with the language. The teams that learned how much it already covers removed suppliers they did not need, and kept their engineering effort for the places where a custom build earned its cost, such as an HTTP/2 stack, a JPEG codec or a write-ahead log.
That is the root-cause lesson he looks for. The cause of most supply chain incidents in software is not one bad package. It is the habit of adding suppliers without counting them. The event asked for 72 hours of discipline in the opposite direction, and the strongest teams showed that the discipline is affordable.
Zero Dependency 2026 was organized by Hackathon Raptors, a Community Interest Company supporting innovation in software development. The event ran for 72 hours from August 28 to 31, 2026, and 295 projects were submitted and judged, each built with an empty dependency manifest using only the standard library of its language. Rushikesh Hayatnagarkar served as a judge evaluating submissions on Functionality & Usefulness, Zero-Dependency Craft, Code Quality & Idiom, and Innovation.
