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 whole story, in one piece
What runs, what it costs and where the limit is — the long-form version of this page.
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.
How this got built
The section above tells you how I work. This one shows the git trail underneath it. Each item is a real task from this site's own build, or from the products the same fleet works on, and most of them end in a specific commit — the hash is shown as proof.
Everything here comes straight from my own working records: git history, the backlog, the role docs. No client names, no numbers I can't defend.
I opened the site on my phone and the product cards were broken. One clipped its own content; another rendered blank with a lone button floating in it. On my laptop everything looked fine. I handed the symptom to an agent, which reproduced the page in a headless browser and showed it wasn't a layout bug at all. The glass cards use a backdrop-filter, and on mobile GPUs that filter kept re-sampling the animated blur behind them, so the card never composited cleanly. The fix drops the blur on touch devices only and keeps the glass on desktop, applied once through a shared hook so it covers every card on the site in a single change. The thing that flagged it was a human on a real phone. The thing that root-caused a GPU repaint quirk in minutes was the agent.
The call-to-action buttons looked washed out and nearly vanished in dark mode. I asked for a styling fix. The agent went a layer deeper and found the real cause: this is a Tailwind v4 project that was missing its @theme mapping, so every semantic colour utility on the site was quietly emitting no CSS at all. The brand blue only survived where someone had hand-written it. That is a far bigger finding than a button, and switching it on would shift colour across every page at once, so I didn't let it ship on autopilot. I looked at it, approved it, and one block brought the AiPOX blue back everywhere. Before it went live it was checked against roughly forty before-and-after screenshots, every page in both languages, light and dark, with the contrast re-measured to stay at WCAG AA.
I wanted the site's SEO to be genuinely good, so I asked a specific question: should the structured data on the English pages be in Dutch or English? The answer came back as advice, not a silent edit. English on /en, because Dutch structured data there doesn't help discovery, with a prioritised list of what else was weak. I read it, agreed, and handed over the profile links. Only then did the work go in: per-locale language tags and JSON-LD, hreflang and canonicals, the verified profiles, a generated sitemap. Doing it carefully surfaced two latent bugs that had nothing to do with the request. A locale left undefined, so /en was silently falling back to Dutch and breaking its own language tags, and a type mismatch breaking the production build. Both fixed in the same pass. That is the rhythm I want on the record: the fleet advises, I decide, then it gets built.
Vincalis is a B2B supply-chain platform I'm building. In one afternoon its codebase took seventeen commits; across the same day sixteen pull requests were opened and fifteen were reviewed and merged. I hand-wrote almost none of it. The work was done by a small fleet, a product owner agent and three developers, and every commit and PR carries their co-author trailer, so the authorship sits in git rather than being something you have to take on faith. The PO agent wasn't only writing code: two of the commits are it running the fleet, lifting a sprint and re-pointing idle developer hosts at the next queue of work. One review pass ran eight separate angles, and three of them landed independently on the same defect: widening one shared type would have let an invalid value slip past validation and crash the database with a 500 instead of returning a clean 400. The agents found it, fixed it, added a regression test, and verified it against a live environment before it merged. The team moved fast. The one thing that waited was my approval.
Proceshuis is one of the products I build with the fleet. In a single morning it moved from its old address to its own brand domain, proceshuis.com, and gained a new feature at the same time — with me steering on direction, not on every step. The move ran in two tracks at once. A developer agent combed the whole codebase for every reference to the old domain, from metadata and SEO to login and mail, on a separate dev environment with typecheck and lint green. In parallel, my sysadmin agent ops-01 handled the DNS, the reverse proxy with a www-to-apex redirect, and the TLS certificate. What the AI did not do on its own was the production deploy and placing a live mail secret: those sit behind a human gate, and I approved them deliberately. That is the pattern I care about most — the fleet knows which steps are irreversible or sensitive and escalates them by itself, even when I say 'go ahead, I can't watch right now.' The same morning a real user question came in: can you filter the process tree by who is responsible for what? It took the same road. First a designer and PO agent mapping the data model and delivering a plan — it could be done entirely on the front end, with no new database query. Then a developer building it. And then the real work: shaping the UX in plain language. 'Takes up too much room' became a filter icon with a popover; 'can it do several at once' became a compact chips combobox. Each round: adjust, look at it live, and only after an independent code review did it reach production. One remark from that morning — 'this isn't a consumer app, it can feel a bit ERP-compact' — the team stored as a standing principle in its memory, so the designer now acts on it by default. The first application rolled out right away: a page header that shrank from 82 to 47 pixels.
Lately the fleet worked through the remaining backlog in a run of sprints, and it went well. The surprise was where the ceiling actually sat. It wasn't the models. It was the infrastructure. The CI pipeline kept getting in the way, and unblocking it turned into a genuine puzzle that no amount of cleverer prompting would solve. In the end it needed hardware: my sysadmin agent, ops-01, called for extra SSDs and different Proxmox settings. Once that landed, the pipeline finally ran clean, and the throughput jumped. The work came out in two separate weekly bursts, roughly one big push a week, each a stack of pull requests and issues closed in a short window. The part I like most is the restraint. The fleet paces itself against a weekly token budget, tracks its own usage, and when it runs ahead of pace it pauses itself rather than burn through the budget. You can watch that happen live in Townhall's token channel. Fast when the plumbing allows it, and disciplined enough to stop itself.
Recently shipped
The latest changes to this site, straight from git. A snapshot taken at build time and refreshed on every deploy.
- fix(theme): dark:-variant volgt de theme-toggle i.p.v. OS540e647
- feat(products): echte product-mockups in de kaarten — theme-aware93cee39
- feat(geo): Product- + FAQ-schema + llms.txt09e0179
- feat(seo): correctheids-batch — lang/JSON-LD per-locale, hreflang, sameAs, sitemap07535ea
- feat(design): semantische kleur-utilities aan via @theme inline331a243
- fix(i18n): contact 'Bel nu' via i18n-key i.p.v. hardcoded NLc0a59c3
Townhall: where the fleet coordinates
All of that back-and-forth runs through Townhall, a small service I built to be the bus the agents talk on. It is an append-only set of channels where the product owner and the developers post status, hand off reviews, and address each other by name, with a web view so I can watch it live instead of digging through logs. The part that matters is the human gate. Anything with real consequences becomes an escalation with an explicit state and lands in front of me as an Approve, Reject or Need-plan decision, rather than a message that scrolls past. That is the one line I draw, made literal: the fleet coordinates itself, and the calls I don't want to delegate stop at me.



The source is public
This whole site is public on GitHub — the exact code you're looking at now. Clone it, read along, or see how it fits together.
Frequently asked questions
What is AiPOX?
AiPOX is Arthur Scheen — a one-person company building modern software that automates manual work, with a directed team of AI agents under his own direction. Not an agency selling hours, but a maker with a product family of his own (Vincalis, SmartDocGen, Proceshuis), built in the open.
Who is Arthur Scheen?
The maker behind AiPOX. Nearly 30 years in horticulture, fresh produce and ERP taught him from the inside where work stalls; he now turns that knowledge into software of his own. Self-taught, building in evenings and weekends, and open about how.
How does 'a team that never sleeps' work?
Arthur sets up AI agents as colleagues — systems administration, development and product ownership — that carry the work around the clock, under his direction. Everything is as-code and traceable in git. One line, drawn by himself: reversible work runs on its own; anything that becomes externally visible or touches his own access, he reviews first.
Which products does AiPOX make?
Vincalis — a supplier collaboration platform, building in public. Proceshuis — process management with risk & control, live at proceshuis.com. SmartDocGen — automatic document generation without programming, live at smartdocgen.app.
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?