● Plan para tu aprobación · LPDI

Transferencia y baja de entidades

Cómo transferir una Startup o un ICG a otra persona —de forma independiente o al cerrar la cuenta— con aceptación expresa, ventana de 30 días y manejo seguro de la recuperación de cuenta. Diseño previo a codear.

Startup + ICG 2 flujos de entrada Tamaño: L 4 jul 2026

Cómo funciona hoy

Startup

Propietario = quien la registró. Ya admite varios miembros (founders) con invitación, aceptación por token y recordatorios.
Al cerrar cuenta: la startup se borra solo si no tiene otros founders; si los tiene, sobrevive.
No existe transferencia de propiedad explícita.

ICG

Propietario = quien lo registró. Contacto = un usuario. Sin modelo de varios miembros.
Al cerrar cuenta: ICG «inversionista individual» se borra; ICG organizacional donde eres contacto queda sin contacto pero vivo.
No existe transferencia ni aviso al propietario cuando el contacto se va.

Aprovechamos la infraestructura de invitación/aceptación que ya tienen los founders de Startup para no construir la aceptación desde cero. El borrado definitivo + anonimización (ya construido) es el destino del «no transferir».

Dos flujos de entrada

Flujo TSolo transferir
Desde la entidad eliges «Transferir». No tocas tu cuenta.

Flujo CCierre de cuenta
Al dar de baja tu cuenta, por cada entidad propia decides: transferir o eliminar.

Destinos de la transferencia

(A) Al contacto actual del ICG (o a un founder existente en Startup).
(B) A otro usuario por correo — existente, o nuevo (se crea cuenta obligando a aceptar TYC y Política de Datos).
(C) A nadie → la entidad se elimina y pasa a anonimización.

Ciclo de una transferencia

Pendiente→ Aceptada / Rechazada / Expirada (30d) / Cancelada

Aceptada: el receptor acepta expresamente (si es nuevo, crea cuenta + TYC/PDP). Se cambia el propietario. Terminal.
Rechazada / Expirada: la entidad queda con el propietario original; en Flujo C sin otra vía, cae a eliminación/anonimización.
Cancelada: el propietario original recupera su cuenta antes de que el receptor confirme → se cae la transferencia.

Regla de la carrera «recuperación vs. confirmación»: si el propietario recupera su cuenta y la transferencia sigue pendiente → se cancela y vuelve a él. Si ya estaba aceptada → nada: recupera su cuenta de usuario, pero la entidad ya es del receptor.

Si el contacto del ICG cierra su cuenta

Al dar la orden de cierre: se limpian de inmediato los datos de contacto del ICG. El ICG queda intacto, solo sin contacto.
Se avisa por correo al propietario: su contacto ya no está disponible por cierre de cuenta y puede agregar uno nuevo → botón que lleva al formulario de ICG.
Si el contacto recupera su cuenta dentro de 30 días, no se re-vincula solo (solo si el propietario lo hace a mano). Evita limbos y sobrescrituras.

Correos nuevos

1Invitación de transferencia — al receptor, con botón aceptar/rechazar.

2Recordatorio de transferencia (durante los 30 días).

3Transferencia confirmada — al original y al receptor.

4Transferencia caída (expirada/rechazada/cancelada).

5ICG sin contacto — al propietario, con enlace al formulario.

Pantallas y base de datos

Pantallas

Botón «Eliminar / Transferir» en la entidad, con sub-flujo (a contacto/founder · a otro correo · eliminar).
En el modal de cierre de cuenta, un selector de destino por cada entidad propia.
Página pública «Aceptar transferencia» (enlace del correo): login o alta con TYC/PDP + aceptar/rechazar.
Panel del propietario: ver y cancelar transferencias pendientes.

Base de datos

Nueva tabla de transferencias (entidad, quién, a quién, vía, estado, token, plazo).
Funciones para crear, aceptar y expirar transferencias (validadas y auto-protegidas).
Enganche con la recuperación de cuenta para cancelar pendientes.
Reúso del motor de anonimización para el «caso C».

Cómo se construye (por olas)

Ola	Qué entrega	Depende de
0	Tabla de transferencias + funciones base	—
1	Crear transferencia · Aceptar/Rechazar	Ola 0
2	Correos (+ inventario) · Expiración automática	Ola 1
3	Pantallas: entidad · cierre de cuenta · aceptar	Ola 1, 2
4	Recuperación ↔ cancelación · ICG sin contacto	Ola 1, 3
5	Caso C → anonimización · Pruebas E2E	Ola 3, 4

Cada tarea llevará criterios verificables («listo cuando…») antes de codear.

5 decisiones para arrancar

Necesito tu ok en esto antes de escribir el plan técnico y codear.

1La Startup no tiene «contacto» sino founders. Para el destino (A) en Startup, ¿transferimos a un founder existente? ¿O en Startup solo aplican (B) otro correo y (C) eliminar?

2Cadencia de recordatorios de la transferencia: ¿día 10 y día 20? ¿otra?

3El Flujo T (transferir sin cerrar cuenta) es voluntario y no hay cuenta que recuperar: ¿también 30 días, o inmediato cuando el receptor acepta?

4Al cerrar la cuenta con transferencias pendientes: ¿la cuenta se inactiva esperando que se resuelvan, o cierra y las transferencias siguen su curso en paralelo?

5El receptor nuevo (creado en la transferencia): ¿con qué rol y qué onboarding entra?