Why this page exists
The question behind this page is why hire me when the same model is a browser tab away. The answer is everything around the model: a crew of specialist agents, a dispatch layer that decides which of them picks up a job, a library of written procedures, a judgement layer that carries decisions between sessions, a state file per project, and a gate that blocks "done" until there is proof. The sections below take them one at a time.
The crew
I run seven specialist agents, each with a narrow scope and pinned to the cheapest model that does the job well:
- Architect, design decisions only.
- Backend and frontend, the builders.
- Design, UX and visual work.
- Growth, marketing and copy.
- Reviewer, read-only, checks a diff for security problems before it ships.
- Explore, read-only, searches a codebase without touching it.
A dispatch layer decides who picks up a task. Trivial work stays with me. Standard work goes to the right specialist without a conversation. Anything complex stops and asks before it spawns a crew, so nothing expensive runs on a guess.
The skills
Around 25 reusable skills sit behind the crew. Each one is a written procedure for a specific kind of work, so the same job gets done the same way every time it comes up. The one that carries the most weight is a six-skill design suite that runs in a fixed order on any interface work: psychology first, so the hierarchy is settled before anything gets drawn, then a teardown of comparable products, then established interaction patterns, then a benchmark for anything that takes more than one step, then a check of every screen's empty, loading, partial, error and ideal states while it is being built, then a critique pass before it ships. The order matters. If the layout goes first, the page ends up decorated and the hierarchy gets patched afterwards.
The brain
A model starts every session with no memory of the last one, so the judgement lives in files. Three of them: scoring anchors for judging copy and design, a risk register for anything that could hurt a live system, and a ledger of rulings, so a question settled once stays settled. Before an agent scores anything, or touches a system that could break, it reads the relevant file first.
Per-project memory
Every project keeps its own state file: what is built, what is next, what is broken, kept current automatically as the work happens. A new session on any project reads that file and starts, with no re-reading of the codebase and no re-explaining from me.
The quality gate
Nothing gets marked complete without the output of a real test run in the report. An agent that says "done" without it gets sent back. Work that touches money, personal data or authentication gets a second, read-only review pass before it ships.
The proof
The clearest evidence I have came out of Flightdeck, the control room I built for running this crew. I ran four agents in parallel in one checkout, each scoped to strict file ownership, and they finished with zero collisions.
Two of them made the right call without being told to. One checked whether a fix already existed before writing a new one, found that it did, and reported that instead of duplicating the work. The other refused a task outright: it had been asked to implement a completion metric that would have counted lost work as done, and it said so instead of shipping the number anyway.
That refusal is the part I point to. I asked for the wrong thing and the system said no, with reasons, before the wrong number shipped.
Why this is what you're hiring
What you are hiring is the system around the model. Routing, guardrails, review gates and memory are what make a model's output safe to rely on at the volume a real business needs, and the setup described on this page is the one I bring to your build.
