- 01Sites don't fail at launch — they fail six months later, when there's no developer with spare time to open a two-line pull request.
- 02The Build → Iterate → Run loop is one continuous team: CustomLabs builds it, CodeHerder iterates on it, CustomHosted keeps it running.
- 03A change ships as a plain-language brief, an agent-opened pull request against the real repo, the usual build/lint/test checks, human review, then merge.
- 04The loop is for the steady stream of small changes — a large redesign or new infrastructure still belongs in a proper build.
Sites rot after launch, not before
Launch day is rarely the problem. The problem is month six: a price needs updating, a section is out of date, a small feature would help, and there's no developer with spare time to open a two-line pull request. So it doesn't get opened, and the site slowly falls behind the business it's supposed to represent.
The usual fixes are hiring a part-time developer for occasional work, or saving up small changes for an infrequent, expensive contractor engagement. Both work. Neither is fast, and both cost more per change than the change is worth.
One team, three jobs
There's a third way, and it comes from how the site is hosted rather than who wrote it originally. Three roles, one continuous loop:
- Build — CustomLabs
- The consultancy that designs and builds the first version of the site or app.
- Iterate — CodeHerder
- An agentic pipeline that keeps making small changes after launch — briefed in plain language, not filed as a ticket and left waiting.
- Run — CustomHosted
- The hosting arm that keeps the result live, patched, backed up, and monitored.
It works because the site is already hosted here and already defined as code, so the agent doing the iterating is working against the real, running thing — not a stale export someone has to reconstruct before work can even start.
How a change actually ships
- Brief it in plain language — a copy fix, a new section, a small feature. No ticket template required.
- An agent opens a pull request — a real diff against the site's own repo, following the patterns already in it.
- The usual checks run — build, lint, and tests, automatically, same as any other change.
- A person reviews and approves it — or sends it back with notes. Nothing merges unseen.
- Merging ships it — through the same pipeline already serving the site. Live in minutes, not a release cycle later.
What's still worth a human decision
This loop is for iteration, not for deciding what to build in the first place. A large redesign, new infrastructure, or anything that hinges on a real product decision still belongs in a proper build. What it removes is the wait between "we should change that" and it actually being live — for the steady stream of small changes every site accumulates.
The full write-up, including what you can and can't brief this way, is on theloop page. The build and the pipeline are run byCustomLabs andCodeHerder respectively — bring your own site, or have CustomLabs build the first version and stay on the loop from day one.
If this is describing a site whose developer has already moved on, keep it moving without a developer walks through what that looks like day to day.