Designing contact that does not expose a phone number

Put a phone number on a windscreen and you have solved a real problem — someone can tell you your car is blocking a gate — by creating a worse one. The number is now public, permanently, to everyone who walks past. Most people weigh those two things up and leave no number at all, which is why the original problem is still unsolved.

This shape recurs constantly. A marketplace connecting buyers and sellers, a booking app connecting a customer and a salon, a delivery handoff, a classified listing. Two parties need to communicate once, briefly, and then probably never again. The naive implementation hands each one a permanent identifier for the other.

Relay, do not reveal

The fix is to make the platform the addressable party. The contact point that goes public is one the product owns — a code, a short link, a proxy number — and the product routes messages to the real person behind it. Neither side learns anything durable about the other, and the platform can revoke the route the moment it stops being useful.

That single decision buys several things that are hard to add later:

• Revocation. A relay can be switched off. A phone number cannot be un-published.
• Rate limiting. You can cap how many messages a stranger sends before anything reaches the recipient.
• Filtering. Because messages pass through your system, abuse and spam can be caught before delivery rather than apologised for afterwards.
• Auditability. When something goes wrong, there is a record of what was sent, which there is not when two people exchange numbers directly.

The part teams underestimate

Relaying is easy. Deciding what happens when the relay is abused is the actual work. Someone will use the channel to harass. Someone will scrape codes and blast every one of them. If those cases are handled by a support inbox, the feature becomes a liability the first week it gets traction.

Classification at the point of delivery is worth building early, and it is a genuinely good use of a language model: short messages, clear intent categories, and a decision that only has to be roughly right because the fallback is holding a message for review rather than dropping it. Build the review queue at the same time. A filter with no appeal path is its own failure mode.

Where the design usually leaks

Privacy-first designs tend to leak at the edges rather than the middle. A confirmation email that quotes the recipient's full name. An error message that distinguishes 'no such user' from 'user is not accepting messages'. A notification preview on a lock screen. It is worth walking the whole flow, including every failure path, and asking of each screen: what does the other party now know that they did not before?

Getting this right is not primarily a technical problem. It is a product decision about what your users owe each other, made early enough that the architecture can support it.