Value Stacking with Open Source Projects
It was 2016. Tenable purchased FlawCheck, a container scanning solution built primarily around Docker containers. I was a Sales Engineer at the time and hadn’t heard of Docker or containers until the acquisition was announced.
I hadn’t been at Tenable long — just over a year — and I was only starting to really learn Python and expand my hacking skills. I had deliberately chased Tenable, “the creators of Nessus,” for a role, because I’d used and admired Nessus for years.
As an avid reader — still today, and back then too — I came across a term that stuck with me: value stacking. I became obsessed with the concept, and I want to share that obsession with you.
What value stacking is
Value stacking is the practice of choosing a single effort that pays off in more than one direction at once. Instead of treating your goals as a to-do list of independent items — each one a separate slog — you look for the project that sits at the intersection of several of them. One unit of work, several returns. The goals stop being a list and become a lattice: connectable enclaves rather than isolated islands.
Most people plan their growth the way you’d write a grocery list — learn Docker, get better at Python, become a stronger presenter, each item chased on its own. Value stacking flips that. You draw the lines between the goals first, then find the single project that touches as many of them as possible.
Drawing the lines
Similar to a mind map, I wrote down my goals and drew connective lines between them, then wrapped a single project around a cluster that looked separate on paper:
- Become a legitimate hacker — able to write my own exploits
- Understand Docker and the security scanning of containers
- Understand web application scanning: the nuances of detection, scanning web apps, and fixing the flaws
- Become a better writer and presenter
- Become a technical evangelist
On a list, those look like five unrelated pursuits. Drawn as a map, they wanted to be one thing.
The first stack: What’s on my network?
I built a small project I called What’s on my network?
It pulled data down from Tenable’s APIs and organized it in a SQLite database. Then I wired up a Flask API on top of that database so I could see which assets were on my small network, using Nessus scan details. Finally, the whole thing was wrapped in a Docker container for deployment.
Now look at what one project gave me:
- A workload I could scan with Tenable’s container scanning solution — learning FlawCheck’s value the way a customer would.
- A live web app I could throw SQL injection and other web-app hacking techniques at — my exploit-writing sandbox.
- A real reason to learn the inner workings of Docker, because I had to actually ship the thing.
- A target for Tenable’s web application scanning, so I could find bugs and then resolve them like a customer running in production.
- Something worth writing and speaking about, which fed the evangelist goal.
The amount of problems, failures, and iterations I ran into securing that stack is exactly what cemented my understanding of the entire tech stack. You don’t learn Docker by reading about Docker. You learn it when your own container won’t build at 11pm and the goal you actually care about is on the other side of fixing it.
Get Casey Reid’s stories in your inbox
Join Medium for free to get updates from this writer.
That project became navi — an open-source CLI that’s now crossed 336K+ downloads and seven years of history. But navi was never the point. The stack was the point. And a good stack keeps compounding.
The stack didn’t stop — it just got a new top layer
Fast-forward to today. My goals changed. The thing I most wanted to become an expert in was AI — agents, tool use, the security exposure that comes with all of it. And I asked myself the same question I asked in 2016: what single project sits at the intersection of everything I’m trying to learn?
The answer wasn’t to start over. It was to stack on top of what already existed. navi was already seven years of accumulated value. The fastest way to become fluent in agentic AI wasn’t to abandon that — it was to add another enclave to the stack.
navi-mcp was the first new layer. I wrapped navi’s 150+ exposure-management primitives in a Model Context Protocol server, so an LLM agent could call them safely. That one project forced me to learn MCP architecture, tool-invocation design, and — because you do not let an agent run remote code or delete tags casually — a real write-gate model (NAVI_MCP_ALLOW_WRITES=1 plus a per-action confirm=True, with separate gates for remote execution and email). I wasn't studying agentic AI in the abstract. I was hitting its design constraints daily: guardrails, prompt injection, tool safety, the blast radius of an autonomous action.
navi Claude Skills was the next layer. I took a single 2,800-line monolith and split it into domain skills so an agent could load exactly the context a task needed and nothing more. That taught me context engineering — how you actually shape what a model knows at the moment it acts — which is one of the least-understood and most valuable skills in AI right now.
And The Hounds is the layer sitting on top of all of it: an agentic exposure-management platform built on navi, navi-mcp, the Skills, and Tenable plugin data — a named pack of autonomous agents, each with its own detection logic. It only exists because every layer beneath it already did. I didn’t build The Hounds. I built navi, then I stacked.
Why open source is the right container for a stack
Here’s the part I want you to take away.
Every one of those layers is public. That isn’t charity — it’s the mechanism. Open source is what turns a personal learning project into a stack that keeps paying off:
- It forces the work to be real. A private script can be 80% done forever. A public repo has users, issues, and a README you have to defend.
- It compounds reputationally. The writing, the talks, the evangelism goal from 2016 — those feed off the code being public. You can’t give a talk about a project nobody can see.
- It makes the next layer possible. navi-mcp only exists because navi was already there and already understood. Each public layer becomes the foundation the next one stacks on.
- It connects you to other people’s stacks. This is the enclave part. When your project is open, someone else’s goals can connect to yours. Their fork, their integration, their MCP client — your enclave links to theirs, and the value stops being something you own alone.
The proof is in what the stack let me say
The clearest sign a stack is working isn’t the code — it’s what the code lets you do everywhere else.
Because navi kept giving me new ground to explore, I’ve now written 33+ articles on the concepts it surfaced — real, hands-on pieces educating customers on the gold buried in Tenable’s plugins. That’s not content for content’s sake. Every article started as something navi let me actually do, then fix, then explain. The writing-and-evangelism goal I wrote down in 2016 didn’t get chased separately — it fell out of the stack. The projects generated the material.
And it reaches further than I expected. When I spoke at Gartner, I could stand up and validate their research from real AI experience — from having actually built the agents, the MCP server, and the guardrails I was talking about. Most speakers on that stage are relaying someone else’s findings. I was confirming published research against a system I’d built with my own hands. That’s not a credential you can buy or borrow. It’s what a value stack earns you: you don’t just know about the thing, you’ve shipped it, so when the industry’s biggest analyst firm makes a claim, you’re one of the few people in the room who can say “yes — and here’s what that actually looks like in production.”
That is the compounding return. The stack doesn’t just make you better at the things on your list. It puts you in rooms, on stages, and in print — with something real to say.
Stop writing lists. Start drawing maps.
If you’re planning your growth as a list of independent goals, you’re leaving the best returns on the table. Write the goals down — then draw the lines between them. Find the one project that touches four or five at once. Make it open. Ship it.
Then, when your goals change — and they will — don’t start over. Add a layer. That’s the whole trick. In 2016 I wanted to learn Docker and web app hacking. In 2026 I want to be an expert in AI. It’s the same stack. I just kept building up.
Think of your goals as connectable enclaves, not independent islands. Then go find the project that connects them.
