A mis amigos les digo, medio en broma, que tener estas herramientas es como tener un genio de la lámpara: le pides lo que quieras y te lo construye. Me gusta la imagen, pero tiene una trampa es muy conocida. El genio no sirve de nada si no sabes qué y cómo pedir.
Y resulta que saber qué pedir —qué construir, para quién, y por qué vale la pena— es justamente lo que llevo veintidós años haciendo.
Estudié ingeniería, he trabajado en diseño y desarrollo web y UX y hace unos 8 años, facilito talleres de varias metodologías. Lo que nunca fui es desarrollador. Durante casi toda mi carrera, esa frontera definió con bastante claridad lo que podía construir solo y lo que no. Tenía ideas, prototipos, hasta proyectos validados. Pero entre la idea y el producto siempre se interponía lo mismo: un equipo de desarrollo, meses de trabajo, un presupuesto que no tenía.
Esa frontera se movió. Y este año, por primera vez, pasé de la idea al producto sin contratar a nadie. Estas son cuatro de esas historias (otros proyectos más complejos los iré comentando más adelante).
1) Monitorica: el proyecto que rescaté del cajón
En 2014 tuve una idea que me obsesionó: una herramienta para analizar y monitorear sitios web durante toda su vida útil. La llamé Monitorica. En 2015 la llevé al Web Summit de Dublín, el último que se hizo en esa ciudad, como una startup en fase alpha. Volví con feedback, con sugerencias y con gente que quería ser beta tester. Interés real.
Y no pasó nada. Para construirla necesitaba un equipo que empecé a construir con colegas profesionales, pero no logramos avanzar (lecciones aprendidas para el emprendedor). Busqué fondos, y en algún momento dejé de insistir. Guardé Monitorica en el cajón sabiendo que era un buen proyecto y que algún día lo rescataría.
¿Por qué Monitorica? En un mundo digital donde los sitios web de alta calidad son fundamentales para ofrecer una excelente experiencia de usuario es importante probar cada proyecto web que se lanza y, posteriormente, monitorear y medir los aspectos clave para corregirlos y mejorarlos. Así nació Monitorica: una herramienta web que combina la potencia del monitoreo online y las pruebas en tiempo real en un panel de control sencillo y potente.
Diez años después la saqué. Me senté con Claude Code, y reconstruí un MVP funcional en menos de 3 semanas (pudieron ser menos). Tenía a favor todo el background del proyecto: la lógica, los tipos de monitores, la arquitectura que ya había pensado. Lo que en 2015 era una pared infranqueable, esta vez fue una conversación. Monitorica está viva, y por primera vez tiene la posibilidad real de convertirse en el servicio para el que la imaginé.
2) La herramienta que construí para mí mismo
Hace poco cambié una parte crucial del branding que espero me represente por un buen tiempo y una de las frases clave es la de «Estructuro Creatividad«. Solamente esas dos palabras les pueden dar una idea de qué perfil me caracteriza: el del orden y la estructura, el que saca la tabla de Excel para ordenar las ideas… Esto me hecho un fan absoluto de los paneles de control (Dashboards).
No puedo decir que desde siempre quise tener un Dashboard para organizar mi vida productiva, pero está muy cerca de eso. Intenté con varios CRM’s y gestionadores de proyectos, todos con features interesantes y muy útiles (sin duda), pero dos cosas me hicieron descartarlos uno por uno: El que estás atado a un servicio de terceros (pagado en su mayoría) y que la personalización llega hasta cierto punto.
En ese caso, la solución obvia es: crea uno tú mismo. Eso hace menos de un año habría sido, una vez más, poco viable para mi. Hasta que llegó Claude Code a mis manos.
El primer proyecto que construí con Claude no fue para vender. Fue para mapear, organizar y centralizar lo que ya tenía bastante bien estructurado en las carpetas de mi compu (y en Google Drive y Dropbox).
Construí un skill que, a través de Claude Cowork (esto no funciona en una ventana de chat normal) leyera sistemáticamente las carpetas donde estan mis talleres y charlas que he venido facilitando desde hace años para y extrajera todo lo que había adentro: el contenido de cada sesión, los valores, los resultados, retroalimentación, los tableros, etc. Casi una década de trabajo que estaba sentado en el disco se volvió una base de datos viva.
Sobre eso construí un dashboard que funciona como mi CRM. Cuando alguien solicita un taller, entra a un flujo donde, apoyado en skills y plugins personalizados que armé para mí, genero la propuesta, llevo la comunicación y cierro la negociación. Se conecta con Google Drive y con la base de datos de mi sitio web para recibir clientes directamente. Y tiene una capa pública que muestra mis talleres, con sus detalles y fotos, alimentada por el mismo contenido que cargo adentro. Una sola fuente, muchas salidas.
Es el asistente de operaciones que durante años habría querido contratar y que nunca tuvo sentido económico para una práctica de una sola persona.
3) El CRM para el cliente poco común y cómo se convirtió en un producto global
Este proyecto no estaba en ningún cajón. Nació justo cuando vi lo que se podía hacer con Claude Code. La posibilidad de construirlo yo mismo fue, literalmente, lo que hizo que la idea existiera.
El cliente más desafiante para el que he diseñado no fue un banco ni una startup. Fue Beatriz Benavides, especialista en medicina energética y mentora de vida, cuyo trabajo es profundamente abstracto: percibe procesos, potenciales, líneas de tiempo. Construirle una plataforma no era «meter clientes a un sistema». Era documentar sesiones cuyo contenido es intangible, catalogar servicios que no figuran en ningún manual e integrar herramientas propietarias de un instituto que no existen en ningún otro lado.
Esa traducción —tomar el mundo de una persona y volverlo una estructura digital que tenga sentido para ella— fue la parte más compleja, y fue puro diseño. Claude Code me dio la velocidad para construir en un par de semanas lo que antes habría exigido un equipo. Pero qué construir, cómo debía sentirse y qué lenguaje usar para que ella se sintiera en casa, eso fue oficio.
El resultado lo resume mejor ella:
Mi trabajo requiere el desarrollo y el uso de habilidades internas muy sensibles. La información que percibo y obtengo al servicio de mis clientes sobre su energía, sus procesos y sus potenciales es profundamente abstracta. Uno de mis mayores retos ha sido transmitir esa información de forma oportuna, estratégica y clara, y lograr que mis clientes sientan, incluso en un espacio online, que entran a un ambiente profesional, cuidado, ordenado y coherente con la profundidad del servicio que reciben.
A nivel personal, uno de mis mayores desafíos era organizar esta información y hacer seguimiento a mis clientes. Podía hacerlo de manera intuitiva, pero es un proceso complejo y multidimensional, y necesitaba una estructura amigable que pudiera sostenerlo en el tiempo. Como una persona altamente psíquica y sensible, muchas veces siento que tengo un pie más en el mundo abstracto y místico que en la sistematización de procesos. Sentarme frente a un Excel para incluir datos, reportar información, hacer seguimiento a mis ingresos o revisar mis estructuras me resultaba abrumador.
Esto me llevó a utilizar diferentes plataformas del mercado para hacer seguimiento a clientes, costos y gastos. Sin embargo, en mi caso particular, o tenía que usar demasiadas aplicaciones al mismo tiempo, o debía adaptarme a un método que me resultaba tedioso y poco natural.
Gracias a la asesoría de Michael, a su mirada abierta, empática y curiosa sobre la singularidad de mi espacio de servicio, y a su capacidad de creer en mí, ponerse en mi lugar y vislumbrar el potencial de mi trabajo al estar mejor estructurado, recibí el desarrollo de una plataforma y una estructura online extraordinaria para el manejo de mi negocio y de mi servicio.
Lo más valioso para mí es que no se trató solamente de desarrollar una página web funcional. Michael estructuró para mí una plataforma fácil de manejar, amigable y hecha desde adentro, con un lenguaje y mecanismos que tienen sentido para mí. Está hecha a mi medida y contempla no solo la funcionalidad, sino también mis necesidades como persona sensible, intuitiva y creativa. Es un ambiente digital amistoso, claro y nutridor.
Beatriz Benavides
Y algo que no vi venir: la plataforma le funcionó tan bien que me pidió convertirla en un producto para ofrecerlo al instituto donde trabaja. Lo dupliqué y lo rearmé como una versión multi usuario y multi idioma, lista para escalar, en cuestión de días.
Lo que nació a la medida de una persona está por volverse producto global.
4) Huertos urbanos: no toda idea tiene que ser una startup
El cuarto es el más pequeño, y por eso me gusta. Empezó como una investigación personal: cómo cultivar mis propios alimentos y avanzar hacia algo de autonomía alimentaria aquí en Guayaquil. Hace un par de meses, con ayuda de IA armé una guía basada en documentos reales sobre qué sembrar, cómo y cuándo según nuestro clima.
La guía se veía bastante útil, pero sinceramente no la había usado aún. Tomé su lógica, pensada primero para Guayaquil y luego ampliada a frutas y verduras de otras regiones del Ecuador, y la convertí en una app web con una versión móvil muy fácil de usar. La construí en muy poco tiempo.
No hizo falta que fuera una startup. Bastó con que fuera útil. La distancia entre «tengo una guía» y «tengo una herramienta que cualquiera puede usar» sucedió en menos de una semana.
Otra parte de este proyecto fue la marca, que también tuvo algo de ayuda de la IA. Allpita, el nombre que elegí, nace de la palabra allpa (tierra en kichwa) + diminutivo. Significa «tierrita»
Este producto está en línea y lo puedes probar. ¡Es gratuito por ahora! Está en beta, aun no implemento algunas funcionalidades, pero en su core, está totalmente funcional: https://michaelmuller.pro/huertoapp/
¿Así nomás?
Cuando cuento todo esto, la reacción más común es una ceja levantada: «¿entonces le pediste a una IA que te hiciera una app y ya?». No. Así nomás, no.
Ninguno de estos proyectos nació de un prompt de desarrollo. Nacieron de una conversación -a veces larga- sobre la necesidad real, el contexto y los detalles, con material de apoyo de por medio: PDFs, links, capturas, esquemas que yo mismo armé, cuyo resultado fue el prompt maestro que disparó todo el proceso de desarrollo. Es, en el fondo, el mismo trabajo de descubrimiento y estructura que llevo haciendo dos décadas, solo que ahora desemboca en un producto y no en un documento de requerimientos que le entrego a otro. La IA construye rápido, pero construye lo que tú entiendes y sabes pedir. El cuello de botella se movió del «cómo lo programo» al «qué tan claro lo tengo».
Algo adicional que aprendí en el camino, es a usar apoyos como el skills como «Superpowers»: «Es un popular plugin de código abierto y framework de metodología ágil para Claude Code. Ayuda a los agentes de programación a dejar de escribir código de forma precipitada y los obliga a planificar metódicamente.» Mindstudio.ai
Y aquí quiero ser honesto, porque este tema tiene una cara incómoda que prefiero mirar de frente.
A esta forma de construir se le puso nombre -«vibe coding«, lo bautizó Andrej Karpathy a inicios de 2025 – y con el nombre llegaron la fama y también el desprestigio. Parte de ese desprestigio es justo y hay data.
Un estudio de Veracode que analizó más de cien modelos en 80 tareas de programación encontró que cerca del 45% del código generado por IA introduce vulnerabilidades de seguridad, muchas de ellas dentro del OWASP Top 10. Un estudio de Stanford halló algo todavía más incómodo: quienes programan con asistencia de IA no solo producen código menos seguro, sino que se sienten más confiados de él. Esa brecha entre la confianza y la realidad es, para mí, el verdadero riesgo. Y no es teórico: a inicios de 2026, una app hecha en una de estas plataformas expuso los datos de más de 18.000 usuarios porque la IA generó consultas a la base de datos sin controles de acceso. Quien la publicó la armó en un fin de semana; la brecha tardó tres meses en descubrirse.
Hay incluso un par de datos de METR que me obligan a mirar esto con matiz. A mediados de 2025, en un experimento controlado, dieciséis desarrolladores experimentados tardaron 19% más en completar sus tareas usando IA… aun esperando ir 24% más rápido. La sensación de velocidad y la velocidad real no siempre coinciden. Pero lo honesto es contar el resto: METR repitió el estudio y para febrero de 2026 el panorama se había movido hacia una mejora modesta —del orden del 4% al 18% más rápido según el grupo, aunque ellos mismos advierten que el número es ruidoso y probablemente se queda corto—. ¿Y por qué tan difícil de medir? Porque para entonces tantos desarrolladores se negaban a trabajar sin IA que el experimento casi no se pudo correr. «Es como cruzar la ciudad a pie cuando ya te acostumbraste al Uber», dijo uno. En menos de un año, la herramienta pasó de estorbar a volverse indispensable —y ni los expertos logran medir bien cuánto—. METR.org
El error es plantearlo como «vibe coders contra desarrolladores», como si fuera un bando contra el otro. No lo es. Simon Willison, una de las voces más sensatas en esto, hace una distinción que me parece clave: si un modelo escribió cada línea de tu código, pero tú lo revisaste, lo probaste y lo entendiste, eso no es «vibe coding»; es usar la IA como un asistente muy rápido. A esa versión más disciplinada ya empiezan a llamarla «vibe engineering»: la velocidad de la IA junto a la disciplina de siempre -pruebas, revisión, entender lo que se despliega-.
Y ahí es donde espero ubicarme de a poco, con toda honestidad. Gracias al entorno donde trabajo, he podido entender que hay que revisar, probar, romper y corregir. Cuando el proyecto de Beatriz creció, me tocó meterme en debugging y aprender bastante más de lo que esperaba. En varios de estos proyectos implementé capas de seguridad, headers y controles de acceso, precisamente, porque sé que la IA optimiza para «que funcione», no para «que sea seguro».
Y esto aplica a los dos grupos, no solo a los que venimos del diseño. Programes como programes, hay cosas que hoy no son opcionales antes de poner algo en producción, entre ellas:
- No dejar secretos en el código. Claves de API y contraseñas van en variables de entorno, del lado del servidor, nunca escritas en los archivos.
- Validar en el backend. Lo que entra se valida en el servidor, no solo en el navegador.
- Auditar las dependencias. La IA a veces «alucina» librerías que no existen o mete paquetes con fallas conocidas.
Nada de esto es exclusivo de los desarrolladores de carrera. Es el precio de entrada para construir con responsabilidad, lo hagas con o sin título en sistemas.
Porque de eso se trata, en el fondo. La puerta que se abrió para los que no somos desarrolladores es enorme y real. Pero cruzarla bien no es cuestión de vibra. Es la misma pregunta de siempre -qué construyo, para quién, y qué responsabilidad asumo al ponerlo en el mundo- solo que ahora la puedo responder yo mismo, de principio a fin.
Varios tipos de proyecto, una misma lección
Si los miro juntos, estos cuatro caen en grupos distintos. Monitorica venía del cajón, un sueño viejo que por fin pude cumplir (y todavía tengo otros durmiendo ahí, pero esa historia es para otro día). El dashboard lo hice para mí. Beatriz y los huertos son ideas que ni siquiera existían hasta que vi que se podían construir.
Lo cual me devuelve al genio de la lámpara. La herramienta se volvió abundante y accesible para casi cualquiera. Lo escaso hoy no es el poder de construir, sino el criterio para saber qué construir y para quién. Entender a las personas, ver el problema real, decidir qué merece existir: ese trabajo sigue siendo de toda una vida. Y es, curiosamente, en lo que he venido trabajando todos estos años.
Por eso esta me entusiasma.
Si tú también tienes algo guardado —una idea que archivaste porque «necesitaba un equipo»— quizá valga la pena volver a mirarla. La pared que la detuvo puede que ya no esté.
¿Qué tienes tú en el cajón que hoy ya podrías construir?