La deuda que se paga tarde

Las ocho

Y la columna izquierda entera cabe en unos días; la derecha, en versiones enteras y en datos perdidos.

Qué tienen en común

Y reconocer el patrón ayuda a detectar las que no están en la lista:

Y la pregunta que las detecta: ¿esta decisión deja rastro en la máquina del usuario? Si sí, cambiarla más adelante va a ser una migración — y merece pensarla ahora.

Priorizar las que ya tengas

Y el orden razonable si tienes varias:

• Primero las que pueden perder datos: 3 y 4. Son las únicas irreversibles, y la corrección protege hacia delante aunque no repare lo pasado.
• Después las que se agravan cada día: 1, 6, 7 y 8, porque cada usuario nuevo aumenta el coste de corregirlas.
• Y al final las de estructura: 2 y 5, que son trabajo y no empeoran solas.

Y una nota sobre la 1: si tu aplicación aún no tiene usuarios, cambiar el identificador es gratis y merece hacerse hoy si hay alguna duda sobre él.

Evitarlas en lo nuevo

Y para lo que empiece a partir de ahora, las ocho son decisiones de un día:

• Identificador definitivo desde el principio.
• Comandos de dominio desde el primero.
• Escritura atómica y copias antes de migrar, desde la primera versión.
• Estado en el core.
• Versión mínima, identificadores no correlativos, y publicar separado de activar.

Ninguna cuesta más que su alternativa al empezar, y todas cuestan mucho más después. Es la definición de una decisión que merece tomarse pronto.