Cuando me toca trabajar gratis durante mis vacaciones… para mi mujer 😄

Hay clientes con los que se negocian un presupuesto, un calendario y un alcance. Y luego están los otros. Los que saben exactamente dónde vives, conocen tus vacaciones y pueden explicarte tranquilamente, mientras estás de descanso, que «solo es una web pequeña». En mi caso, ese cliente especialmente exigente era mi mujer. 😄

Durante mis vacaciones de verano, Eva quería lanzar una web para desarrollar su actividad de fisioterapia y ofrecer actividades físicas adaptadas por videoconferencia. La petición inicial parecía casi relajante: unas cuantas páginas para presentar su actividad, un formulario de contacto y una página para explicar las clases online.

En otras palabras: una pequeña web escaparate. El tipo de proyecto que un desarrollador acepta pensando que le dedicará algunas tardes tranquilas entre dos días de vacaciones.

Por supuesto, no ocurrió absolutamente nada de eso.

01El cliente más peligroso: el que vive contigo

Yo pensaba que, después de todos estos años, Eva había entendido algo fundamental de mi trabajo: cuando pido una expresión de necesidades completa, no es solo para molestar al cliente con documentos y reuniones.

Una necesidad incompleta no desaparece porque empieces a programar. Simplemente vuelve más tarde, normalmente en el peor momento, cuando las decisiones técnicas ya están tomadas y cada «pequeña funcionalidad adicional» empieza a mover otras tres.

El escenario fue, por tanto, completamente clásico: «solo hay que presentar mi actividad», después «estaría bien que la gente pudiera reservar», luego «entonces también tiene que poder pagar», después «seguramente necesita una cuenta» y finalmente «¿y yo cómo gestiono las clases?».

Unas cuantas iteraciones más tarde, la pequeña web escaparate había decidido tranquilamente convertirse en una aplicación.

02De web escaparate a verdadera aplicación de negocio

A medida que fuimos definiendo el proyecto, el alcance real de Mumkine.fr se volvió mucho más ambicioso.

El proyecto incluye ahora varias piezas:

• Sitio público: presentación de la actividad, acompañamientos, zonas de intervención y actividades online.
• Formulario de contacto: para facilitar el primer contacto en el recorrido de fisioterapia.
• Área de usuario: autenticación y acceso a la información necesaria para las actividades ofrecidas.
• Calendario: publicación y consulta de las sesiones disponibles.
• Reserva online: inscripción a una sesión con gestión de plazas y del recorrido del usuario.
• Pago: integración con Stripe para las actividades correspondientes.
• Administración: gestión de sesiones, usuarios, contenidos y operaciones del día a día.
• Correos transaccionales: centralizados en una infraestructura mailcow que ya controlo.
• Blog: publicación de contenidos prácticos relacionados con el proyecto y la actividad.

El sitio público distingue además claramente dos recorridos: por un lado la fisioterapia perinatal en Yvelines y, por otro, las actividades físicas adaptadas accesibles online.

Puede parecer un detalle, pero es importante. Cuando una aplicación empieza a gestionar varias actividades, conviene evitar construir un gigantesco túnel idéntico para todo el mundo. Las reglas de negocio, los pagos y la información solicitada no son necesariamente los mismos.

03La paradoja: usar IA para definir un proyecto desarrollado con IA

Aquí es donde el proyecto se vuelve interesante: utilizamos inteligencia artificial en dos niveles completamente diferentes.

El primer nivel no fue el desarrollo. Fue la definición funcional.

Antes de pedir a una IA que genere archivos, rutas, una base de datos o una interfaz, todavía hay que saber qué se quiere construir realmente.

Ese es precisamente el problema que encuentro a menudo con el vibe coding: la herramienta sabe producir código extremadamente rápido, pero si cambias de dirección constantemente también puede producir, extremadamente rápido, varias versiones distintas de una mala arquitectura.

04Léopold para transformar ideas en requisitos utilizables

Para poner un poco de orden en las ideas de Eva —y de paso salvar lo que quedaba de mis vacaciones— utilizó Léopold.

Léopold es un asistente AMOA de análisis y definición funcional que desarrollo junto con Jean-Francis Ochs. Su objetivo es partir de una necesidad todavía poco definida, hacer las preguntas necesarias, conservar las decisiones y producir entregables realmente utilizables.

Lo que me interesaba no era obtener un enorme documento de especificaciones que nadie leería. Quería recuperar suficiente información estructurada para responder rápidamente a preguntas concretas: actores, recorridos, autenticación, datos persistentes, administración, pagos, correos, cancelaciones y reglas de negocio.

Léopold puede producir síntesis de alcance, especificaciones, estudios detallados, modelos de datos, propuestas UX y una base de contrato OpenAPI. Gracias a las exportaciones, pude reutilizar el resultado directamente como contexto para el desarrollo.

Y probablemente esa sea la parte más importante de esta historia: la IA no eliminó el análisis funcional. Lo hizo todavía más útil.

05Una arquitectura deliberadamente fácil de desplegar

Una vez suficientemente estabilizada la necesidad, tomé una decisión simple: quería que la puesta en producción fuese casi aburrida.

Nada de quince componentes que instalar manualmente. Nada de una documentación de despliegue interminable. Nada de una máquina en la que haya que recordar que alguien modificó un archivo a mano seis meses antes.

La aplicación está pensada alrededor de un despliegue Docker compacto, con la persistencia necesaria en un volumen para que las copias de seguridad, las actualizaciones y los nuevos despliegues sean mucho más previsibles.

