One face at the front. A system behind it.

In July 2026 I built a Telegram gateway called Hermes Next. Start to live in about a day. It wrapped an agent framework I already had, roughly ten thousand lines, and it became the transport for the whole system: every message in, every task out, all of it flowing through Hermes.

I killed it nine hours later.

The reason was boring. The old transport, the one Hermes was meant to replace, was simply sitting in a better place in the stack. It had years of small fixes baked into it that I had forgotten were even there, until the things I relied on quietly stopped working. Hermes was newer and cleaner and wrong for the job. Clean code in the wrong slot is still the wrong code.

What I want to remember is how fast I let go. Not fast because I am disciplined. Fast because I had already learned the expensive version of this lesson: the cost of a build is not the hours you spent, it is the hours you keep spending to defend it. I have shipped things I was proud of and then dragged them around for months, because ripping them out felt like admitting the first build was a mistake. It was. Admitting it on day one is cheap. Admitting it in month four is not.

Three ideas from Hermes survived the rollback. A transport journal, so every message has a paper trail I can replay when something looks wrong. Task dedupe, because the same request used to arrive twice and get done twice. And an idempotency queue, so a retry can never fire an action a second time. I folded all three back into the old transport that same afternoon. The old transport is now better than it was before I built Hermes, which is the only good argument for having built it at all.

One day of work, nine hours of life, zero regret. If you hire me, you are not paying for code that survives no matter what. You are paying for someone who will throw out his own good work the moment it stops being the right work, and keep the three parts that were worth keeping.

People ask which AI I use like there is one answer. There is not. I run different models for different jobs, the same way you would not put one person on legal, sales and the coffee run.

A big, expensive model does the thinking. It plans the work, decides what happens in what order, and judges whether the result is any good. I pay for that judgment and I pay a lot, because judgment is the part that is hard to fake. Underneath it, cheaper and faster models do the mechanical passes: reformatting, extracting, the hundred small chores that do not need a genius, just someone quick who does not get bored.

Then the builders run in parallel. Several at once, each with one job, none of them waiting on the others. Here is the part most people skip. A separate reviewer model tries to tear their work apart before any of it ships. Not a rubber stamp. A different model, with different instructions, whose entire job is to find what is broken, what is ugly, what breaks a rule. If the reviewer finds something, the work goes back. Nothing reaches a human on a lucky streak.

This site was built exactly that way. One orchestrator holding the plan. Fleets of builder agents writing pages, reviewer agents checking them, every page screenshotted and read by a machine before I ever looked at it. By the time a page reached me, it had already survived a critic that does not get tired and has no ego about its own work.

The honest catch is that models change under you. The one that was best in spring is second best by summer, and a setup that worked last month starts making quiet mistakes. So the whole thing is not a monument. It is something I re-tune constantly. I do not marry a model. I hire it for a job, watch it, and swap it the week something better shows up. You are not buying my favourite tool. You are buying the judgment about which tool goes where, and that part stays mine.

Every mistake I make becomes a gate. That is the whole system, and it took me an embarrassingly long time to build the obvious version of it.

A gate is a check that runs before anything ships. It is small and stupid and specific. Did a link 404. Did a heading wrap to three lines and look broken. Did someone reach for a colour that is not in the brand. Did an em dash sneak in, which on this system is banned outright, so a single one stops the whole deploy cold. Each gate started as a real thing that went out wrong once, embarrassed me, and got turned into a rule so it can never go out wrong the same way again.

I started with a handful. Today there are 140 of them, and the number goes up most weeks. That direction is the point. A checklist you write once and forget rots, because the mistakes move and the list does not. A checklist that grows every time something slips gets harder to fool the longer it runs. The version I have now catches things the version from three months ago would have waved straight through.

The part clients tend to like: the gates are shared. When one client's project teaches the system a new failure, that gate goes live for everyone. So the ninth company through the door inherits every lesson the first eight paid for, without paying for them again. Their work ships against a checklist that eight real projects made stricter before they arrived.

I will be honest about the limit. Gates catch the mistakes you can describe. They are useless against the ones you cannot see yet, the taste calls, the moment where something is technically correct and still wrong for the client. That part stays human and always will. What the gates buy me is a clear head. I do not spend attention on whether a link works or a token is right, because a machine already checked. I spend it on the handful of decisions that actually need me. That is the trade, and it is a good one.

The question I get most is how one person runs thirty client projects without the whole thing falling over. Fair question. Here is the actual shape of it.

The system carries the repeatable eighty percent. Builds, checks, deploys, the overnight monitoring, the weekly reports. None of that needs me awake for it to happen, and most of it happens while I am asleep in Bangkok and the client is asleep in Brussels. I carry the other twenty. Taste, approvals, the judgment calls, and the relationships, which is the part that does not scale and is not supposed to.

My morning does not start with status meetings. It starts with exceptions. The system has already done the routine work overnight and left me a short list of the things that need a human: this deploy failed, this client asked for something new, this number moved in a way worth a look. I read the exceptions over coffee and spend the day on those. On a normal day the list is short. On a bad day it is not, and that is exactly when having the routine work already handled is worth the most.

The honest limit is onboarding. I take on two new installs a month, no more, and I turn work away to hold that line. It looks like leaving money on the table, and it sort of is. But the twenty percent that stays human is the whole product. If I onboard six clients in a month, I do all thirty-six projects badly, and the thing people actually pay for, the sense that one person is genuinely on the hook for their business, quietly dies. Two a month means every install gets the real version of me, not a thinner copy.

People hear thirty projects and picture chaos, or picture a guy drowning. It is neither. It is boring in the good way. The machine does the boring work so I can do the work that is not boring, and the calendar has room in it because I built it that way. That is not hustle. It is closer to the opposite.