#Qué vas a encontrar aquí

• Bitácora CTO. Lo que pasa de verdad en la silla de CTO: decisiones de arquitectura, contrataciones, incidentes, roadmaps que cambian a mitad de trimestre y lo que haría distinto.
• Lanzamientos. Los productos que construyo o lidero, por qué existen y qué problema resuelven.
• Señales. Noticias del sector comentadas con una pregunta en mente: ¿qué significa esto para una startup o una pyme que tiene que decidir con poco equipo y poco tiempo?

#Para quién escribo

Para fundadores que tienen que tomar decisiones técnicas sin ser técnicos, para equipos de producto que crecen más rápido que su arquitectura y para otros CTOs que quieren comparar notas.

#Cómo lo voy a escribir

Corto, concreto y sin humo. Si hay una cifra, es una que puedo defender. Si algo salió mal, lo cuento. Y no voy a publicar nada confidencial de los clientes con los que trabajo: cuando hable de un caso, será con su permiso o lo bastante abstraído como para que no se reconozca.

Escribo en español y en inglés. Si algo de lo que publique te resulta útil, o no estás de acuerdo, escríbeme por LinkedIn o reserva una llamada: las mejores ideas para un post siempre salen de una conversación.

Eso es lo que hace CalendaVibe.

#Qué hace

• Enlaces de reserva conectados a Google Calendar y Outlook, para que la disponibilidad sea siempre la real.
• Enlaces de Google Meet creados en cada reserva, sin copiar y pegar nada.
• Pagos con Stripe, para cobrar las sesiones de pago en el momento de reservar.
• Equipos, para que una reserva caiga en quien esté libre y no en un único calendario saturado.

Y es gratis para empezar. No deberías necesitar presupuesto para dejar de mandar correos de "¿te va bien el martes a las 4?".

#Por qué otra herramienta de agenda

Porque la parte útil es pequeña y conocida, y el resto es política de precios. La mayoría de herramientas ponen detrás de un plan de pago justo lo que una pyme necesita el primer día (cobrar, un segundo miembro del equipo). Yo quería lo contrario: lo básico gratis y bien hecho.

#Cómo está construido

React en el front, Node.js y PostgreSQL detrás. Lo difícil de un producto así son las integraciones de calendario: zonas horarias, eventos recurrentes, permisos y proveedores que modelan la disponibilidad cada uno a su manera. Ahí se ha ido la mayor parte de la ingeniería.

#Pruébalo

Si recibes reservas, pruébalo esta semana con un enlace real y cuéntame qué echas en falta. Leo todos los mensajes.

El Ómnibus Digital sobre IA de la UE, el Reglamento (UE) 2026/1744, ya está en vigor y cambia el calendario de la Ley de IA. Según el resumen de Orrick y de otros despachos:

• Los sistemas de alto riesgo del Anexo III (selección de personal, scoring crediticio, educación y usos similares) tienen ahora hasta el 2 de diciembre de 2027, en lugar del 2 de agosto de 2026.
• La IA de alto riesgo integrada en productos regulados (Anexo I) pasa al 2 de agosto de 2028.
• Las obligaciones de transparencia del artículo 50, como avisar a las personas de que hablan con una IA, se aplican desde el 2 de agosto de 2026. Los sistemas que ya estaban en el mercado antes de esa fecha tienen hasta el 2 de diciembre de 2026 para marcar el contenido generado por IA.
• Las simplificaciones para pymes (documentación técnica más ligera, gestión de calidad proporcionada, acceso prioritario a sandboxes, topes de sanción más bajos) se amplían a una nueva categoría de "pequeña mediana capitalización": empresas de menos de 750 empleados y hasta 150 millones de euros de facturación.

#Por qué importa a startups y pymes

El retraso es una buena noticia, pero es un retraso, no una cancelación. Los requisitos son los mismos; solo han cambiado las fechas. Veo venir dos trampas:

1. "Tenemos hasta 2027" se convierte en "ya lo pensaremos en 2027". Si tu producto puntúa a personas, filtra CVs o decide sobre crédito, lo difícil no es el papeleo. Es la trazabilidad de los datos, el registro de decisiones y la supervisión humana, que hay que diseñar dentro del sistema. Añadirlo a un producto que lleva un año en producción sale mucho más caro que construirlo ahora.
2. Olvidar lo que ya se aplica. Si tienes un chatbot, un asistente de IA o cualquier cosa que genere contenido para usuarios, la transparencia ya es tu problema hoy, no en 2027.

#Qué haría este trimestre

