90 Minutos al Día, Cero Excusas: Cómo el Vibe-Coding Lleva a tu Primer Millón
El solo-dev con 90 minutos de código al día construye mejor software que equipos con 8 horas. El framework Vibe-Coding Constraints convierte la restricción en ventaja.
Tienes 90 Minutos al Día para Codificar. Esa Es tu Mayor Ventaja Competitiva.
Crees que el solo-dev con hijos pequeños está en desventaja. Menos horas. Más interrupciones. Menos energía para mantener el foco.
*Te has equivocado de diagnóstico.*
La cultura startup ha normalizado las jornadas de catorce horas como señal de compromiso. El fundador que duerme en la oficina. El dev que hace push a las tres de la mañana. Código como medalla de sacrificio.
Pero los estudios sobre productividad en ingeniería de software lo llevan diciendo años: después de seis horas de trabajo cognitivo intenso, los retornos decrecen drásticamente. Las horas catorce a veinte no son productivas. Son residuo térmico de una cultura que confunde horas sentado con output real.
El solo-dev con un peque de seis meses no tiene ese problema. Porque no tiene elección.
Entre el biberón de las seis de la mañana y la siesta de las nueve, tienes exactamente noventa minutos. Y esos noventa minutos —protegidos como un bloque sagrado— valen más que ocho horas frente al monitor con Slack abierto, notificaciones de caliente y reuniones que podrían ser un email.
La restricción no es tu límite. Es tu filtro de calidad.
---
El Problema: El Tiempo Ilimitado Produce Código Peor
1. La sobreingeniería como subproducto del tiempo sobrante
El desarrollador sin hijos con ocho horas disponibles no tiene un incentivo natural para parar. Y cuando no hay presión externa, el cerebro busca entretenerse con lo que sabe hacer: abstraer, refactorizar, añadir patrones de diseño que nadie pidió.
Esta semana vi a un fundador soltero dedicar tres sprints a implementar una arquitectura hexagonal con DDD en un MVP que todavía no tenía un usuario pagando. Había hecho seis capas de abstracción para un CRUD de tres tablas.
El principio YAGNI —*You Ain't Gonna Need It*— es universalmente aceptado en arquitectura de software. En teoría. En la práctica, es el primer principio que se abandona cuando tienes tiempo de sobra.
❌ Dev sin restricciones: ocho horas → abstracciones prematuras → refactorización innecesaria → deuda técnica por sobreingeniería.
✅ Solo-dev con 90 min: tiempo justo → solo lo necesario → código que resuelve el problema real → deuda técnica mínima.
2. El estado de flujo es el activo, no las horas brutas
Cal Newport escribió Deep Work sobre esto. La psicología cognitiva muestra que el cerebro necesita entre quince y veinticinco minutos para alcanzar estado de flujo. Un dev con ocho horas disponibles pero interrumpido cada veinte minutos por Slack, una reunión de daily y la notificación de un CR en GitHub puede tener cero minutos de flujo real en toda la jornada.
El padre que protege sus noventa minutos como un bloque inviolable, ese sí alcanza flujo. Porque sabe que si pierde diez minutos, pierde el once por ciento de su jornada de codificación.
El resultado: tres bloques de flujo real de sesenta minutos cada uno a lo largo del día (mañana, siesta del peque, noche) producen más output que catorce horas fragmentadas.
3. El dato que nadie quiere ver
Los datos de más de cuatrocientas mil sesiones de codificación con asistentes de IA analizadas por Anthropic entre octubre de 2025 y abril de 2026 muestran algo claro: la calidad del output no se correlaciona con las horas brutas. Se correlaciona con la claridad del objetivo antes de empezar a escribir.
El solo-dev con noventa minutos no tiene tiempo para empezar a escribir sin saber qué va a construir. Planifica antes. Y esa planificación forzada es exactamente lo que los estudios señalan como predictor de código mantenible.
---
La Evidencia: Lo Que Aprendí Desde el Taller de Pintura
Cuatro años en España. Un taller de pintura donde paso cuatro horas al día. Un peque de seis meses. Y productos enviados: conversoriaecnae.es, gestoriascercademi.com, findemergencyplumber.com, Juridica Integral, Grot, Modulos-IRPF.
Cada uno de esos productos se construyó en bloques de noventa minutos.
No es romanticismo de la precariedad. Es ingeniería de restricciones aplicada al desarrollo de software.
Cuando tienes a tu hijo durmiendo en la habitación de al lado y sabes que se despertará en exactamente noventa minutos, cada línea de código pesa. Cada decisión de arquitectura se examina con un nivel de escrutinio que ningún code review formal puede igualar.
La pregunta que te haces antes de escribir cualquier función no es "¿esto queda bien?". Es:
"¿Resuelve esto un problema que un usuario pagaría por resolver hoy?"
Si la respuesta no es inmediatamente sí, no se escribe. Y ese filtro, aplicado durante meses, produce sistemas con menos deuda técnica que equipos que dedican semanas a abstracciones que nunca se usarán.
El mismo fenómeno explica por qué las startups con funding limitado producen mejor product-market fit que las über-capitalizadas: la restricción fuerza enfoque. No es romanticismo. Es física del desarrollo de software.
---
Análisis: Por Qué el Vibe-Coding es la Herramienta del Solo-Dev
El contexto importa más que las horas brutas
El término vibe-coding se ha popularizado para describir el uso intensivo de asistentes de IA (Claude Code, Cursor, Copilot) para generar código rápido, iterar con feedback inmediato y reducir el tiempo entre idea y software funcionando.
Pero la mayoría lo malinterpreta. Creen que vibe-coding es "escribir prompts y que la IA lo haga todo". Que es una forma de externalizar el pensamiento.
*El vibe-coding real no es eso.* El vibe-coding real es el arte de saber qué pedir. Y eso solo se aprende cuando cada prompt tiene un coste de oportunidad.
El solo-dev con noventa minutos no puede permitirse prompts vagos. No puede iterar diez veces sobre el mismo componente porque "total, tengo tiempo". Cada iteración cuesta minutos de la ventana de codificación.
El resultado: prompts más precisos, código más limpio, menos ciclos de feedback.
Deep Work vs. tiempo fragmentado
El dev sin hijos que trabaja desde casa con ocho horas disponibles suele caer en la trampa del trabajo fragmentado. Una reunión aquí, un Slack allá, un PR review, una respuesta a un cliente.
Al final del día, ha estado ocho horas "en modo trabajo". Pero si midieras el tiempo real de codificación profunda, probablemente no llegaría a tres horas.
El solo-dev con hijos no puede fragmentar. Cuando tiene los noventa minutos, sabe que son sagrados. Sin Slack. Sin reuniones. Sin notificaciones. Solo el editor, el terminal, y el problema que resolver.
Ese tipo de sesión produce más output en noventa minutos que tres horas fragmentadas. Lo he medido en mis propios proyectos.
---
El Framework Vibe-Coding Constraints: Cómo Convertir 90 Minutos en Primer Millón
Aquí está el marco que he desarrollado enviando seis productos desde un taller de pintura. Lo llamo el Framework Vibe-Coding Constraints, y funciona así:
Paso 1 — Auditar los 90 minutos reales
La mayoría sobreestima su tiempo disponible. Crees que tienes dos horas. Mides una semana y descubres que tienes cuarenta y cinco minutos.
Usa un tracker de tiempo —Toggl, o un bloc de notas físico— durante siete días. Anota cada bloque de codificación ininterrumpida. Ni el móvil, ni el café, ni "dejarme caer por Twitter".
El número que obtengas es tu presupuesto real. Trabaja con él, no contra él.
Paso 2 — Aplicar el filtro de restricción
Antes de escribir cualquier función, hazte esta pregunta exacta:
"¿Resuelve esto un problema que un usuario pagaría por resolver hoy?"
Si la respuesta no es inmediata, no la escribes. Ni siquiera la añades al backlog. El backlog es una lista de deseos. Tu tiempo de codificación es tu capital.
Esta semana, antes de añadir una feature a gestoriascercademi.com, me pregunté eso. La respuesta fue "no". La función no existió. Y el producto sigue funcionando mejor sin ella.
Paso 3 — Batch propositivo (monotarea forzada)
No alternes entre código y contextos. Los noventa minutos deben ser monotarea. Preparar el contexto (issue, archivos, dependencias, el prompt que vas a usar) el día anterior, en sesiones separadas de baja energía.
Yo preparo los prompts y los ficheros que voy a tocar mientras tengo al peque en brazos. No puedo codificar con una mano, pero sí puedo leer issues y pensar en la solución. Cuando llegan los noventa minutos, solo ejecuto.
Paso 4 — La regla del commit único por sesión
Cada bloque de noventa minutos debe producir exactamente un commit completo y testeado.
Esto fuerza dos cosas que el solo-dev necesita desesperadamente:
1. Planificar antes de escribir — si sabes que solo tienes una oportunidad, piensas bien la solución.
2. No dejar código a medio terminar — el código a medias es deuda técnica con nombre propio.
Si en noventa minutos no produces una unidad de valor entregable, tu proceso está mal diseñado. No es falta de tiempo. Es falta de planificación.
Paso 5 — Medir output por minuto, no por hora
Reemplaza la métrica de "horas trabajadas" por "features entregadas por sesión".
Si trabajas ocho horas y entregas tres features parciales, tu productividad real es baja.
Si trabajas noventa minutos y entregas una feature completa y testeada, tu productividad es altísima.
La métrica correcta no es el tiempo invertido. Es el valor generado por unidad de tiempo de codificación.
---
Las objeciones que seguro te estás haciendo
"Tener hijos no es una estrategia de negocio"
Tienes razón. No lo es. El punto no es romantizar la precariedad ni sugerir que tener hijos te convierte en mejor desarrollador. El punto es que la restricción temporal externa funciona como mecanismo de calidad.
Da igual si la restricción viene de un hijo, de un trabajo que te ocupa ocho horas, de una mudanza, o de una decisión consciente de no trabajar más de dos horas al día. El mecanismo es el mismo: tiempo limitado fuerza decisiones óptimas.
"Yo sin hijos también soy disciplinado"
Me alegro. De verdad. Pero la disciplina voluntaria es frágil. Cuando tienes un mal día, cuando el proyecto no avanza, cuando el código se resiste, la disciplina se desmorona.
La restricción externa —solo noventa minutos y luego el peque se despierta— es un constraint duro. No depende de tu fuerza de voluntad. No negocia. No se rinde.
Eso, y no la virtud personal, es lo que fuerza decisiones óptimas incluso en los días malos. Y son precisamente los días malos los que separan los productos que se envían de los que se quedan en el repositorio.
---
La conclusión que cambia tu relación con el tiempo
El mayor error que cometen los solo-dev es pensar que su problema es la falta de horas.
No lo es.
Tu problema es que confundes tiempo disponible con tiempo productivo. Y mientras sigas midiendo tu éxito en horas sentado frente al monitor, seguirás perdiendo contra el dev que sabe que sus noventa minutos son más valiosos que tus ocho horas.
El vibe-coding hacia el primer millón no va de escribir más código. Va de escribir el código correcto en el tiempo que tienes. Y cuanto menos tiempo tienes, mejor código escribes.
Mi hija tiene seis meses. Se despierta tres veces por noche. Trabajo desde un taller de pintura. Y he enviado seis productos al mercado este año.
No a pesar de las restricciones. Gracias a ellas.
La próxima vez que tengas noventa minutos libres, no pienses en lo que no puedes hacer. Piensa en lo único que sí puedes hacer.
Y hazlo. Commit. Despliega. Envía.
Ese es el camino.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF