The server had been sitting in the corner of the home office for about two months before I did anything with it.
The wind-down was still grinding — creditors, lawyers, suppliers, banks, each moving at their own pace with no regard for mine. But in between calls and emails, I kept finding myself standing in front of that machine. Not staring at it exactly. More like two old colleagues who'd been through something together, neither quite sure what the next chapter looks like.
Same chassis. Same RGB lighting cycling through its colours, completely indifferent to the fact that the company it had powered was gone. The hardware didn't know the difference.
I did. And I had to decide what I actually wanted it to become.
The temptation to just copy-paste
The easy move would have been to carry everything over. The containers were all documented. Spin it back up at home, point the Cloudflare tunnels at the new IP, done in a day.
I nearly did it. Then I looked at what I'd actually be carrying over. Nine months of accumulated services. Containers that had outlived their purpose the moment the office closed. Port numbers that had made sense in November and were confusing by February. A directory structure that had grown organically — which is a polite way of saying it grew without any plan at all.
The staff were gone. The company was gone. Why was I dragging all of their infrastructure into my family home?
So I stopped. And I did something I probably should have done eleven months earlier: I sat down and actually designed the thing before building it.
Designing it properly
One of Claude's more underrated uses isn't writing code or debugging configs. It's thinking. You describe a problem, you push back on each other, and somewhere in the process you arrive at decisions you wouldn't have reached alone.
We looked at homelab forums, self-hosting communities, turnkey platforms promising to do exactly what I wanted. OpenClaw was getting a lot of attention — looked appealing on the surface. The more I read, the less comfortable I felt. Security concerns, oversold features, negative reviews from people who'd actually deployed it. I'd already been through that cycle with AI frontends. I wasn't interested in repeating it.
The conclusion: there was no ready-made solution that did what I wanted. Not because I was doing something exotic, but because what I was building combined things that don't usually go together. Family document management plus password sharing plus AI tools plus a learning environment for a teenager. We drew the map ourselves.
The decisions that mattered
The directory structure got one firm rule: nothing in the root without a reason. Every service, every user, every component gets its place — and if there's nothing in a folder yet, the folder doesn't exist yet.
Port allocation got a proper scheme. The whole home platform lives in the 88xx range, carved into logical blocks — support infrastructure in 880x, app frontends in 881x, MCP servers in 882x, databases in 883x. When you're debugging at 11pm trying to remember which port runs which service, having a scheme you designed yourself is worth more than you'd think.
And then there was Vikunja. I'd been thinking about what it actually meant to build an AI system that could genuinely act on your behalf. For that to work, the AI needs somewhere to put the work. Not just read tasks — own them. Create them, assign them, update them, close them out. Vikunja is a self-hosted task manager — open source, full API, native mobile app. The moment I understood it wasn't just a to-do app but the missing action layer in the agentic model, it stopped feeling like an optional addition.
The spring clean
Before any new build, there was a reckoning with what was already running.
Halfway through the cleanup, I opened the LibreChat config to remove it and ended up reading through what we'd actually built inside it. The Sales Portal. The Workspace Portal. The AutoCount integration. Revenue tracking, inventory analysis, commission calculations, picking list automation — an entire AI-powered operations layer built on top of our accounting software, running silently in a container that nobody was actively using anymore.
I've spent thirty years building things. And in the two months of winding down, I watched all of it get demolished in the way businesses end: not dramatically, just gradually and then completely.
I learned CPR after my mother died so I'd never feel helpless in that moment again. I keep this system for the same reason. The skill exists even when there's no emergency. Someday, if it can help another SME owner — give them the clarity that AI can bring, before it's too late — maybe what I built here means something.
Many containers went. LibreChat stayed. The spring clean was done.
What the home platform became
Eleven containers, each serving a purpose. Document management, password manager, photo library, AI tools accessible from any device in the world. Port ranges documented. Startup chain tested through a real power outage. GitHub repo set up, configs version-controlled, documentation written for a future maintainer who isn't me.
That last part is the important one. Everything I'd built before, I'd built for staff. This was different. I was building for my wife and my son. Building for people who aren't you is a completely different problem. That's what Post 5 is about.
Next: What happens when the people you built something for are too busy to use it.
Top comments (0)