From request to live — what the deploy handover contains

Nodipe is deliberately a people-run deployment, not a self-serve signup funnel. That means the path from “we want this” to “your site is live” has a shape you can predict — and it ends with a handover document you should read carefully. This guide walks both sides of that line: the steps, and what you’re entitled to see before you call it done.

The path from request to live

The flow is short on purpose:

1. You submit. Company name, the domain you want, a note about your product lines. This is a short note through the deploy form — no technical brief required.
2. A founder replies one-to-one. They check fit, confirm the domain is available or that you own it, and agree what your site will include. Any questions about timeline, content or price are settled here, in writing, before you commit.
3. Domain binding. The web records point at your node. If mail coexistence is part of your setup, that’s verified on the same pass — nothing about your existing mailbox changes without you confirming it.
4. The node handover confirmation. You receive a document that lists exactly what is live and where each piece of your setup stands. You review it. When you’re satisfied, the site is announced live.
5. Launch. Buyers can reach you, and inquiries start landing in your dashboard and inbox.

What your handover confirmation should list

Before you accept a node as live, the confirmation document should name each of these — not vaguely, but with the concrete value for your deployment:

• Instance ID — the identifier for your dedicated node, so there’s never ambiguity about which instance a support question refers to.
• Domain & DNS state — the domain(s) bound, whether the apex and www both resolve, and where the zone is hosted.
• Email coexistence status — confirmed either as “no mail on this domain” or “site and mailbox coexist; MX/SPF/DKIM verified”, so email safety isn’t an assumption.
• HTTPS & edge — confirmation that your domain serves over HTTPS with automatic renewal, and that the site is on the global edge.
• Data export entry point — where in your dashboard the one-click export lives, so the exit is visible from day one rather than discovered later.
• Content state — what was published at handover (which products, pages and copy), and how to request changes afterward.
• Contact channel — a direct line to the founding team, and the expected response behaviour, so “who do I write to” is never a question.

If any of these are missing from your confirmation, ask. A handover document is a contract about current state, not a brochure — it should read like a checklist with your values filled in, not marketing copy.

What about timelines?

You’ll notice this guide has no “launches in X days” promise. That’s deliberate. Launch timing depends mostly on how ready your product content is — a two-product precision shop can move faster than a three-hundred-SKU OEM catalogue — and we’d rather set a real expectation than a slogan.

The honest rule is: timing is agreed in your one-to-one, confirmed in writing, and only then relied on. If a founder quotes you a date, it will be a date for your specific content scope — not a generic marketing number. If you need something faster or slower, that’s exactly the kind of thing the one-to-one exists to sort out.

Before you go live

Three habits make the handover cleaner:

• Confirm the domain with your registrar. The registration stays in your name. Verify you control the account, so “who owns the domain” is settled before launch rather than during a later dispute.
• Keep your content ready. The faster your product copy, specs and photos are finalised, the less the launch depends on back-and-forth.
• Test the inbox before announcing. Send one test inquiry through the live site and confirm it lands where you expect — dashboard and mailbox — before you tell buyers the channel is open. The inquiry dashboard guide covers what to check.

The measure of a good handover isn’t that the site is up. It’s that every asset — domain, data, email, and the ability to leave — is accounted for in writing on the day you launch.