The T-drive started as storage. It became infrastructure. That is the shortest version of the story, but it misses the useful part: the stack grew because every project created a new operational need, and every operational need became a reusable capability.
At first the problem was simple enough: keep projects somewhere I could find them. Then the work expanded into local AI tooling, photography workflows, production websites, VPS services, business experiments, compliance notes, and recovery bundles. A normal folder structure stopped being enough. I needed a working environment that could hold evidence, active code, archived experiments, and the context needed for AI agents to help without starting cold every time.
Where it is now
T-V2 is now a working system with active projects, memory folders, deployed web services, MCP gateways, local automation, photo scanning, recovery scripts, and VPS deployment patterns. It has a living split between active work, archived research, reusable infrastructure, human context, generated assets, and production-facing services.
The VPS at 69.62.122.2 is the public edge. It runs multiple PM2 services, Nginx, live sites, gateway processes, and the project web that proves the system is not theoretical. FocusGoods, LabLocum, Fortress404, Worthington, Dentabam, whytohireme, and the MCP services all sit inside that wider pattern.
The barriers
The hard part was not one technology. It was entropy. Projects multiply. Secrets drift. Live servers get out of sync with local folders. Image assets exist in one place while the public root serves another. A tool count written on a homepage can become wrong overnight because the system keeps growing.
The answer has been to turn drift into process: status documents, deploy runbooks, recovery bundles, gateway manifests, PM2 service names, root paths, and verification commands. The work is not just building; it is making the build findable again tomorrow.
How I built it
I grew it in layers. First came project folders. Then came local scripts. Then MCP tools. Then a VPS with PM2 processes and web roots. Then deployment runbooks. Then recovery bundles designed for USB survival. Then the site you are reading now, which converts the whole stack into something a human can inspect.
That is the pattern I keep using: turn a repeated problem into a tool, turn a tool into a documented system, and turn the system into visible proof.