Documento de trabajo · agosto 2026
People Evolution ya sabe hacer el trabajo. Lo que hoy se entrega persona por persona, en hojas de cálculo y juntas, puede entregarse como plataforma —sin dejar de ser suyo, y sin perder el acompañamiento que lo hace valioso.
Lo que está en people.noko.mx no es una maqueta: es la plataforma corriendo. Se construyó como prueba de velocidad.
El punto de partida
El instrumento de clima, la lectura de resultados y la conversación con el cliente son de People Evolution. Eso no se automatiza: se apalanca.
Cada evaluación consume horas de armado, seguimiento y vaciado. Ese esfuerzo limita cuántos clientes se pueden atender a la vez, no la demanda.
Un desarrollador de medio tiempo y un flujo que hay que explicar antes de usar. Hace falta un dictamen honesto de qué se rescata y qué no.
Cómo trabajaríamos
Nadie firma a ciegas. La primera fase es corta, tiene alcance cerrado y entrega algo que sirve aunque no haya segunda.
2 a 3 semanas · alcance cerrado · sin compromiso posterior.
Auditoría del repositorio y la infraestructura actuales. Dictamen de qué se
rescata, qué se reescribe y qué se tira. Roadmap priorizado a seis meses y
definición del producto mínimo de evaluaciones self-service.
Se entrega: documentos ejecutables —del tipo que un desarrollador puede tomar y construir— y el alcance de la plataforma dibujado a detalle. Si aquí se acaba la relación, People Evolution se queda con todo lo entregado.
Acompañamiento continuo · cancelable con 30 días de aviso.
Traducir la visión a sprints y dirigirlos. Dirigir al desarrollador actual
o sustituir esa función con nuestro stack. Diseño de la experiencia e
integración de IA. Dedicación parcial, resultados verificables por sprint.
Si el producto demuestra tracción, tiene sentido hablar de una relación más profunda que la de proveedor. Esa conversación se tiene con resultados sobre la mesa, no con una promesa — y por eso no se anticipa aquí.
Fase 1 al detalle
Dos a tres semanas, alcance cerrado. Esto es exactamente lo que se revisa y lo que queda en manos de People Evolution al terminar.
Revisión del repositorio actual: qué tan mantenible es, qué tan probado está, de qué depende y qué tan atado queda People Evolution a decisiones que ya se tomaron. Se revisa también dónde está desplegado, cómo se respalda y qué pasa el día que el desarrollador actual no esté.
Se recorre la plataforma como la recorre un cliente y como la recorre Mariana. Dónde se traba, qué hay que explicar antes de que alguien pueda usarlo, y qué pasos existen solo porque el software no supo resolverlos.
Pieza por pieza: esto se conserva, esto se reescribe, esto se tira. Con el porqué de cada una y qué cuesta en tiempo. Sin diplomacia: el trabajo de un diagnóstico es decir lo que nadie quiere oír, si es lo que hay.
Definición precisa del producto mínimo de evaluaciones que una empresa cliente puede operar sola: qué entra, qué no entra, y el criterio verificable con el que se sabrá que está terminado.
Sprints secuenciales con criterios de terminado verificables, no estimaciones optimistas. Cada sprint asume el anterior y se puede detener sin romper lo construido.
Del tipo que un desarrollador —el actual, otro, o una IA— puede tomar y construir sin más contexto. Es el mismo formato con el que se levantó esta plataforma en un día.
Acceso de lectura al repositorio y al entorno actual, una sesión con Mariana para recorrer el flujo real, y un ejemplo completo de un entregable de clima tal como se entrega hoy al cliente. Nada más.
Todos los documentos, el dictamen y el roadmap. Si después de la Fase 1 la decisión es seguir con otro proveedor —o sin ninguno— el diagnóstico sirve igual. Está escrito para eso.
Por qué NoKo
Lo que está en people.noko.mx no salió de la nada ni se armó para esta junta. Salió de un taller que lleva tres meses construyendo plataformas reales, con reglas escritas y herramientas propias que se reusan de un desarrollo al siguiente.
La Caja
Cada pieza se extrajo de un desarrollo real, se probó y quedó documentada para humano y para IA. Existen en TypeScript y en Python, y las marcadas como interoperables producen bytes idénticos en ambos lenguajes. Por eso esta plataforma tuvo bóveda cifrada, bitácora inalterable y capa de IA desde el primer día: no se escribieron, se sacaron del cajón.
Cómo se trabaja
Ocho reglas de taller, cada una con su documento, su disparador y sus casos en contra. No son un manifiesto: son un menú. Cada desarrollo declara cuáles adopta, y las que adopta se cumplen o el despliegue se detiene. Estas son todas, con el motivo por el que existen.
«No hay dos martillos; el martillo vive en el cajón y se usa desde ahí.»
Nada reutilizable se escribe dos veces. Existe una fuente canónica, cada desarrollo se lleva su copia y la afila, y la mejora que sirve para todos regresa al origen con versión nueva. La consecuencia comercial es directa: un cliente nuevo es configuración, no un proyecto nuevo.
«No se empuja nada a producción —aunque el cambio sea una coma— sin actualizar la documentación aplicable.»
El despliegue queda bloqueado si el documento de contexto no cambió. Suena a burocracia y es lo contrario: la documentación que no se toca en cada despliegue miente a los pocos días, y una plataforma cuyo mapa miente es una plataforma que solo puede mantener quien la escribió.
«Nada está terminado si no se puede ver y comprobar desde la pantalla.»
Ni una función se da por hecha si solo vive en el backend, en la base o en una prueba. Existe para evitar la entrega fantasma —funciona en el test y el usuario no lo ve— y obliga a que el backend y la interfaz avancen juntos. El criterio de terminado de cada sprint se escribe como algo que el cliente puede abrir y mirar.
«Si una acción existe en la interfaz y no está en el Registro, es un bug.»
Lo que se hace con mouse y teclado se puede pedir hablando. La interfaz y el chat son dos clientes de la misma capa de capacidades, no dos programas que hay que mantener de acuerdo. Y el copiloto solo puede lo que el usuario podría con su propia cuenta: la IA no es una cuenta de administrador con buenos modales.
«Solo se crean migraciones nuevas; nunca se edita una ya aplicada.»
Ninguna credencial vive en el código. En el archivo de arranque solo van los secretos de conexión; todo lo demás lo captura el propio cliente en un panel y se guarda cifrado. Corregir el pasado es un movimiento nuevo hacia adelante, jamás una edición hacia atrás — crítico donde hay libro mayor.
«Nadie llega directo a donde viven los datos.»
La aplicación y su base corren en un servidor privado, y el servidor público es únicamente una ventana que pasa el tráfico por una red privada. La cara expuesta a internet no guarda un solo dato ni ejecuta la aplicación. Es exactamente la topología con la que esta página está en línea ahora mismo.
La Bóveda, El Portavoz, La Caseta, Los Chalanes — nunca «AuthUtils» ni «CryptoService».
Todo en español, y cada pieza con nombre de taller. No es folclor: un equipo mexicano lee su propio código sin traducir, y un nombre de oficio dice qué hace la pieza sin abrir el archivo. Las únicas palabras en inglés son las que el framework exige por contrato, y esa excepción está escrita.
Cómo se le da taller a alguien que empieza, sin darle las llaves de todo.
Nació de un caso real: entregarle a un desarrollador junior su propia infraestructura, sus accesos acotados y sus reglas, con once trampas ya documentadas para que no las pague él. Habla del ambiente de trabajo tanto como del código — y de que aquí se documenta hasta cómo se enseña.
Cómo se entrega
Las de arriba dicen cómo se construye. Estas dicen cómo se trabaja con quien contrata, y son las que explican por qué ninguno de los diez desarrollos de abajo se quedó en una presentación.
La versión comercial de la regla 02. Ninguna junta de NoKo empieza con un PowerPoint de lo que se va a hacer: empieza con una dirección que se abre en el navegador. Esta página existe por esa regla — se levantó para que esta conversación tuviera algo que enseñar, no algo que imaginar.
Sus datos son suyos y salen completos cuando los pida. La autenticación es propia, no rentada a un proveedor que un día cambie las reglas o los precios. Un cliente que se queda porque no puede irse no es un cliente satisfecho: es un rehén, y ese modelo se cae solo.
Literal, de La Quiniela: la plataforma registra, sella, publica y da fe — el dinero se mueve fuera. Donde no hace falta ser intermediario financiero, no se es. Se evita una categoría entera de responsabilidad legal, de obligaciones regulatorias y de desconfianza, a cambio de nada.
Cada llamada a un modelo de IA queda registrada con su consumo, su costo y a qué tarea y a qué cliente pertenece. Sin eso, la IA es un gasto que aparece a fin de mes sin explicación — y un costo que no se puede explicar tampoco se puede cobrar con la cara limpia.
En esta misma página, cada pantalla trae su sello: corriendo o diseñado. El roadmap dice qué está y qué no, con fechas de a de veras. Es más incómodo de presentar y es la única forma de que la segunda junta sea mejor que la primera.
La consecuencia comercial de la Regla del Martillo, y la que decide si un negocio de software escala o se convierte en una agencia. Diez clientes con diez copias del programa son diez programas que mantener. Diez clientes sobre el mismo núcleo son un producto.
Los desarrollos
Ninguno es una demostración: todos tienen infraestructura propia, despliegue automatizado y documentación viva.
Y esta plataforma, People Evolution, levantada de cero en un día —cimientos, acceso, aislamiento por cliente, auditoría, despliegue y dominio— para que esta conversación tuviera algo que enseñar.
Siguiente paso
Es corto, tiene alcance cerrado y termina con documentos que sirven con o sin nosotros. De ahí se decide si hay Fase 2.
Hablemos del diagnóstico