Cuatro frentes, una forma de trabajar.

Desarrollo de Producto

Tienes un producto que poner en pie y no tienes meses para montar un equipo — ni margen para equivocarte en la base y descubrirlo en el lanzamiento.

Ingeniería de punta a punta, desde cero: un descubrimiento corto para recortar alcance, el primer tramo en producción en semanas y el producto evolucionando en ciclos a partir de ahí. Sin big bang, sin prototipo que haya que tirar después.

• 01Alcance dividido en tramos, con la primera entrega definida sobre el papel
• 02Aplicación en producción, con CI/CD y entornos separados
• 03API y modelo de datos documentados
• 04Observabilidad y alertas desde la primera semana
• 05Repositorio, nube y dominios a nombre de tu empresa

• ¿En cuánto tiempo veo la primera versión en producción?+

  Entre cuatro y ocho semanas para el primer tramo útil, según el alcance recortado en el descubrimiento. No es un prototipo: es código en producción, con deploy y monitorización.
• ¿Se puede trabajar junto con mi equipo interno?+

  Sí, y es el formato que mejor funciona. El equipo interno entra en el mismo repositorio y en el mismo ritual; la transferencia de conocimiento ocurre durante el proyecto, no en una reunión al final.
• ¿De quién es el código al final?+

  Tuyo. Repositorio, cuentas de nube y dominios quedan a nombre de tu empresa desde el primer día.

Ingeniería de Plataforma

Deploy que se atasca, incidente que nadie sabe quién atiende y una factura de nube creciendo más rápido que el producto.

Medir antes de tocar. Primero los números — tiempo de deploy, tasa de fallo, tiempo de recuperación, coste por entorno — después los cambios que mueven esos números, uno a uno, empezando por los que reducen riesgo sin tocar el producto.

• 01Pipeline de deploy automatizado, igual en todos los entornos
• 02Infraestructura como código, versionada
• 03Paneles y alertas con dueño definido y acción escrita
• 04Runbook de incidente y rollback ensayado
• 05Test de restore de backup corriendo en el calendario
• 06Revisión de coste por entorno y por servicio

• ¿Se puede hacer esto sin parar las entregas?+

  Sí. El orden es siempre el mismo: primero lo que reduce riesgo sin tocar el producto — backup probado, alerta con dueño, rollback ensayado —, después la infraestructura de debajo.
• ¿Se quedan operando la plataforma después?+

  Solo si tú quieres. Lo estándar es entregar con runbook y formar al equipo. El soporte continuo es un contrato aparte, nunca una dependencia creada a propósito.
• ¿En cuánto tiempo aparece la primera ganancia?+

  Las dos primeras semanas normalmente ya devuelven un test de restore funcionando y las alertas con dueño — que es donde vive el riesgo de verdad.

• 45 minutos, USD 460 millones: cuando falta gobernanza de tecnología20 sept 2026

Sistemas de IA

La demo encanta a la dirección y se desarma en la primera semana de producción: latencia fuera de lo acordado, factura de tokens sin explicación y respuestas que nadie puede verificar.

Tratar la IA como sistema, no como magia: presupuesto de latencia por etapa, contexto recuperado con la fuente citada, evaluación contra preguntas reales y coste medido por funcionalidad — no por impresión.

• 01Ingesta, chunking y embedding con reindexación incremental
• 02Búsqueda vectorial con filtro y recall medido
• 03Conjunto de evaluación con preguntas reales y nota por versión
• 04Panel de coste por funcionalidad, con cache verificada
• 05Camino de fallback determinista para cuando el modelo se caiga

• ¿Mis datos van a entrenar el modelo?+

  No. Los documentos se quedan en tu base de datos y las llamadas van por contratos que no usan tu contenido para entrenamiento. Es una decisión de arquitectura y de contrato, y queda escrita en el proyecto.
• ¿Cuánto cuesta mantener esto al mes?+

  Depende del volumen, pero se vuelve previsible cuando se mide. Indexar un corpus de unos cientos de fragmentos cuesta céntimos; el gasto real está en las llamadas de generación — y es ahí donde la cache de prompt y el tamaño de contexto bajan la factura.
• ¿Se puede correr con modelo abierto, en mi nube?+

  Sí. La arquitectura separa búsqueda de generación, así que cambiar el modelo pasa a ser una decisión de coste y calidad, no una reescritura.

• RAG en producción: qué cambia cuando existe un SLA20 sept 2026

Modernización de Legado

Un sistema que nadie quiere tocar, que una sola persona entiende de verdad, y que sostiene todo el resto del negocio.

Nada de reescrituras de dos años. Mapear lo que existe, acorralar el comportamiento actual con tests y migrar por tramos — con el sistema antiguo en producción hasta el último de ellos, y ruta de vuelta en cada etapa.

• 01Mapa de dependencias, riesgos y puntos de fallo único
• 02Tests de caracterización sobre el comportamiento actual
• 03Plan de tramos, con orden y criterio de corte
• 04Migración incremental, con ruta de vuelta en cada etapa
• 05Documentación viva de lo que migró y de lo que quedó

• ¿Hay que parar la operación?+

  No. Cada tramo entra con el sistema antiguo aún en pie; el cambio solo ocurre cuando el tramo nuevo ya ha demostrado que responde igual.
• ¿Y si no existe ninguna documentación?+

  Es el caso más común. Los tests de caracterización se convierten en la documentación: registran lo que el sistema hace hoy, incluido lo que hace mal y de lo que el negocio ya depende.
• ¿Cuánto tiempo lleva?+

  La auditoría y el plan de tramos llevan de dos a tres semanas. La migración se mide en tramos entregados, no en un plazo único — y puedes parar entre uno y otro.