Six situations you have already been in.
Every agency hits these. Below is what each one costs you now, and what CloudVault is being designed to change — marked so you can tell a decision from a plan.
The 2am text you cannot ignore.
The client texts at 2am. The site is down. You are on a laptop in bed, SSH'd into a VPS you set up eighteen months ago, trying to remember how you configured it — while the client watches the clock and quietly forms an opinion about your agency.
Infrastructure monitoring and first response are designed to sit with us, inside a coverage window we agree with you in writing. You would get an incident summary — what broke, what we did, when it resolved — and you decide what your client hears and when.
Boundary: we report facts to you, not to your client. Coverage windows, escalation limits, and who is reachable when are being defined honestly for a small operator — not sold as an always-on rotation.
Nobody documented it. Now it is yours.
A new client arrives with a site somebody else built on a server nobody wrote down. No repository, no build process, a runtime from a previous decade, and a hosting login that may or may not still work. Quoting the work is guesswork, because you do not yet know what you are touching.
Onboarding is designed to open with an inventory: what is actually running, which runtime, where the data lives, what the DNS and mail records really do. You get that written inventory whether or not you go ahead. Migration scope is quoted before anything moves — we would rather tell you a stack is a bad fit than accept it and find out later.
Boundary: you supply source access and authorize the cutover. We do not promise to accept every legacy platform, and the supported list is still being decided.
Success arrives as an infrastructure problem.
The site you built two years ago is doing real traffic. Shared hosting is buckling, the client is complaining about speed, and the fix is a migration you will do at night and absorb the cost of — because raising it feels like admitting the original setup was wrong.
Capacity is designed to be a conversation rather than an emergency. Once monitoring exists, we would advise from observed infrastructure usage and tell you what it implies before it becomes urgent. Resizing an environment would be a planned change you approve — not a surprise invoice, and not a claim that growth is ever completely invisible.
Hosting is either a cost you absorb or a line you own.
You charge for builds. Hosting is either free — you eat it — or passed through at cost, so you break even and still do the work. Revenue stays project-shaped: feast, famine, feast.
Wholesale capacity rather than per-site resale. You would take a block sized to your book, put client sites on it, and set your own retail price. The spread is yours.
- You buy
- Capacity at a wholesale rate.
- You sell
- Your own managed-hosting package, at your own price.
- You keep
- The difference, and the client relationship.
Rates, capacity limits, and terms are not set. There is no published price, no discount, and no rate-lock offer — that is a founding-partner conversation once the cost base is real.
The questions that cool a room.
A larger client asks about uptime, backups, and who touches their data. Here is what we can honestly say today — including where the answer is still "not yet".
What is your uptime guarantee?
There is not one. We will not publish an availability figure before there is a platform to measure, a defined measurement method, stated exclusions, and SLA wording that has had legal review. Anyone quoting you a number for infrastructure that has not run yet is guessing.
No figure will be published yetWho can reach our client's data?
Administrative access is limited to what is needed to operate the infrastructure, and the boundary is written down rather than implied. Your agency keeps ownership of schema, authorization logic, and application-level correctness.
Confirmed boundaryWill you contact our client directly?
No. Not for support, not for billing, not for marketing. If we need something we ask you. Any emergency contact path would be explicit, narrow, and documented — and never a route to sell around your agency.
Confirmed policyWhat if CloudVault does not make it?
A fair question to ask any young infrastructure company, and you should ask it of every vendor you put a client on. The platform is being designed around standard, portable components — Postgres, containers, ordinary routing — specifically so leaving does not require our cooperation to be easy.
Confirmed design principleDepartures should stay civil.
A relationship ends and the handover is a shoebox: scattered credentials, a server only you understand, and an awkward conversation about what the client is actually entitled to take with them.
Portability is a design principle, not a retention lever. Standard components mean an export is an export rather than a bespoke extraction project. The export process itself is still being built — what is settled is that leaving should not require a negotiation.
Boundary: exports follow authorization and account settlement. You coordinate the destination and the client conversation; we hand over the data and the infrastructure detail.
We do not market to your clients.
// Confirmed policy — C-03We do not upsell around your agency.
// Confirmed policy — C-02We are designing for portable, standard components.
// Confirmed principle — C-08Recognise more than one of these?
CloudVault is pre-launch and onboarding founding partners personally, starting with a single low-stakes site rather than your whole book. Join the list and we will talk about which one to move first.
// Pre-launch. Founding partners are onboarded personally, one site at a time.