L'anonimato come invariante architetturale: perché «non vi contatteremo» non basta
Promesse come «non sarete mai contattati senza preavviso» nelle piattaforme B2B non sono applicabili — i fornitori le aggirano offline. Ciò che funziona è un'invariante tecnica: i dati di contatto vivono in una sfera separata, il server li rilascia solo a match bilaterale. Una proprietà del codice, non una clausola dei TOS.
La classica promessa di matching B2B: «non sarete mai contattati senza preavviso». Bella formulazione. Non applicabile.
Una piattaforma non può impedire a un fornitore di fare ricerca offline, estrarre il numero aziendale dal registro delle imprese e chiamare. La promessa è un'affermazione sul mondo — e il mondo è più vasto di qualunque contratto TOS.
Ciò che regge davvero: invarianti architetturali
Su PairSonal abbiamo riformulato la promessa. Invece di:
«Non condivideremo i vostri dati di contatto.»
ora si legge:
«I vostri dati di contatto HR sulla piattaforma sono tecnicamente invisibili ai fornitori — finché non sbloccate voi stessi un match.»
La differenza non è semantica. È strutturale:
- I dati di contatto vivono in una sfera di database separata.
- Gli endpoint di listing restituiscono profili il cui payload semplicemente non contiene
email,telefono,hr_contact. - L'endpoint di match esegue il join sulla sfera dei contatti server-side, e solo dopo lo sblocco bilaterale.
- Il frontend non ha alcun code path che possa ricostruire campi che non esistono nel tipo generato.
La promessa diventa una proprietà del codice. Chi prova "cosa succede quando carico i profili?" trova i campi assenti. Non "filtrati", non "null" — non presenti nello schema.
Perché è più forte
- Auditabile. Un revisore legge lo schema OpenAPI e verifica: i campi di contatto non esistono nella sfera anonima. È un fatto, non una clausola TOS.
- Scala con l'organico. Un nuovo collega non può accidentalmente costruire un endpoint che fa leak dei campi — non sono nella classe del modello dati che importa.
- Sopravvive a bug di auth. Un bug nello strato di privilege non può esporre campi nascosti che nello schema della risposta non esistono.
Quando è eccessivo
Le invarianti architetturali costano. Stai di fatto mantenendo due modelli dati, due repository, due classi di servizio, un ponte esplicito fra loro. Per un profilo utente con tre attributi è esagerato.
Il punto in cui ripaga: quando la promessa è il prodotto. Se i clienti arrivano sulla piattaforma perché si fidano dell'anonimato, l'anonimato non può vivere in una clausola TOS. Deve vivere nell'architettura a strati — altrimenti il prodotto muore al primo leak.
La regola generale
Per ogni promessa "non faremo X" oggi ci chiediamo:
Possiamo costruirlo in modo che tecnicamente non possiamo farlo?
Se sì: costruiamolo. Se no: la promessa è un'affermazione, non una feature — e va nominata come affermazione, non venduta come feature.
Stesso fuoco anche da te?
Probabilmente abbiamo già visto qualcosa di simile. Parliamone.
Iniziamo a parlarne→