Ship, then keep shipping
CustomLabs builds the first version. CustomHosted runs it. And because it's already hosted here and defined as code, CodeHerder's agents can iterate on it directly — brief a change in plain language, an agent opens a pull request, the same pipeline ships the merge.
One team, three jobs
Build, iterate, run — each with its own name, none of them a handoff that loses context.
- 01Build
CustomLabs
Design and build the first version with the consultancy that also runs it. One team, brief to production — nothing lost in a handoff to a separate agency or a separate ops team.
customlabs.io ↗ - 02Iterate
CodeHerder
Agentic, automated iteration on the code that's already live with us. Brief a change, an agent implements it on a branch and opens a pull request, CI ships the merge once it's reviewed. Human-reviewed, versioned, repeatable.
codeherder.com ↗ - 03Run
CustomHosted
Every stack is defined as code and deploys straight from the repo, so the loop closes on the same pipeline we monitor, back up, and patch. Merge, and it's live.
That's us
A change, end to end
Six steps from a plain-language brief to a live deploy — the same review and history as a change your own team would make.
- 1
Brief the change
Describe what you want, in plain language — a copy fix, a new section, a config change. No ticket template, no backlog grooming.
- 2
Agent reads the live codebase
Because the site is already hosted with us and defined as code, CodeHerder's agent works against the real thing — not a stale export or a re-created mirror.
- 3
Branch and implement
The agent makes the change on its own branch, following the patterns already in your repo — same components, same tokens, same conventions.
- 4
Pull request opens
A normal PR lands against your default branch: a real diff, a description of what changed and why, nothing hidden behind a proprietary interface.
- 5
CI and human review
Build, lint, and tests run automatically. A person reviews the diff and approves it — or sends it back with notes, same as any other change.
- 6
Merge ships it
Merging the PR deploys through the exact pipeline that's already serving your site — the one we monitor, back up, and patch. Live in minutes, not a release cycle later.
Why it's faster here
Agentic iteration works best on infrastructure it can already see. That's what being hosted with us gives it.
Already hosted, already code
The agent iterates on the real, running infrastructure definition — no export step, no rebuilding a throwaway environment before work can start.
Human-reviewed & versioned
Every change is a pull request with a diff and a history. Nothing merges unseen, and nothing ships without someone's approval.
One pipeline, not two
Agentic changes ship through the same deploy path as everything else we run for you — no separate "AI hosting" environment to keep in sync with production.
No environment drift
Staging and production are the same infrastructure definition, so what an agent tests against is exactly what goes live.
What you can brief
"Agentic iteration" made concrete — the kinds of changes that suit a brief and a pull request rather than a project kickoff.
Copy tweak
Reword a section, fix a typo, update a price or a claim.
New page or section
A landing page, an FAQ block, a new entry in the nav.
Config change
A redirect, a security header, an environment variable.
The full redirect and header rule set →Dependency bump
A version upgrade, or a security patch to a library you rely on.
Small feature
A form field, a filter, a widget that doesn't need a design sprint.
Integration
Wire up a service you already use — no new environment to provision first.
Loop questions
The questions this page raises on its own. General hosting questions live on the homepage.
01Do agents push to production directly?
No. Every change lands on its own branch and opens a pull request. Nothing reaches production without passing CI and a human approval, exactly like a change from your own team would.
02Who reviews the changes?
Whoever normally reviews pull requests for the project — you, your team, or CustomLabs acting as caretaker. The loop doesn't remove review, it just removes the wait for someone to have time to write the diff.
03What can't be briefed this way?
Large redesigns, new infrastructure, or anything that needs a real product decision still belong in a proper build with CustomLabs. The loop is for iteration on something that already exists, not for deciding what to build first.
04Do I have to have used CustomLabs to use the loop?
No. The loop works on any codebase already hosted with CustomHosted. It's a natural fit if CustomLabs built the first version, but it's not a requirement — bring your own repo.
Keep exploring
- Brief a change
What "brief the change" from step one above actually looks like — the five parts, and a composer that assembles one.
- Environments
The "no environment drift" claim below, in full — what staging actually is, and how a change gets promoted to production.
- Who it's for
The loop, applied to your specific situation — agency, founder, or no dev team.
- Built in the open
The loop, run on ourselves — the real pull-request ledger behind this site.
- Case files
Three ledger rows, followed end to end — the brief, the review, and the real diff stats behind each.
- Platform
How the edge network, storage, and dedicated compute fit together.
- Pricing
The full rate card — flat, predictable, and posted in the open.
- About
The consultancy and the hosting arm, and how the two work together.
- Support
How we back up, patch, and answer when something needs a decision.
- Access
The full answer to "do agents push to production directly?" — the matrix, not just the FAQ.
- Delivery
The "config change" row above, in full — every URL rule, the cache, and the response headers.
Ready to start?
Tell us what you're running — one fixed monthly rate, within a business day.