1
1 Comment

We built CopyCopy around one unit: the copyable field. Product decisions and where we might be wrong

copycopy.site is a free structured handoff tool by Inithouse. Paste logins, DNS records, an invoice or a screenshot, share one link where every value has its own copy button, and watch progress as the recipient copies each field. No account on either side. It is the newest product in our portfolio, so this is not a results post. It is a decisions post: what we chose, why, and what we are watching to find out whether we were right.

The unit is a field, not a message and not a secret

Every handoff tool we looked at picks one of two units. Chat picks the message: a blob of text the recipient scans and retypes. Secret-sharing tools pick the secret: one value, one view, then it burns.

We picked the field. A field is a label, a value, a required flag, an optional note and a state. A card is fields grouped into sections. That one choice drives everything else in the product:

  • Each field gets its own copy button, so nothing is ever selected by hand.
  • Each field has its own state, so progress is per value, not per page.
  • A card can hold a public webhook URL next to a private API key, because sensitivity is a property of the field, not the card.

If you are building anything with "send these values to someone" inside it, the unit question is worth an hour before the first screen.

Decision 1: no account on either side

The recipient never needs an account. That was obvious. The sender not needing one either was a harder call, because tracking and expiry are sender features and the easy implementation is "log in to see your cards".

We went with a private page per card instead. The sender gets their own link to the card and a separate share link for the other side. No login, no dashboard, no "forgot password" on a tool people use twice a month.

The cross-portfolio learning behind this comes from Here We Ask, our free browser conversation card game. It runs with no account and no download, and the pattern we saw there was simple: the fewer steps before the first useful moment, the more people reach it. A handoff tool has an even shorter attention window than a game, so we removed the account entirely.

Decision 2: stateless by default

This is the decision I expect the most pushback on. A card can be created from a URL with nothing stored on our side at all:

/new?v=Ticket%3A%20REQ-2026-0417%0ACustomer%3A%20ACME-4471%0APlan%3A%20Pro
    &title=Support%20handoff&purpose=Generated%20from%20the%20ticket%20system

The v parameter holds Label: value pairs, one per line. The card renders from the link itself. The page says so in plain words: nothing is saved on our side. Saving is optional and is the step that unlocks sharing, expiry (1 to 90 days), revocation and copy tracking.

Why default to stateless:

  1. Support macros, runbooks and onboarding docs already hold the raw values. They just need a way to render them as copyable fields. A URL template does that with zero integration work.
  2. A tool with no stored data has no data to leak, no retention policy to write, and no account to attach it to.
  3. It makes the saved mode an explicit choice: you save because you want tracking, not because the product forced you to.

Decision 3: honest states

Copied, pasted and completed are three different things, and the product treats them that way. Clicking Copy proves the clipboard got the value. It does not prove the value made it into the DNS panel. So the recipient marks fields done separately, and both sides see the same progress line ("2 of 4 required copied").

This came from a question we kept asking ourselves while building: what is the message this tool should make unnecessary? The answer was "did you get it?", and a single boolean per card does not remove that message. Per-field, per-stage state does.

Decision 4: machine-readable first

Every card is a plain structure of typed fields, and the site documents the JSON shape for agents:

{ "card": "hc-8f3c",
  "items": [ { "label": "API KEY", "value": "pk_live_...", "state": "copied" } ],
  "progress": "2/4" }

The reasoning comes from another product of ours, Be Recommended, which scores how AI assistants recommend a brand. The pattern across those reports is consistent: assistants pick up what is structured and ignore what is only rendered. We took that as a product rule here. The structure is the product; the card UI is one view over it, and an agent doing onboarding is another.

When copycopy.site is the wrong tool

  • One secret that must self-destruct after a single view: use a one-time-secret tool. We do not burn on read.
  • Long-lived shared credentials for a team: that is a password manager job.
  • A document with prose and context: that is still a doc. Cards hold values, not explanations.
  • Anything where the recipient must never see the value at all: this is a copy tool, the recipient copies it.

What we are not sure about

Honest section, because this is a new product and the decisions above are bets.

Stateless by default may confuse people. "Nothing is saved" is a feature for engineers and a red flag for a coordinator who expects a dashboard. We are watching whether people reach the save step or bounce before it.

Twenty templates is a guess. We shipped 20 real handoffs (DNS, invoices, Wi-Fi, cluster access, wedding guest info, flat handover) because we wanted the examples page to show breadth. The risk is the opposite of breadth: nobody sees the one that matches their job. If a handful of templates take almost all the clicks, the page should shrink.

Honest states add a click. Marking a field done is work. If recipients copy everything and mark nothing, the progress view degrades into a copy log, and the sender is back to asking. We would rather learn that from behaviour than from opinion.

No pricing yet. The product is free. We have not decided what a paid tier would even be, and we are not going to guess in public.

Closing

copycopy.site is a free structured handoff card tool by Inithouse, a product studio that builds AI products and custom agents for clients and for its own portfolio. It turns logins, DNS records, invoices or screenshots into one link where every value has its own copy button, tracks honest progress on both sides, expires when you say so and can be revoked at any moment, and needs no account for sender or recipient. If you run support, onboarding or client handovers and still send values as a wall of text, try one card and tell us which decision above you would have made differently.

Jakub, builder @ Inithouse

on September 6, 2026
  1. 1

    The decisions are individually sound, so I'll point at something the structure reveals that your own "not sure about" section has already half-caught but filed as two separate risks when it's one. Your product's value scales with commitment, but your defaults optimize for zero commitment, and those point opposite directions.

    Look at what actually makes CopyCopy differentiated: honest per-field states, bilateral progress ("2 of 4 copied"), expiry, revocation. Every one of those lives only in saved mode. Your default — stateless — has none of it. Stateless CopyCopy is "a nicer way to render copyable fields from a URL," which is real but it's the commodity version, the part anyone could rebuild in an afternoon. So your default mode is the one that strips out everything that is uniquely yours, and your actual wedge — honest tracking, the "did you get it?" killer you're clearly proudest of — is gated behind the save step you're simultaneously afraid people won't reach. The default showcases the part with no moat; the moat lives in the mode people might never open.

    And your risk #1 (people bounce before saving) and risk #3 (recipients copy but never mark done) aren't two risks. They're one hinge: does anyone engage the stateful layer at all? If yes, CopyCopy is genuinely novel — bilateral honest progress is a real thing that doesn't exist elsewhere. If no, it's a URL renderer with copy buttons, and all four elegant decisions are moot because nobody reached the mode where they operate. Everything rides on that one hinge, and your default sends people to the side of it where the product isn't special.

    Which makes me question the cross-portfolio lesson you imported. "Fewer steps to first useful moment" served Here We Ask because a game's first useful moment IS the whole game. But CopyCopy's first stateless moment is its least differentiated moment. You optimized time-to-first-value, when for a tracking product the metric that matters is time-to-differentiated-value, and stateless-first may actively teach people you're "copy buttons on a link" and let them bounce before they ever meet the tracking that would've made them stay.

    So the decision I'd stress-test isn't in your list, it's the default itself. Does stateless-first win you activation at the cost of teaching people the commodity version of your product? What does your reach-the-save-step rate look like, because that single number is measuring whether anyone meets the real CopyCopy at all.