For a long time I operated under a quiet assumption: portfolios are for developers. They're for people who build things — apps, tools, open source projects. People who have something to show.
I'm in IT support. I fix things. I troubleshoot. I answer tickets. What was I going to put on a portfolio page — a screenshot of a closed ticket?
So when I started wanting a way to document and showcase my work, I didn't build a portfolio. I built a wiki.
Why I Started Documenting
My homelab had been growing for a while. pfSense for routing, Pi-hole for DNS, a dedicated Docker host, a storage server, Tailscale for remote access. It was becoming real infrastructure — and real infrastructure has a way of becoming mysterious over time.
I'd seen it professionally at Datto too, just from a different angle. In technical support, documentation wasn't about managing someone else's environment — it was about continuity. When a partner called in on an ongoing ticket, good notes meant you knew exactly what had been tried, where things stood, and what to do next. When you hit a wall diagnosing something, you could search past tickets and find a case where someone else had solved the same thing. Documentation wasn't optional — it was the difference between resolving a ticket efficiently and spinning your wheels every time someone called in.
I didn't want that to happen to my own network. So I set up BookStack — a self-hosted, open source wiki — in a Docker container and started writing things down.
The first entries were practical. How the network is laid out. What IP addresses belong to what. How services are connected. The kind of information that feels obvious when you set something up and completely vanishes six months later when something breaks at 11pm and you're staring at a config file wondering what past-you was thinking.
It Grew Into Something More
What started as homelab documentation didn't stay there.
BookStack's structure — shelves containing books, books containing chapters, chapters containing pages — made it easy to expand into other areas. I added a Recipes shelf for cooking. A Subway Knowledge Base shelf for the SOPs and scripts I was writing at work, partly for reference and partly so I had a record of the processes I'd built or improved.
That work shelf in particular felt significant. I was documenting the Autopilot reimaging workflow I'd fixed, the processes I'd written up, the tools I'd built. I was building a record of my own professional contributions — not because anyone asked me to, but because I wanted it to exist.
I also started an Apollo Archives shelf — a growing reference library for certifications and courses I'm working toward, collected and organized for when I'm ready to dig in.
At some point I realized what I was actually doing. I was building a portfolio. I just hadn't called it that.
The Assumption I Had Wrong
Here's what I'd gotten wrong about portfolios: I thought they were about showing off projects. Things you built from scratch. Code you wrote. Apps you deployed.
But a portfolio is really just evidence of how you think and what you've done. It doesn't have to be a GitHub repo. It can be documentation. It can be a write-up of a problem you solved. It can be a structured record of the processes you've improved and the things you've learned.
IT support people build things all the time. We build processes. We build runbooks. We build muscle memory for diagnosing problems that would take other people hours. We just rarely write it down in a way that's visible to anyone else.
The wiki forced me to write it down.
What's in There Now
The nora.local Homelab shelf documents everything about my home network — infrastructure overview, network and DNS configuration, services and containers, backup and recovery procedures, a running change log, and a troubleshooting section for issues I've worked through.
Every Docker container gets a page. Every significant config change gets a change log entry. If I make a decision — why I chose Unbound over a forwarding resolver, why I run ZFS on both servers, why I set up WeTTY instead of direct SSH — I write down the reasoning, not just the steps.
That last part matters more than I expected. Steps tell you what was done. Reasoning tells you why, and why is what you actually need when something breaks or you're deciding whether to change it.
The Unexpected Side Effect
When I eventually decided to build an actual portfolio site — after realizing that yes, IT support people can have portfolios, and yes, I had more to show than I thought — the wiki had already done most of the work.
The project descriptions, the process write-ups, the technical details I needed to articulate my experience clearly — it was all there. Years of documenting my own work, organized and searchable, in my own words.
I didn't have to reconstruct what I'd done. I'd been writing it down the whole time.
If You're in IT and You're Not Documenting
Start.
You don't need BookStack specifically. A Notion workspace, a simple GitHub repo with markdown files, even a folder of well-named text documents — the tool matters less than the habit.
Document what you build. Document what you fix. Document the decisions you make and why you made them. Write it for future-you who will absolutely forget, and write it like someone else might need to understand it someday.
Because they might. And that someone might be a hiring manager.
Are you in IT support and wondering whether a portfolio is even worth building? I'd love to hear where you're at in the comments — this is a conversation I think our corner of the industry needs to have more.
