El playbook de cuatro semanas y nuestro propio marcador
El método para levantar una vertical sobre infraestructura compartida en cuatro semanas, y después el registro que dice cuántas de las nuestras cumplen.
Por qué cuatro semanas son posibles
Casi nada de una vertical nueva es nuevo.
Todas necesitan saber quién es un usuario, qué es una empresa, cómo pertenece una persona a una empresa, cómo se acota una clave de API y cómo se sobrescribe un permiso para un tenant. Son cinco entidades, y son idénticas tanto si el producto alquila excavadoras como si agenda fisioterapia.
Encima están las capacidades: diecinueve paquetes bajo @inite/*, que cubren bandeja de entrada, facturación, incidentes, notificaciones, i18n, seguridad, escaparate y conocimiento entre otros, más tres servicios horizontales para auth, billing y brain. Tampoco se reescribe nada de eso.
Lo que queda es lo que hace que el producto sea el producto: los objetos de dominio y los flujos sobre ellos. Para un alquiler, el activo, la reserva y el despacho. Para una inmobiliaria, el inmueble, el anuncio y la operación. Ese es el único código genuinamente nuevo, y cuatro semanas es lo que tarda cuando todo lo de debajo ya funciona.
El orden que importa
| Semana | Qué entra | Por qué aquí |
|---|---|---|
| 1 | auth, tenant | Todo lo posterior depende de quién pregunta y por quién |
| 1 | api-kit | Errores y límites uniformes antes de tener endpoints que uniformar |
| 2 | El modelo de dominio | Lo único genuinamente nuevo de la obra |
| 2-3 | La interacción principal: bandeja o escaparate | Lo que el producto realmente es |
| 3 | assistant, notifications | Útiles cuando ya hay algo a lo que asistir |
| 4 | billing, security, i18n | El precio al final porque es lo que más cambia |
Identidad primero es la regla con la consecuencia más afilada. Meter multitenencia en un producto que asumía un solo cliente es la reelaboración más cara de este oficio, y es el error que convierte un clon de cuatro semanas en uno de tres meses.
La facturación va al final por la razón contraria. El precio cambia más que la identidad, y construirla en la semana uno significa construirla dos veces.
El marcador, sin maquillaje
Un post de playbook suele terminar con un recuento de éxitos. En su lugar, el registro real.
| Estado | Cant. | Qué significa |
|---|---|---|
| production | 1 | Atendiendo usuarios |
| pilot | 2 | Calibrando activamente la especificación |
| migration_pending | 4 | Repositorio existe, pretende cumplir, hueco en el modelo |
| drift | 4 | Consume los paquetes compartidos, sin manifiesto |
| non_conforming | 2 | Repositorio existe, sin paquetes, sin manifiesto |
| candidate | 3 | Nombrada, no empezada |
| legacy | 2 | Sustituida |
| conforming | 0 | Declara versión y cumple el contrato |
Dieciocho entradas. Una en producción. Y el estado que la especificación define como meta no lo tiene nadie.
Esa última fila merece un minuto. conforming significa que la vertical declara su versión de ecosistema y cumple el contrato entero. Todavía no lo cumple nada. La mitad del registro está en drift o migration_pending, es decir: usando el runtime compartido en la práctica, sin haberlo asumido aún por escrito.
Por qué lo publicamos así
Porque un recuento de verticales es un número de marketing y un registro de estados es uno de ingeniería, y solo el segundo puede estar equivocado de una forma que alguien note.
"Dieciséis verticales sobre un runtime compartido" es una frase que sobrevive a cualquier cantidad de desviación por debajo. "Cero conformes, cuatro desviadas" es una frase que crea trabajo. El registro se mantiene a mano y se actualiza en cada versión de la especificación precisamente para que no se convierta en silencio en un número del primer tipo, y por el mismo razonamiento la separación entre constitución y runtime mantiene el repositorio de la especificación libre de código ejecutable: una especificación que entrega runtime deja de ser verificable contra nada.
Qué compran cuatro semanas y qué no
Compran la eliminación de la parte repetible. Un producto multitenencia funcionando sobre infraestructura que otras verticales ya han depurado, con identidad, facturación y mensajería heredadas en lugar de descubiertas.
No compran clientes, conocimiento del dominio, el precio correcto, ni el punto en que aquello se paga solo. Nuestro registro es la prueba: el trabajo de infraestructura está repartido por dieciocho entradas, y exactamente una está en producción.
Una vertical con un modelo de dominio genuinamente inédito también tardará más, y ninguna fontanería heredada cambia eso. Las cuatro semanas son una afirmación sobre el suelo, no sobre el techo. El caso de alquiler es donde el número aguantó, y el inmobiliario enseña qué cambia cuando el modelo de dominio se aleja más de la plantilla.
Si vas a hacerlo por tu cuenta
La parte transferible aquí no son nuestros paquetes. Es la disciplina de decidir, antes de la primera vertical, qué capa tiene permiso para tener opinión.
Escribe las entidades que compartirán todos los productos de tu familia y no dejes que ningún producto suelto las cambie. Pon el runtime compartido detrás de una versión. Lleva un registro de qué productos lo cumplen de verdad, y haz que los estados honestos resulten incómodos de mirar, porque un registro que no hace torcer el gesto a nadie es un registro que nadie actualiza.
01Si el método funciona, ¿por qué solo hay una vertical en producción?+
Porque construir una vertical y cumplir una especificación son trabajos distintos, y solo el primero es urgente para alguien. Una vertical llega a producción cuando atiende usuarios lo bastante bien como para cobrar por ello; llega a conforming cuando declara una versión de ecosistema y cumple el contrato entero, un trabajo que se paga después y no antes. El registro es deliberadamente poco halagador. Cuatro de las dieciocho están en drift, es decir, consumen los paquetes compartidos y nunca han publicado un manifiesto, y otras cuatro en migration_pending, es decir, el repositorio existe y la intención de cumplir existe, pero hay un hueco en el modelo de datos. Esa distribución es la cara real de un programa guiado por especificación a mitad de camino, y publicarla como registro de estados en lugar de como recuento de marketing es la única manera de que el número siga siendo útil de puertas adentro.
02¿Qué es compartido y qué hay que escribir cada vez?+
Compartido: las cinco entidades del Ring 1 que definen quién es un usuario, qué es una empresa y cómo se relacionan, más los paquetes de capacidad de bandeja de entrada, facturación, incidentes, notificaciones, i18n, seguridad, escaparate y base de conocimiento, más los tres servicios horizontales de auth, billing y brain. Nada de eso se reescribe. Escrito por vertical: los objetos de dominio que hacen que el producto sea lo que es, y los flujos sobre ellos. Para un alquiler son el activo, la reserva y el despacho; para una inmobiliaria son el inmueble, el anuncio y la operación. Esa proporción es lo que hace posibles las cuatro semanas, y es también el límite honesto de la afirmación, porque una vertical con un modelo de dominio genuinamente inédito tardará más por mucha infraestructura que herede.
03¿En qué orden hay que adoptar las capacidades?+
Identidad primero, siempre: auth y tenant, porque cada decisión posterior depende de saber quién pregunta y en nombre de quién, y meter multitenencia en un producto que asumía un solo cliente es la reelaboración más cara de este oficio. Después el envoltorio de peticiones, para que forma de error, registro y límites queden uniformes antes de que haya muchos endpoints que uniformar. Después la capacidad que lleva la interacción principal del producto, normalmente bandeja de entrada para todo lo que tenga conversaciones o escaparate para todo lo que tenga catálogo. La facturación entra más tarde de lo que esperan los fundadores, porque el precio cambia más que la identidad y construirla pronto significa construirla dos veces. Seguridad e i18n van al final solo en la secuencia, no en importancia, y ambas son mucho más baratas sobre un modelo de tenencia limpio que atornilladas a uno sucio.
04¿Una vertical de cuatro semanas significa un negocio de cuatro semanas?+
No, y confundir ambas cosas es el error más común con un número así. Cuatro semanas es el tiempo de ingeniería para levantar un producto multitenencia funcionando sobre infraestructura que ya existe y que las verticales anteriores ya han depurado. No es el tiempo de encontrar clientes, aprender el dominio, acertar el precio o llegar al punto en que aquello se paga solo. Nuestro propio registro es la prueba: el trabajo de infraestructura está en buena parte repartido por dieciocho entradas, y exactamente una está en producción. Lo que las cuatro semanas eliminan es la parte genuinamente repetible, lo que libera el calendario para la parte que no lo es. Quien venda la segunda mitad como resultado de cuatro semanas está vendiendo otra cosa.
