From yes to live
What the first week actually looks like once you say yes — and, honestly, how much of it is your own time rather than ours.
Here's what it costs you
Everything below adds up to one number, and it's smaller than most people expect.
That's the whole handover checklist added up: a typical estimate for a standard move-in, not a promise, and most of it isn't active work so much as sending things you already have. There's a fallback for every line below, so missing one piece of it is not a reason to wait.
See where the minutes go ↓The first week
For most stacks. Anything unusual gets its own timeline, discussed up front rather than discovered halfway through.
- Hour 0You~10 min
Send the brief
Describe what you're running, or what you want built, through the quote form. That's the whole ask to get started.
- Hour 0CustomHostedNothing
Fixed rate comes back
A flat monthly number, in writing, within a business day — no discovery call required to get it.
- Day 1CustomHostedNothing
Stack goes up as code
The agreed shape is provisioned from an infrastructure definition, and a copy of the site or app stands up alongside it for you to check.
- Day 2–3CustomHosted~10 min to confirm the window
Rehearsed cutover, go-live
DNS and TLS switch over on a schedule you set, checked against the standing copy first, with a rollback ready.
- Week 1CodeHerder~5 min to write the brief
First briefed change ships
Brief a small change in plain language; an agent opens a pull request and CI ships it once it's reviewed. Anything larger goes to CustomLabs instead of through the loop.
- OngoingCustomHostedNothing
Monitoring, backups, patching
Running quietly from here on, with a named human if anything ever needs a decision from you.
What we need from you
Every line has a fallback — nothing here is a hard blocker to getting started.
Repo access (read-only)
5 minWhy So the stack gets provisioned against the real code, not a re-created copy of it.
If you can'tDon't have a repository yet? Send a zip or export and it goes into version control for you.
DNS access, or a delegation
10 minWhy To point the domain at the new stack on the day of cutover.
If you can'tCan't get into the DNS panel? We handle the delegation directly with the registrar instead.
Current environment variables and secrets
10 minWhy API keys, database URLs, and anything else the app reads at startup need to move with it.
If you can'tLost track of a value? We help you regenerate it from wherever it gets used.
A database export, if there is one
15 minWhy Data moves once, deliberately, rather than being pulled live off a connection nobody wants left open.
If you can'tNo export handy? Given read access, we can pull one from your current host ourselves.
A short description of the workload
10 minWhy What it does, and roughly how much traffic it sees, is what the sizing and the quote are based on.
If you can'tNot sure how to put it in words? Answer the selector's questions instead — same information, no writing.
Sign-off on the go-live window
5 minWhy The DNS/TLS cutover happens on a schedule you choose, not one picked for you.
If you can'tNo strong preference? We propose a low-traffic window and confirm it before touching anything.
What you don't have to do
Not covered above because it isn't yours to carry in the first place.
- No console to learn — nothing to click through before you can even ask a question.
- No CI pipeline to write. The one already running here ships every merge.
- No on-call rota. A named human carries that instead of you.
- No ticket queue — the quote form is the one channel, in both directions.
- No per-request bill to model. One flat number, agreed before anything starts.
- No renewal to remember: TLS, patching, and backups just keep happening on their own.
What you have on day one
Live before you've had to ask for any of it.
A spec-sheet permalink
The exact configuration, line by line, at a link you can hand to anyone on your team.
Deploys from git
Push to the branch that's wired up and it ships — no separate deploy step to remember.
A status page
Live system status, there before you'd ever need to go looking for it.
Backups already running
Nightly, from day one — not something you have to go and schedule yourself.
A named human
Someone from the team that provisioned the stack, reachable through the same form.
The export clause, in writing
How to take everything with you, spelled out before you've ever needed it.
Where each of the three fits
One team, three jobs — brought together at the moment onboarding actually needs them.
CustomLabs
Builds it, or finishes itYou've got a half-built app, a prototype, or nothing written down yet — CustomLabs designs and builds the first version.
customlabs.io ↗CustomHosted
Runs itWhatever exists — built by CustomLabs or brought in from anywhere else — this is what keeps it live, patched, and backed up.
About →CodeHerder
Iterates on itOnce it's live, small changes skip the backlog: brief it, an agent opens a pull request, and it ships as a $25/mo add-on.
The Loop →
Onboarding questions
The follow-ups that come up once someone's actually about to say yes.
01How long does onboarding actually take?
For a typical move-in, well under an hour of your own time spread across the first week — the handover checklist above is exactly where those minutes go, and it sums to the number at the top of this page. The stack itself is usually live within days of the brief, not weeks.
02What if I don't have the code, or it's unfinished?
That's a CustomLabs job, not a blocker. Bring a half-built prototype, a rough idea, or nothing written down yet, and CustomLabs designs and builds the first version; CustomHosted takes it from there.
03Will there be downtime during the cutover?
The cutover is rehearsed against a standing copy first, and DNS/TLS switch over on a schedule you set — most moves see little-to-no visible downtime, with a rollback ready if anything looks wrong.
04Can CustomLabs finish something half-built as part of this?
Yes. If onboarding turns up gaps — a missing feature, a rough edge that needs real design work — CustomLabs can close them as part of the same handoff, rather than you finding a second vendor.
05Can I brief a change while onboarding is still happening?
Once the first copy of the stack is up as code, typically by day 1, it's already a fit for a CodeHerder brief. Most people wait for go-live, but there's no rule against sending one earlier.
06What happens if the cutover goes wrong?
A rollback is ready before the cutover starts, on a schedule you approved. If something still looks off, a human replies within a business day — the same response time promised everywhere else on this site. The minutes and the timeline here are typical estimates for a standard move-in, not a contractual guarantee; the binding availability commitment lives in the SLA.
What onboarding connects to
- Migrations
Already hosted elsewhere? The cutover mechanics behind Day 2–3 above, in full.
- The Loop
The Week 1 row above, in full — brief a change, an agent opens a pull request, CI ships it.
- Brief a change
What "send the brief" on Hour 0 above actually means, in detail — what to say, and a composer to help say it.
- Domains
The DNS/TLS switch inside Day 2–3 above, in full — the record sheet, why mail records never move, and the propagation window.
- Pricing
The rate card behind the fixed number that comes back on Hour 0.
- Support
How things work once onboarding is done and you're just running.
- Access
What the repo, DNS, and secrets access handed over on Hour 0 actually grants — the full matrix.
Ready to start the clock?
Tell us what you're running — one fixed monthly rate, within a business day.