How I build
How I build
I run AiPOX on my own, but not alone. The work is carried by a directed fleet of AI colleagues, under my direction. This page explains how that works. Not as a sales pitch, but because I think you should be able to see how something is built before you trust it.
Open about the way I work
The way I build is the most distinctive thing AiPOX has, so I don't keep it hidden. I'm happy to share how I approach things, free of charge, so someone else doesn't have to spend the same months of searching it cost me. This is a small start; the page grows with what I learn along the way.
The work: a directed fleet
It started with a single agent that helped me with infrastructure-as-code for a few servers. Today there's a whole crew, each with its own job, coordinating through a channel of their own.
A tiered guard keeps an eye on the platform day and night: Proxmox, firewall, network, backups. It knows the difference between noise and an incident, so no one stares at a dashboard. I get a message when it genuinely matters and can respond straight from my phone.
Developers work on features independently, each in their own environment. The dull, repetitive, error-prone work that never used to get finished now simply keeps going. Everything is as-code and traceable in git, not in my head.
A product owner guards priorities and thinks along about direction. What's left for me is the work that matters: deciding where time and money go, and calling the shot at the right moments.
The interesting part isn't that I let go, but how. Anything internal and reversible, a new VM, a firewall rule, a DNS record, has standing approval; no one has to ask. Anything that becomes visible to the outside world or is hard to undo, like a production cutover or a change that touches my own access, I review first. Not out of distrust, but because I know where the pain is when something goes wrong.
What's actually there
No client logos, no numbers I can't back up. But this:
The page you're reading was built in exactly this way, task by task, by the same crew. What you see is the proof itself.
Infrastructure, deploys and changes are fixed in git. Every step can be read back in the commit history, rather than in my memory. That makes 'traceable' a property, not a promise.
This doesn't run in a demo. At home there's a server with 14 cores and 128 GB of ECC memory, running around fifteen containers and VMs, with a UniFi network and an OPNsense firewall. That's where I learn the most, and where I test everything before it goes anywhere else.
I don't pretend the agents can do everything. They don't set direction, and sometimes something goes wrong. That's exactly why that one line exists and why I look over things myself at the moments that matter. Being honest about what's finished and what's still being built stays the starting point.
Outcome over buzzwords
This isn't about being 'AI-powered'; it's about work that happens reliably and frees up time for the things that matter. Want to see what that produces?