← Nelo / apprenticeship portfolio
Apprenticeship portfolio

A record of what I've actually built

The homelab I run, the AI colleagues that help me run it, the websites I've built, and the small tools that automate my day. Written for school, exams and job applications, in plain language.

Nelojan Nehru IT Apprentice, MTF Solutions AG Switzerland Updated 2026-09-29

Each entry below follows the same shape: the problem I was solving, what I actually built, the tools I used, evidence I can point to, and what I took away from it. The goal is that anyone reading this, technical or not, understands what I did and why it mattered, without needing me in the room to explain it.

What this covers
  • Homelab1 entry written
  • HQ1 entry written
  • Websites1 entry written
  • Automations1 entry written
How each entry is built
  1. ProblemThe real need or gap, described concretely, not "I wanted to build something cool."
  2. What I builtThe actual solution, in plain words a non-technical reader can follow.
  3. TechThe tools and technologies used, named plainly.
  4. ScreenshotReal evidence: a screenshot, or an honest diagram where a live screenshot isn't the right evidence.
  5. What I learnedOne honest, specific takeaway, including things that didn't work first try.
HQ

HQ: a small company of AI colleagues that runs my homelab

Ongoing, 2026
problem

My homelab runs a dozen self-hosted services: files, media, network filtering, a ticketing site, several websites. All of that needs constant, careful attention: monitoring, updates, backups, incident response. I'm one person, with school and an apprenticeship on top, so I can't watch it around the clock, and paying for managed IT support wasn't an option.

what I built

HQ: a small "company" of specialized AI colleagues (built on Claude), each responsible for one slice of the infrastructure, network, storage, security, websites, automation, and so on, the same way a real ops team would split the work. They coordinate through a shared ticket board, so problems get picked up, worked and closed instead of getting lost in one long chat log.

The part I'm most proud of is the guardrails, not the AI itself: a gatekeeper program is the only way any colleague can reach the actual servers, it checks who is allowed to do what, and it takes an automatic backup before anything risky. Planned changes only happen in a quiet overnight window unless something is actually broken, and anything big enough to matter needs my explicit yes or no from my phone before it happens.

tech
Claude (Anthropic)PythonSSH command gatekeeper Proxmox LXCTelegram botNode.js
screenshot
HQ Boy, the handheld-console-styled status app for HQ, showing its login screen and a note that it runs a company with 10 employees
HQ Boy, the companion app I built so I can check on the company from my phone. Login is a one-time code sent over Telegram, so this is genuinely the first thing you see.

"Getting an AI to do IT work was the easy part. The real design problem was deciding what it's never allowed to do on its own, like touching backups or restarting something with people using it, and what always needs my sign-off first. A system like this is only as trustworthy as its rules, not its intelligence."

Homelab

A 3-node Proxmox cluster for self-hosting everything

Ongoing
problem

Cloud hosting for personal projects, files and media adds up in cost over time, and it means handing my data to someone else's servers. I wanted one place to run everything I build and use, self-hosted, properly backed up, and reachable from outside the house without opening ports on my home router (a real security risk if done carelessly).

what I built

Three physical machines clustered together with Proxmox, each one hosting several virtual machines and containers. Every guest gets a predictable IP address based on its own ID, so nothing needs a lookup table to find. One machine is dedicated to backups: it takes a snapshot of every guest every night and keeps a rolling history, so a broken update or a mistake is always recoverable.

Instead of opening ports on my router, every service that needs to be public goes out through its own encrypted tunnel to Cloudflare, so nothing on my home network is directly reachable from the internet. The HQ system described in the entry above runs on top of this and handles most of the day-to-day upkeep.

tech
Proxmox VE 9LXC / KVMProxmox Backup Server Cloudflare Tunnel + DNSPi-holeWireGuardDocker
screenshot
Internet visitor Cloudflare Tunnel pve01 guests pve02 guests (incl. HQ) pve03 guests + backup node Nightly backups every guest, kept 7 days
Architecture diagram (not a product screenshot): three nodes, one of them doubling as the backup target, public traffic arriving only through Cloudflare Tunnels.

"A backup job that runs quietly can also fail quietly. In September 2026 the backup drive's USB connection dropped and nightly backups failed for a full week before anyone noticed, simply because nothing was watching the backups themselves. I now treat a missing backup as an incident the same day it happens, not something to discover a week later."

Websites

Real apps for real people, not just portfolio pieces

2025-2026
problem

Most student project briefs invent a fake client with fake requirements. I wanted practice building for a real, specific need instead: a local business that actually needed working software, and a personal idea I was curious to build end to end myself.

what I built

Warenerfassung ("goods capture") for an Asian grocery store in Schaffhausen: staff scan a barcode and the app looks the product up, enriches it from Open Food Facts when the store doesn't have the data yet, and tracks how complete each product's record is so gaps don't get lost. It also ships as a desktop app (Electron), since a shop counter isn't always a great place for a browser tab.

Connection Room is a smaller, personal project: a real-time room where everyone who joins can see how they're connected to each other as a live graph, built to see how far I could push WebSockets for something that has to feel instant, not just "eventually consistent."

tech
Next.jsTypeScriptReactPostgreSQL PrismaElectronSocket.IOExpress
screenshot
/scanbarcode lookup /productssearch + filter PostgreSQLvia Prisma /dashboardcompleteness, export Electrondesktop wrapper
Structure diagram (not a product screenshot): this runs on a shop's internal network, not a public demo.

"Building for someone else's real workflow is a different discipline than building for myself. The hard part of Warenerfassung wasn't the barcode scanning, it was designing the data-completeness tracking so a busy shop worker could tell at a glance what still needed attention, without reading a manual first."

Automations

Mail Agent: taking repetitive inbox work off my plate

2025-2026
problem

A lot of day-to-day admin, mine and small clients', is the same small set of actions repeated over email: read something, decide what it means, do something about it. Doing that by hand doesn't scale and is easy to let slip.

what I built

Mail Agent: a Python service that watches a mailbox and hands each message to a small set of specialised agents, split cleanly into layers (core logic, integrations with outside services, and the agents themselves), the same "split the work into specialists" idea behind HQ, just smaller and for one job instead of a whole homelab. It runs containerised so it's easy to move between machines without reinstalling anything by hand.

tech
PythonDockerAgent-based architecture
screenshot
Mailboxincoming mail Coreroutes to agents Agent A Agent B Integrations
Architecture diagram (not a product screenshot): this runs unattended in the background, there's no UI to photograph.

"The first version tried to do everything in one script, and every new rule made the whole thing harder to reason about. Splitting it into small agents behind one core, the same lesson HQ taught me at a much bigger scale, made it possible to add a new capability without re-reading everything else first."