Why#
There is a particular kind of professional blindness that comes from spending years advising organisations on IT without doing the technical work yourself. You know what good looks like. You can evaluate an architecture, ask the right questions in a steering committee, identify when a team is overcomplicating something. But you cannot sit down and configure it. The distance between knowing and doing is real, and it is easy to mistake familiarity with competence.
HomeStack was always partly about closing that gap. Not to prove something, but because the gap bothered me. I had spent years in IT advisory — programmes with hundreds of people, strict compliance requirements, enterprise governance — without ever being the person who actually writes the Compose file or debugs the TLS handshake. This project was a deliberate return to the hands.
The question was: how do you track that honestly?
Family#
This one is invisible to the family. They do not see the spreadsheet or the framework. They see whether things work, whether the apps are fast, whether login is easy. The learning infrastructure exists entirely for me.
Though there is something to be said for building in a way that forces you to understand what you are doing. When something breaks at an inconvenient moment — and it will — the person who understands the system can fix it. The person who copied a tutorial cannot.
Tech#
Two frameworks, introduced at the same time.
The first is SFIA — the Skills Framework for the Information Age. An international standard that defines competency levels across IT disciplines, from Linux administration to cryptography to network architecture. HomeStack uses twenty of them. Each skill is defined at three levels: what you can do at L1 (awareness), L2 (working independently), and L3 (full practitioner). The levels above that exist in the framework but are not the target here.
The honest starting point was humbling. Most skills sat at L1 to L1.5. Not because the concepts were unfamiliar — they were not — but because there is a difference between knowing that CrowdSec exists and having configured it, debugged it, and understood why it failed. Version 1.0 of the tracker was written in April 2026 as HomeStack moved from foundation to first services. It was mostly a record of starting points.
Version 2.0 came two weeks later, after several phases of actual building. The numbers moved. Not dramatically, but measurably. Database administration from L1.5 toward L2 after designing a polymorphic schema and debugging a PostgreSQL permissions error. Network architecture toward L2 after coordinating a URL migration across six different configuration locations. Identity and access management after understanding, at the database level, how Authentik actually stores role assignments.
The second framework is Bloom’s Taxonomy. Less formal, more personal. Six levels of learning depth: remembering facts, understanding concepts, applying them in practice, analysing when things go wrong, evaluating design trade-offs, creating something new. At the end of each phase, a short reflection: what did I just remember, understand, apply, analyse, evaluate, create?
The combination works because they measure different things. SFIA measures where you are. Bloom’s measures how deeply you engaged with what you just did. You can complete a phase at Bloom’s L3 — applied the thing, it worked — without really understanding why. The L4 and L5 questions force you to go back and look.
Project#
The Dunning-Kruger check is the most useful part.
Every skill entry in the tracker includes a note about where I might be overestimating myself. Database administration: I designed a fifty-entity schema. But I have not done a restore test. I have not profiled query performance on realistic data volumes. The schema works in Dev with seed data. Whether it holds under real use is not yet known. The tracker says L2.5, not L3, for a reason.
This matters more than it might seem. An IT consultant who advises large organisations knows, professionally, that most failures come not from the hard problems but from the things people assumed were solved. Backup strategies that were never tested. Security configurations that were documented but not verified. Monitoring that was set up but whose alerts nobody checked.
The tracker is a small mechanism for applying that professional knowledge to my own work. For asking, after every phase: what did I say I understood, and what would actually break if I had to rely on it?
The answer is often instructive.