• Haz un inventario. Apunta cada sitio donde tu producto usa IA y clasifícalo: prohibido, alto riesgo, solo transparencia o mínimo. Suele ser trabajo de una tarde y cambia la conversación.
• Resuelve ya lo barato de transparencia. Un aviso claro de "estás hablando con un asistente de IA" y etiquetar el contenido generado cuestan poco y ya son obligatorios.
• Si algo es de alto riesgo, diséñalo en el próximo roadmap. Registro de entradas y decisiones, posibilidad de que una persona corrija la decisión y documentación de tus datos de entrenamiento y evaluación. Trátalo como arquitectura, no como cumplimiento normativo.
• Comprueba si eres pyme o pequeña mediana capitalización. El régimen simplificado es dinero ahorrado de verdad.

El tiempo extra solo sirve si lo usas para construir el sistema que vas a necesitar igualmente.

Esta es la lectura de un CTO a partir de resúmenes públicos, no asesoramiento legal. Para tu caso concreto, habla con un abogado especializado en la Ley de IA.

#Cuatro opciones, cuatro trabajos distintos

• Un desarrollador sénior escribe y entrega código. Ideal cuando el producto está claro y el riesgo es de ejecución.
• Una agencia o freelancers construyen un alcance definido. Ideal cuando sabes exactamente qué construir y alguien de dentro puede juzgar el resultado.
• Un CTO fraccional se encarga de la estrategia técnica y de las grandes decisiones unos días al mes: arquitectura, proveedores, contratación, roadmap. Ideal cuando las decisiones son de alto impacto pero todavía no llenan un puesto a tiempo completo.
• Un CTO a tiempo completo hace todo lo anterior cada día y además construye y dirige el equipo. Necesario cuando la tecnología es el negocio y el equipo es lo bastante grande para necesitar liderazgo diario.

#Señales de que necesitas liderazgo técnico sénior ya

• Vas a tomar una decisión cara de revertir: reescribir la plataforma, migrar a la nube, elegir un proveedor clave, contratar a tus primeros ingenieros.
• Tus desarrolladores o tu agencia toman decisiones de arquitectura por inercia y nadie del lado de negocio sabe si son buenas.
• La entrega se ha ralentizado y nadie sabe explicar por qué con palabras sencillas.
• Inversores, un cliente grande o un auditor empiezan a hacer preguntas de due diligence técnica.
• Los costes de nube o de proveedores crecen más rápido que los ingresos.

#Señales de que un CTO fraccional es suficiente

• Las grandes decisiones llegan por oleadas (un lanzamiento, una migración, una ronda), no a diario.
• Tienes, o vas a tener pronto, a alguien que ejecuta: un desarrollador líder, un equipo pequeño o un partner.
• Todavía no puedes justificar el salario de un directivo, o no quieres contratarlo antes de saber qué necesita de verdad el puesto.

#Señales de que necesitas un CTO a tiempo completo

• La tecnología es tu producto principal y tu diferencial, no una función de apoyo.
• El equipo de ingeniería es lo bastante grande para necesitar liderazgo diario, planes de carrera y contratar a ritmo constante.
• Las decisiones técnicas son diarias y esperar unos días por una respuesta sale caro.

Un buen encargo fraccional muchas veces termina justo ahí: con la arquitectura en orden, el equipo contratado y el perfil del CTO a tiempo completo que necesitas por escrito.

#Una prueba sencilla

Escribe las cinco decisiones técnicas más importantes que vas a tomar en los próximos seis meses. Si no puedes escribir la lista, o no sabes quién tomará cada una, necesitas ayuda con el liderazgo técnico, tenga la forma que tenga.

#Semana 1: escuchar antes de tocar nada

• Fundadores y dirección: hacia dónde va el negocio en los próximos 12 meses y qué problema técnico les quita el sueño.
• El equipo, uno a uno: qué les frena, qué arreglarían primero, qué les da miedo tocar.
• La visión del cliente: los tickets de soporte más repetidos y las quejas que escucha el equipo comercial. Te dicen dónde duele de verdad la calidad.

Resultado: un resumen de una página con objetivos, problemas y restricciones, compartido con todas las personas con las que hablé.

#Semana 2: la auditoría técnica

• Arquitectura: cómo se comunican las piezas principales, dónde viven los datos, qué es un punto único de fallo.
• Código y entrega: cómo llega un cambio del portátil a producción, cuánto tarda y cada cuánto se rompe.
• Nube y costes: qué corre dónde, quién tiene acceso y cuánto cuesta cada parte.
• Proveedores y contratos: de qué dependes y lo difícil que sería salir.
• Seguridad básica: secretos, copias de seguridad, accesos y si alguien ha restaurado alguna vez un backup.

No estoy poniendo nota al equipo. La mayoría de problemas que encuentro son decisiones razonables que sobrevivieron a su contexto.

#Semana 3: el roadmap

Cada hallazgo va a uno de tres grupos:

1. Arreglar ya: riesgos que pueden hacer daño al negocio pronto (pérdida de datos, agujeros de seguridad, un proceso de release frágil).
2. Construir después: los cambios que desbloquean el roadmap de producto.
3. Dejar como está: cosas que parecen feas pero que hoy no compensan. Decirlo en voz alta es la mitad del valor.

