Kyro VPN: a privacy prototype I started, parked, and learned a lot from

Kyro VPN is the most over-scoped project on my GitHub. I want to talk about it honestly because I think the lesson is more valuable than the code.

The idea: a privacy-focused VPN with a coordinator service, a client across desktop and mobile, a dashboard for status, an infra layer, and node daemons. Multiple languages because each piece sat at a different layer — Go for the coordinator, Dart for mobile, Swift/Kotlin for platform clients, TypeScript for the dashboard, C++ at the network layer.

If that list sounds like a lot, that's the lesson. It is a lot. It is too much for one student.

What I'm proud of

Even though Kyro VPN is a prototype and clearly labeled as such, two things came out of it that I'm proud of:

1. An architecture document I actually finished. Before I wrote a line of code I wrote ARCHITECTURE.md, API.md, FRONTEND.md, and SETUP.md. They describe what the system would be. They're honest about what's prototype vs what's planned. That document was harder than any code I wrote.
2. A repo structure that mirrors the architecture. client/, coordinator/, dashboard/, infra/, node-daemon/. Even though most of those directories don't have a full implementation yet, the shape of the system is browsable. That makes it useful as a reading exercise even when it isn't runnable.

What I'm going to fix in the README

The current README is too thin. It doesn't make the prototype status loud enough. Someone landing on the repo might think this is a usable VPN. It is not. Here's what I'm going to add (probably before this blog post goes live, honestly):

• A big "PROTOTYPE — DO NOT USE" banner at the top.
• A status table for each subdirectory: prototype, design only, runnable, etc.
• A "security note" section that lists every thing this would need before being trustworthy: independent audit, reproducible builds, signed releases, threat model document.

Security projects need to be louder about their status than other projects. A buggy todo app annoys users. A buggy VPN gets people hurt.

What I learned about scope

I picked Kyro VPN as a project because I wanted to learn distributed systems. That's a legitimate goal. The mistake was trying to learn it across six languages at once. The right version of this learning project would have been: pick one language, build one small piece (say, a coordinator that tracks node liveness), and ship that.

I asked Claude after I'd already started "is this too much?" and Claude said yes. I respect that the AI was honest. I should have asked it before I started.

What I'd do as v0.1

If I revive this, the first runnable version is:

1. A Go coordinator with one endpoint: POST /heartbeat.
2. A Go node daemon that sends heartbeats every 10 seconds.
3. A tiny dashboard that shows which nodes are alive.
4. No VPN tunneling whatsoever.

That's a week of work and it's a real distributed system. From there, layering on tunneling is a separate, focused project.

What AI helped with

• Threat modeling vocabulary. I didn't know what STRIDE or DFDs were when I started. Claude walked me through them and now I have shorthand for thinking about security risk.
• Architecture diagram drafts. I'd describe what I wanted and ask for a Mermaid diagram. Mermaid is great for this. AI is great at producing valid Mermaid syntax from English.
• Cross-language patterns. Some patterns translate between Go and Rust (channels, ownership) and some don't. AI was helpful for "explain how this Rust idiom maps to Go" type questions.

The honest portfolio framing

I left Kyro VPN on my portfolio with a "Prototype" status badge instead of hiding it because I think it's important for student portfolios to show what didn't ship as well as what did. Hiding parked work is a kind of dishonesty.

If you're a student considering a security project: pick a smaller scope than you think. Then halve it. Then you can start.