# How I built my own CLI tools and what I learned from them ## First thought I don’t build tools because I like tools. I build them because I get tired of doing the same thing twice. That’s pretty much where all of this started. When you’re working in terminals all day, setting up environments, jumping between folders, preparing labs, creating virtual environments… You start noticing something. It’s not hard work, it’s repetitive work. And repetitive work is where mistakes live. So instead of accepting that, I started asking a simple question: > *“Why am I doing this manually if I already know exactly how it should look?”* That question turned into code.

## T-labzz — building my “workbench” before working T-labzz came from a very simple frustration: every time I started a lab or an engagement, I had to “prepare the ground” first. Create folders. Organize notes. Set permissions. Structure everything so I don’t end up with chaos later. Think of it like cooking. Before you even turn on the stove, you prepare your ingredients, cut, organize, place everything where it belongs. That process has a name in kitchens: mise *en place*. T-labzz is basically my mise *en place* for CTF's challenges or Pentesting Engagements. Instead of manually preparing everything, I run one command, and my workspace is ready. Clean. Predictable. Structured. If I have to denfine it with a single word, it would be "Efficiency" What I learned from building it wasn’t just Bash, was: > *"Good environments, reduce mental noise."* If your workspace is messy, your thinking becomes messy too. This tool forced me to think about how I work, not just what I do. And until this days, is part of my daily Work-Flow.

## venv-maker — isolating problems like a controlled experiment Python environments are one of those things everyone *knows* they should manage properly… but often don’t. You install something, it breaks something else, dependencies collide, and suddenly nothing works. It’s like mixing different chemicals in the same container and hoping nothing explodes. So I built venv-maker to remove that friction. Instead of thinking: > *“Okay, I need to create a folder, then a virtual environment, then activate it, then install requirements…”* I just think: > *“I need a clean space for this project.”* And the tool does the rest. If I had to explain it simply: A virtual environment is like giving each project its own room.\ No one touches anyone else’s stuff. No conflicts. No chaos. What this tool really taught me is something deeper: > *"Everybody needs privacy, including some tools."* When you isolate systems, environments, or even problems, debugging, becomes easier, thinking becomes clearer, and mistakes become smaller. That mindset applies way beyond Python.

_{(POV: dpkg runs into a dependency conflict against apt.)}

## Info4Ports — fast answers without thinking too much Info4Ports is probably the simplest one, but also one of the most practical. When you’re working with networks, ports are everywhere. And remembering what each one does isn’t hard… until you’re under pressure, or moving fast, or dealing with dozens at once. Instead of opening a browser or relying on memory, I wanted instant answers. So I built a tool that tells me: > *“This port usually means this service.”* Simple. If I had to explain it, like I would to a kid: > *"Ports are like doors in a building.*\ > *Each door usually leads to a specific type of room."* Info4Ports is just someone standing next to you saying: > *“That door? Yeah, that usually goes to the kitchen.”* No guessing. No delays. And the lesson here? > *"Speed matters when thinking."* Even small delays, like searching something you already kind of know, break your flow. This tool removes those interruptions.

(All the roads lead to ~~Rome~~... Efficiency)

## What all of this actually taught me At the beginning, I thought I was just building “small utilities.”, but over time, I realized I was doing something else entirely: I was designing how I think. Each tool solves a tiny problem, but together they shape how I approach work: * I reduce repetition → so I can focus on real problems * I isolate environments → so I don’t deal with unnecessary complexity * I automate structure → so I don’t rely on memory * I remove friction → so I can move faster without breaking things If I had to summarize it in one idea: > *"I don’t like wasting brainpower on things a script can handle."* Because every bit of attention you save can be used somewhere that actually matters, like understanding a system, breaking it, fixing it, or improving it.

## Final thoughts These tools aren’t “big projects.” They’re small, almost boring... But that’s the point. > *"Real efficiency doesn’t come from flashy tools.*\ > *It comes from removing friction in the things you do every single day."* And once you start doing that, you stop thinking like someone who just uses tools… and start thinking like someone who understands them. At that point, going back to being a regular user becomes harder than picking up a new skill or technology in the field. Keep the good work!