Founding-partner waitlist is open for small web and design agencies.
Onboarding

Handoff to operation, without losing the client.

Six stages, and at every one it is written down what you supply, what we prepare, and where your approval is required. Founding partners are onboarded personally — this is a conversation, not a signup form.

The three CloudVault guardians guide a project from repository handoff through setup, review, launch, and ongoing operation.
// slot: process-repository-to-operation — one continuous journey, split into two panels on mobile; stage labels are in the page, not the image
The six stages

Every stage names who decides.

Nothing below happens to a client site without your authorization. That is the part most hosting handoffs leave vague, so it is stated at each stage rather than in a footnote.

01

Handoff

You point us at a repository or hand over the production files, along with whatever access exists and whatever you already know is awkward about the build.

Agency provides
Repository or production files, access inventory, known constraints.
CloudVault prepares
A written record of what was received and what is still missing.
Approval required
You confirm what we may access before anything is touched.
02

Assess

We inventory what is actually running: runtime and dependency compatibility, where the data lives, what DNS and mail records really do, and which risks have no clean answer yet.

Agency provides
Context on the client, the deadline, and any commitments already made.
CloudVault prepares
A compatibility and risk inventory — including anything we think is a bad fit.
Approval required
You decide whether to proceed once the risks are written down.
03

Provision

Only the services agreed in the assessment get built: the environment, routing, certificates, data services, and the backup schedule that matches what the client actually needs.

Agency provides
Environment requirements, secrets through a secure channel, sign-off on scope.
CloudVault prepares
The agreed environment, with configuration documented rather than tribal.
Approval required
Scope changes are re-quoted before they are built, not after.
04

Review

You get a preview environment and test it properly, on your own schedule — not just whether it loads, but whether forms submit, mail sends, payments process, and redirects resolve.

Agency provides
Functional validation and any client-facing acceptance you require.
CloudVault prepares
A preview environment and a list of what changed from the source setup.
Approval required
Client-facing approval stays entirely with your agency.
05

Launch

Cutover happens in a window you choose, with the previous environment kept available for a defined period afterwards. How long a DNS change takes to settle is not something anyone can promise away.

Agency provides
Authorization for the cutover window and client communication.
CloudVault prepares
Prepared records, a documented rollback condition, and the old environment kept warm.
Approval required
Nothing goes live without your explicit authorization.
06

Operate

Ongoing work covers exactly the monitoring, backup, and support scope written into the agreement — with the coverage window and escalation limits stated rather than implied.

Agency provides
First-line client support and application-level fixes.
CloudVault prepares
Infrastructure monitoring, patching, and incident reports addressed to you.
Approval required
Restores, resizes, and scope changes are authorized by you each time.

Where the process stops on purpose.

A managed handoff that never pauses is a handoff that is hiding something. These are the conditions that hold the process at a checkpoint until they are resolved — each one is a conversation with you, not a silent failure.

  • Access we were told exists turns out not to work.
  • The runtime or dependency set is not one we can support responsibly.
  • A data migration cannot be tested safely before cutover.
  • A compliance or data-residency requirement has not been resolved.
  • The cutover window has not been authorized in writing.
  • Scope has moved far enough that the original quote no longer holds.
Ownership recap

Who owns what, once it is live.

The same boundary that governs onboarding governs the relationship afterwards. It is a provisional operating model, and a commercial agreement will refine it.

Your agency

// Owns the client and the application

  • Client relationship Owns the commercial and day-to-day client relationship.
  • Application code Owns source, dependencies, build configuration, and application defects.
  • Deployment Supplies a deployable build, a production branch, and release approval.
  • Data and auth Owns schema, migrations, authorization logic, and data correctness.
  • Domains and DNS Confirms domain authority and authorizes cutovers and client-facing timing.
  • Backups and restores Identifies critical data and authorizes restore point, target, and timing.

CloudVault

// Owns the infrastructure layer, invisibly

  • Client relationship Stays behind your agency. Does not market or upsell to your clients.
  • Application code Does not change code without an approved support request and repository authorization.
  • Deployment Provisions and maintains the supported pipeline once it is implemented.
  • Data and auth Maintains the managed database and auth service within confirmed boundaries.
  • Domains and DNS Prepares and validates infrastructure records within approved scope.
  • Backups and restores Runs only the backup services included in the approved plan.

Escalation path: End client → Agency → CloudVault
Exceptions must be explicit, narrow, and documented. A client emergency contact does not become a general support channel, and never becomes a route for us to sell around you.

Start with one site.

Move a single low-stakes client first, watch how it goes, then decide. Anyone pressuring you to move your whole book on day one is selling rather than helping.

// Pre-launch. Founding partners are onboarded personally, one site at a time.