Aprendí a programar para dejar de recomendar cosas que otros construían.
Quién soy
Llevo 20 años enseñando innovación y estrategia en escuelas de negocio internacionales y universidades públicas de referencia en Barcelona, y 25 dirigiendo proyectos de marketing y transformación digital — los últimos como Marketing Project Manager en una empresa de innovación de la industria 4.0.
Eso me enseñó a leer una organización: dónde está el cuello de botella real, qué se va a adoptar de verdad y qué se va a quedar en un cajón, cómo explicárselo a quien toma la decisión sin tecnicismos. Eso no se aprende programando. Se aprende dando clase veinte años y sentándote en la sala donde se decide qué proyecto de transformación digital sigue adelante y cuál se cancela.
Lo que no tenía, hasta 2025, era la capacidad de construir yo mismo lo que recomendaba. Así que me puse a aprender a programar en serio, no por encima.
Hoy hago las dos cosas a la vez: pienso la estrategia y construyo la herramienta — la misma persona en las dos partes, sin traspaso a un equipo técnico en medio, sin que la versión que se construye se parezca cada vez menos a la que se decidió en la reunión inicial. Es una combinación poco habitual: quien construye rápido casi nunca ha pasado veinte años entendiendo cómo decide una organización; quien entiende eso, casi nunca construye.
Lo que pasó después
En menos de un año pasé de no saber escribir una línea de Python a tener dos sistemas propios funcionando en producción: un backend con aislamiento de datos real a nivel de base de datos, procesamiento de archivos, autenticación, despliegue en un servidor europeo y dominio propio.
No lo cuento como hazaña personal. Lo cuento porque cambia lo que puedo ofrecerte: veinte años de saber qué preguntar y qué priorizar, aplicados con las herramientas de desarrollo de 2026, sin arrastrar la forma en que se construía software hace una década. Eso significa que lo que a una consultora clásica le lleva seis meses y un equipo de cuatro personas — descubrimiento, propuesta, traspaso a desarrollo, gestión de proyecto — yo lo hago en semanas, solo, porque no hay traspaso: la misma persona que entendió el problema es la que escribe el código.
Por qué construyo en vez de asesorar
El mercado está lleno de gente — yo incluido, durante años — que vende un diagnóstico de IA, una hoja de ruta a noventa días y un informe con recomendaciones. He escrito varios de esos informes. La mayoría acaban en un cajón, no porque estuvieran mal, sino porque entre la recomendación y la herramienta funcionando hay una distancia que casi nadie cruza.
Lo que casi nadie hace es sentarse y construir la cosa.
Mi apuesta es que a una empresa mediana no le hace falta otra estrategia de IA. Le hace falta una herramienta concreta que resuelva un problema concreto, funcionando, con su gente usándola — decidida y construida por la misma persona, en semanas, no meses. Y a partir de ahí, decidir lo siguiente con datos reales en la mano, no con diapositivas.
Cómo trabajo
-
Pienso y construyo a la vez. Decido alcance y arquitectura mientras construyo, con el mismo criterio que aplicaba dirigiendo proyectos de transformación digital — no planificación por un lado y ejecución por otro, con todo lo que se pierde en ese traspaso.
-
Empiezo pequeño, siempre. Un departamento, un proceso, un conjunto de documentos. Nunca "transformación total". Si el piloto no demuestra valor, se para — y es mucho mejor descubrirlo en tres semanas que en nueve meses.
-
Precio cerrado, alcance cerrado. Sabes lo que cuesta antes de empezar. No cobro por horas.
-
Sin permanencia. El mantenimiento mensual se cancela cuando quieras. Si sigues, es porque te sirve, no porque firmaste algo.
-
Te lo explico. Trabajo con equipos que no son técnicos. Parte del encargo es que entendáis qué se ha construido, qué límites tiene y qué pasa con vuestros datos. Veinte años dando clase sirven para algo.
-
Tus datos, donde deban estar. Por defecto trabajo con infraestructura europea. Cuando la documentación es sensible, se puede desplegar dentro de vuestra propia red. No es un extra: es una decisión de arquitectura desde el primer día.
Lo que también construyo para mí
LowOrbits no es solo servicio. También construyo mis propios productos, con las mismas herramientas y la misma metodología que aplico en los encargos.
Krakencast es el primero: una plataforma de canales de audio privados para organizaciones y universidades. Informes, comunicados o clases que se escuchan en lugar de leerse, y solo por quien tiene permiso.
Esto no es un hobby paralelo. Es la razón por la que sé lo que cuesta de verdad mantener un sistema en producción, y no solo entregarlo y desaparecer — algo que muy pocos consultores de IA pueden decir con evidencia detrás.
Lo que ya no hago
Durante años trabajé en marketing y dirección estratégica, y podría seguir vendiendo eso. He decidido no hacerlo.
No cojo retainers de marketing ni encargos de contenido. No es que no sepa — es que dejaron de interesarme, y prefiero decirlo en voz alta antes que aceptarlos a medias.
Lo que sí conservo de esa etapa es saber traducir entre negocio y tecnología. Que es, francamente, donde se cae la mayoría de proyectos de IA — no en el modelo, sino en la distancia entre quien decide y quien construye.
Hablemos
Si tienes un problema que crees que se resuelve construyendo algo, cuéntamelo. Media hora, sin presentación comercial y sin coste. Si puedo ayudarte, te digo cómo y cuánto, con un alcance y un precio cerrados antes de empezar. Si no soy la persona adecuada, te digo qué buscarías tú en mi lugar — no te voy a hacer perder el tiempo para cerrar una venta que no te conviene.
LowOrbits S.L.U. Barcelona