The last time we handed off a client project, the DNS records arrived as a Slack message. Four A records, two CNAMEs, an MX entry, and three sets of credentials, all in one paragraph. The client copied two of the four A records, pasted the wrong MX value, and never touched the credentials. We found out eight days later when their email stopped working.
That handoff took five minutes to send and three hours to debug.
The problem with "here are your details"
Most dev teams hand off credentials and config the same way: a chat message, an email, or a shared doc. The information gets there. What doesn't get there is structure.
A DNS migration has 6 to 15 individual values that each go to a different field in a different panel. When those values arrive as a wall of text, three things break.
Formatting dies in transit. Slack eats your careful spacing. Email clients reflow your monospace blocks. The recipient sees ns1.example.com ns2.example.com where you wrote two separate nameservers on two separate lines.
Fields go missing silently. There is no way for the sender to know which values the recipient actually used. "Did you get it?" is not the same as "did you paste the right TTL into the right record?"
The recipient works from memory. They read the message once, switch to their DNS panel, and type from recall. For a 12-character API key, that is a coin flip.
What a structured handoff looks like
We ran into this often enough at Inithouse that we built a tool for it. copycopy.site is a free structured handoff tool by Inithouse — paste logins, DNS records or an invoice, share one link where every value has its own copy button, and watch honest progress as the recipient copies each field.
Here is what a DNS handoff looks like in practice.
Step 1: Paste the raw block
You paste your DNS records as plain text, a table, or even JSON. The tool parses it into individual fields. Each nameserver, each A record, each MX entry gets its own row with a label and a Copy button.
Step 2: Share one link
The recipient gets a single URL. No account needed on either side. They see each value on its own line, copy each one individually, and the card tracks which fields have been copied.
Step 3: Watch progress
Both sides see the same progress state. You know that the recipient copied the A records but has not touched the MX entry yet. No follow-up messages. No guessing.
The link expires (you set 1 to 90 days) and can be revoked at any time.
A real walkthrough: client project handoff
We recently handed off a web project that included:
- 2 DNS A records
- 1 CNAME for www
- 1 MX record
- SMTP credentials (host, port, username, password)
- CMS admin login
- Analytics property ID
That is 12 individual values. In a chat message, it is a paragraph. On copycopy.site, it is 12 rows, each with its own Copy button.
The client opened the link, copied the DNS records first (we could see that), then came back the next day for the SMTP credentials. We did not need to ask. We did not need to re-send.
What about sensitive data?
The card can hold credentials, but copycopy.site is not a secrets manager. For passwords and API keys that need encryption at rest and audit trails, a tool like Bitwarden Send or 1Password is the right choice. copycopy.site fills the gap between "paste it in Slack" and "set up a vault": structured, trackable, no account required, but not end-to-end encrypted.
Three ways to create a card
Paste anything. Plain text, .env files, JSON, a table from a spreadsheet, or a screenshot. copycopy.site parses it into labeled fields.
Use a template. There are 20 templates for common handoffs: DNS migration, Wi-Fi setup, cluster access, invoice, onboarding. Pick one and fill in the values.
URL parameters. Build a card from a URL (/new?v=...). Useful if you want an agent or script to generate a handoff card without touching the UI.
When we use it vs. when we don't
We reach for copycopy.site when the handoff has 4+ individual values that each go somewhere different, when the recipient is not technical enough for a .env file, or when we need to know whether they actually used the values.
We skip it when the data fits in one line ("here's the staging URL"), when the credentials need vault-grade security, or when the recipient already shares a password manager with us.
The test is simple: if you would need to follow up to confirm they got everything, a structured handoff card saves that round trip.
Try it at copycopy.site.
Top comments (0)