Esta decisión no elimina los temas clásicos: variables de entorno, secretos, copias de seguridad, migraciones, logs, monitorización y rollback siguen siendo necesarios. Pero para un proyecto de este tamaño prefiero controlar una unidad de despliegue coherente antes que multiplicar dependencias externas sin motivo.

06No olvidar el correo electrónico

Hay una funcionalidad que casi siempre se subestima en un proyecto web: el correo electrónico.

Creación de cuenta, reserva, confirmación, información práctica, cancelación, recuperación de contraseña, mensajes administrativos… la «pequeña web» empieza muy rápido a enviar muchos mensajes.

Por eso reutilicé mi infraestructura mailcow. mailcow es una suite de correo open source basada en Docker que agrupa, entre otros, Postfix, Dovecot, Rspamd y SOGo.

Para mí, la principal ventaja es no tener que reinventar una estrategia de correo distinta para cada nuevo proyecto. Cuando una pieza ya es conocida, monitorizada y respaldada, reutilizarla suele ser mucho más sensato que reconstruir toda una infraestructura.

07Stripe, MCP y una enorme ganancia de tiempo

La parte de pago es probablemente la que mejor ilustra el cambio de productividad que aportan las herramientas actuales.

Elegimos Stripe.

Una precisión importante sobre el IVA: el tratamiento depende de la naturaleza exacta de la prestación. Los cuidados realizados por un fisioterapeuta dentro del marco regulado de su profesión pueden beneficiarse de una exención, pero eso no significa automáticamente que toda actividad propuesta por un fisioterapeuta tenga el mismo tratamiento fiscal. Por tanto, debe analizarse actividad por actividad.

Lo que más me interesó técnicamente fue el servidor MCP oficial de Stripe. MCP —Model Context Protocol— permite a un agente o a un entorno compatible acceder a herramientas expuestas explícitamente por un servicio.

Stripe ofrece actualmente un servidor MCP que permite, entre otras cosas, buscar en su documentación e interactuar con una gran parte de su API. En mi caso, lo conecté a mi entorno Codex.

Obviamente, no pretendo afirmar que cuatro días de trabajo se conviertan siempre en dos horas. Depende totalmente del proyecto. Pero en esta integración concreta, la ganancia de tiempo fue espectacular.

Una gran parte del tiempo ahorrado corresponde a lo que antes perdíamos navegando por la documentación, comprobando el nombre de un parámetro, buscando de nuevo un método, creando un objeto de prueba o intentando comprender un error de API.

08¿Por qué no utilizar simplemente un CMS y plugins?

Seamos claros: Mumkine podría haberse desarrollado perfectamente con otras tecnologías.

WordPress, un constructor de sitios, una herramienta especializada de reservas, un plugin de pago y varios servicios SaaS probablemente habrían permitido llegar a un resultado funcional.

No tengo nada contra esas soluciones. A menudo son la mejor elección cuando la necesidad encaja exactamente con su funcionamiento.

El problema aparece cuando los requisitos empiezan a desviarse ligeramente del camino previsto por cada módulo. Instalamos un plugin de reservas, después un módulo de pago, luego una extensión para cambiar una regla, otra para conectar las cuentas, un hook, algo de CSS… y terminamos con una solución «sin desarrollo» que nadie comprende realmente en su conjunto.

El desarrollo asistido por IA cambia el equilibrio económico. Una funcionalidad específica que antes habría requerido un día puede, en algunos casos, producirse mucho más rápido. Esto vuelve a hacer pertinente el desarrollo a medida para determinados proyectos pequeños, siempre que sigamos siendo capaces de mantener lo que construimos.

09Lo que el vibe coding cambia realmente

Este proyecto me confirmó sobre todo una cosa: el vibe coding no sustituye realmente al desarrollador. Desplaza una parte de su trabajo.

El desarrollador no se convierte por tanto en un espectador. Al contrario: cuanto más rápido programa la IA, más rápido pueden implementarse también las malas decisiones.

Alguien tiene que seguir siendo capaz de decir: no, esta lógica no debe duplicarse; no, esa clave no se guarda en Git; no, un pago correcto en el navegador no basta; y a veces simplemente: no, no necesitamos esta funcionalidad.

10Lo que la IA todavía no hace por ti

Probablemente sea la parte menos sexy de un artículo sobre vibe coding, pero es indispensable.

Un agente puede ayudarte a escribir una integración con Stripe. No asume la responsabilidad de un pago incorrecto.

Puede generar un esquema de base de datos. No decide por ti qué datos es realmente legítimo conservar.

Puede producir un Dockerfile. No verifica automáticamente que tus copias de seguridad permitan realmente reiniciar el servicio el día que desaparezca el servidor.

Y puede producir una enorme cantidad de código limpio alrededor de una mala decisión funcional.

11¿Y mis vacaciones?

Volviendo al título del artículo, sí: yo estaba realmente de vacaciones.

Y sí: trabajé.

Y sí, el cliente todavía no ha pagado la factura. 😄

Pero este pequeño proyecto familiar terminó siendo un excelente laboratorio. Me permitió comprobar hasta dónde puede llegar hoy el desarrollo asistido por agentes cuando la necesidad está bien definida y se mantiene una arquitectura coherente.

La conclusión no es que cualquiera pueda crear en dos horas una aplicación de negocio completa explicando vagamente una idea a una IA.

La conclusión es mucho más interesante: una persona que conoce su actividad, una buena definición funcional y un desarrollador capaz de dirigir correctamente agentes pueden transformar hoy una idea en un producto realmente utilizable a una velocidad extraordinaria.

Ahorrar tiempo no significa necesariamente trabajar menos.

En mi caso, sobre todo permitió a mi mujer añadir muchas más funcionalidades antes de que terminaran mis vacaciones. 😂