Cada punto lleva un responsable, una estimación de esfuerzo y el resultado de negocio al que sirve. Si no puedo ligar un punto a un resultado, no entra en el roadmap.

#Semana 4: empezar a ejecutar, juntos

• Elegir una o dos victorias rápidas que el equipo pueda entregar en días, para generar confianza en el plan.
• Acordar el ritmo de trabajo: cuándo estoy disponible, cómo se toman y se documentan las decisiones, qué se revisa.
• Arrancar el primer cambio estructural con las manos en el código, junto al equipo.

#El objetivo

Desde el primer día, el objetivo es un equipo que no dependa de mí. Cada decisión queda por escrito, cada estándar se automatiza cuando se puede y cada contratación sube el listón. Si al cabo de un año la empresa todavía me necesita de la misma forma, no he hecho bien el trabajo.

#Los microservicios son una herramienta organizativa

Su gran ventaja es que muchos equipos puedan desplegar de forma independiente sin pisarse. Si tienes un solo equipo de cinco personas, no tienes ese problema. Lo que sí te llevas es el coste: llamadas de red en lugar de llamadas a funciones, transacciones distribuidas, más infraestructura, más pipelines, depuración más difícil y más superficie de guardias.

Para un equipo pequeño que todavía busca encaje producto-mercado, ese coste se paga en la única moneda que no se puede permitir: la velocidad de cambio.

#Qué significa "modular" en la práctica

Un monolito se convierte en un lío cuando cualquier cosa puede llamar a cualquier cosa. Un monolito modular pone fronteras desde el primer día:

• Módulos por capacidad de negocio (facturación, catálogo, usuarios), no por capa técnica.
• Cada módulo es dueño de sus datos. Los demás no leen sus tablas; llaman a su interfaz pública.
• Interfaces públicas explícitas. Lo que no se exporta es privado, y una regla de lint o un test de arquitectura lo hace cumplir.
• Eventos internos para los efectos secundarios. "Pedido pagado" se publica dentro del proceso y quien lo necesite se suscribe. El día que eso pase a ser un mensaje en un broker, el código apenas cambia.

#Las señales de que toca sacar un módulo

• Un módulo necesita escalar de forma muy distinta al resto (un proceso en segundo plano pesado, una API con picos).
• Varios equipos se bloquean con los despliegues de los demás en el mismo código.
• Un módulo tiene requisitos distintos de disponibilidad, seguridad o cumplimiento normativo.
• Desplegar es lento o arriesgado por el tamaño del conjunto, y los builds modulares ya no ayudan.

Ninguna de ellas es "estamos en 2026 y las empresas serias usan microservicios".

#Cómo separar sin reescribir

Cuando un módulo se gana su propio servicio, las fronteras ya existen: es dueño de sus datos, tiene una interfaz pública y se comunica por eventos. Extraerlo es mover código y cambiar llamadas internas por llamadas de red, no un rediseño de seis meses. Ese es el sentido de empezar modular: tomar la decisión cara más tarde, cuando tienes la información para tomarla bien.

#Qué hace

Closevibe automatiza las conversaciones de venta y atención al cliente de negocios de e-commerce en los canales que sus clientes ya usan: WhatsApp, Instagram, Messenger y email. Responde con el conocimiento de la propia tienda, detecta qué quiere el cliente y mantiene la conversación en tiempo real.

Puedes verlo funcionando en esta web: el asistente de chat de la esquina funciona con Closevibe.

#Cómo está construido

Diseñé la arquitectura de la plataforma desde cero. Las piezas que más importan:

• Multi-tenant desde el primer día. Los datos, el conocimiento y las conversaciones de cada tienda están aislados.
• Agentes basados en RAG. Las respuestas se apoyan en el contenido de cada negocio, recuperado con búsqueda vectorial semántica sobre PostgreSQL con pgvector, en lugar de depender de lo que un modelo recuerde.
• Detección de intención y orquestación en tiempo real, para que el sistema sepa si tiene delante una pregunta de preventa, un problema con un pedido o algo que debe pasar a una persona.
• Integraciones de canal a través de las APIs de Meta Business (WhatsApp, Instagram, Messenger) y email.
• El stack: Python y FastAPI, React, PostgreSQL con pgvector, Docker en GCP y Railway.

#Qué he aprendido construyéndolo

El modelo es la parte fácil. Lo difícil es lo aburrido: meter el contexto adecuado en cada respuesta, saber cuándo no responder, pasar la conversación a una persona sin fricción y conseguir que todos los canales se comporten igual aunque cada API tenga sus reglas. Ahí se va la mayor parte de nuestro tiempo de ingeniería, y es lo que separa una demo de algo a lo que una tienda confía sus clientes.

#Pruébalo

Si vendes online y tu equipo pasa el día respondiendo las mismas preguntas, échale un vistazo.