El solo-dev con hijos tiene 90 minutos diarios para codificar. Esa es su ventaja más grande.
Vibe-coding para solo-dev con hijos. Cómo 90 minutos diarios entre crianza y trabajo producen código más sólido que 8 horas sin restricciones. Framework práctico de 3 ciclos.
El solo-dev con hijos tiene 90 minutos diarios para codificar. Esa es su ventaja más grande.
Crees que el solo-dev necesita más horas. Más disciplina formal. Sprints. OKRs. Standups diarios contigo mismo.
*Te has equivocado de diagnóstico.*
El solo-dev con niños pequeños tiene una ventaja que ningún founder en una startup backed por VC puede comprar: la incapacidad de sobreingeniería. Cuando solo tienes 90 minutos diarios para codificar entre siestas, el taller de pintura y la cena, cada línea que escribes tiene que contar.
Lo he vivido. Cuatro años en España. Un peque de 6 meses. El taller de pintura 4 horas al día. Y seis productos enviados: conversoriaecnae.es, gestoriascercademi.com, findemergencyplumber.com, Juridica Integral, Grot, Modulos-IRPF.
El vibe-coding no es improvisación. Es disciplina invisible. Y la restricción de tiempo — real, con consecuencias inmediatas si fallas — es el mejor filtro de calidad que existe.
---
El mito de la disciplina formal como sustituto del equipo
La creencia común es que el solo-dev necesita más estructura para compensar que trabaja solo.
Así que montan tableros Kanban con 8 columnas. Se ponen story points a sí mismos. Se hacen daily standups frente al espejo.
Eso no es disciplina. Es ruido.
El problema es profundo: estás replicando procesos diseñados para equipos de 5-10 personas en un sistema de 1 persona. Es como ponerte una reunión de retrospectiva contigo mismo. No tiene sentido.
❌ Enfoque débil: Tablero Kanban complejo, sprints de 2 semanas, estimaciones, retrospectivas semanales, OKRs trimestrales, reuniones de planning.
✅ Enfoque real: Un solo tablero con tres columnas: "mañana", "próximo mes", "tal vez nunca". Y un solo proceso: codificar en flujo, reflexionar fuera del teclado, desplegar antes del fin de semana.
Los solo-dev más longevos que conozco — los que llevan años enviando software sin quemarse — tienen exactamente cero procesos formales. Tienen rituales. Y los rituales no se planifican en una reunión de sprint planning.
---
Por qué 90 minutos entre siestas valen más que 8 horas sin hijos
En Google I/O 2026, Google AI Studio anunció "native Android vibe coding support" — la capacidad de generar apps nativas desde un prompt en el móvil. La industria entera se mueve hacia el vibe-coding como metodología.
Pero los que lo presentan como novedad no han entendido algo fundamental: el vibe-coding no es nuevo. Es lo que los solo-dev con restricciones reales llevamos años haciendo.
La diferencia entre un equipo con roadmaps formales y un solo-dev con hijos no es de cantidad de código. Es de calidad de decisiones.
Los equipos con roadmaps formales acumulan capas. Abstracciones prematuras. Patrones de diseño donde no hacen falta. Testing exhaustivo de edge cases que nunca ocurrirán. Documentación que nadie lee.
El solo-dev sin tiempo no puede permitirse eso.
```
// Equipo con roadmap formal:
abstract class BaseService<T extends Entity, R extends Repository<T>> {
protected abstract val repository: R
protected abstract val validator: Validator<T>
protected abstract val eventBus: EventBus
fun create(entity: T): Result<T> {
return validator.validate(entity)
.flatMap { repository.save(it) }
.flatMap { eventBus.emit(EntityCreated(it)); Result.success(it) }
}
// 47 líneas más de abstracciones que nunca se usarán
}
// Solo-dev con 90 minutos:
async function createUser(data) {
const { error } = await supabase.from('users').insert(data)
if (error) return { error }
return { data }
}
```
El segundo fragmento hace exactamente lo que necesita. Ni más, ni menos. Cuando tengas 10.000 usuarios y necesites abstracciones, las añades. Pero el 90% de los productos mueren por falta de usuarios, no por falta de escalabilidad.
---
El Patrón de los 3 Ciclos: el framework del solo-dev con restricciones reales
Google AI Studio anunció en I/O 2026 que permite "Build across the Google ecosystem" — exportar proyectos directamente a Antigravity, integrar Workspace, desplegar desde el móvil. La dirección es clara: quitar fricción entre la idea y el deploy.
Pero la tecnología no resuelve el problema fundamental del solo-dev: cómo priorizar cuando literalmente no tienes tiempo para todo.
Aquí está el framework que uso — El Patrón de los 3 Ciclos — y que he validado en seis productos enviados:
Ciclo 1 — La Ventana de Flujo (diario, 60-90 min)
Identifica tu bloque de tiempo donde la energía cognitiva está al máximo. Para padres con niños pequeños: suele ser 5-7 AM o después de que los hijos duermen.
Reglas de la ventana de flujo:
Sin notificaciones. Sin Slack. Sin email.
Un solo objetivo. No multitasking.
Nada de meetings. Nada de código legacy. Solo features nuevas o bugs críticos.
Durante esta ventana, no tomas decisiones arquitectónicas. Tomas decisiones de ejecución. Las decisiones importantes las tomas fuera del teclado — paseando, en la ducha, llevando al peque al colegio.
La investigación y la práctica lo confirman: las mejores decisiones de arquitectura ocurren cuando no estás codificando.
Ciclo 2 — El Filtro de Paternidad (semanal, 30 min)
Aplica este filtro a cada feature antes de escribirlo. Pregúntate: "si solo tuviera 2 horas esta semana para construir esto, ¿cómo lo haría?"
Esa respuesta es casi siempre la versión correcta.
Lo que elimina el filtro de paternidad:
Configuraciones innecesarias (páginas de settings que nadie usará)
Dashboards administrativos (adminéalo desde la base de datos hasta que tengas 50 clientes)
Edge cases que probablemente nunca ocurran (el usuario cuyo email tiene 256 caracteres no existe)
Abstracciones prematuras ("esto podría reutilizarse en el futuro" — no, no va a reutilizarse)
Lo que conserva:
Lógica de negocio que diferencia tu producto
Flujo crítico del usuario (registro, pago, funcionalidad principal)
Lo que hace que el producto funcione para un usuario real
Ciclo 3 — El Release del Viernes (quincenal)
Establece un ritmo de release personal. Despliega el viernes antes del almuerzo, cuando tu energía baja. El código descansa el fin de semana.
El sábado por la mañana, con la mente fresca tras dos días sin mirar el código, revisas lo que hiciste. Ese diferimiento de 24-48 horas es más efectivo que cualquier code review de un par.
¿Por qué funciona? Porque replicas el beneficio del code review — perspectiva fresca, detección de errores obvios — sin necesidad de un segundo desarrollador.
```
// workflow de release personal:
// viernes 11:00 — último push
// viernes 11:30 — despliegue a producción
// viernes 12:00 — apagar ordenador
// sábado 09:00 — revisar lo desplegado
// sábado 09:15 — hotfix si es necesario
// sábado 09:30 — seguir con el finde
```
Este patrón protege tu salud mental, fuerza un context switch natural, y produce código más sólido que cualquier sprint retrospectivo.
---
Externaliza todo lo que no sea diferenciador
El solo-dev con tiempo limitado no puede permitirse construir infraestructura commodity.
La decisión técnica más importante que tomarás no es qué framework de frontend usar. Es qué externalizas y qué construyes.
Cuando lancé gestoriascercademi.com, externalicé:
Auth (Supabase)
Base de datos (Supabase)
Hosting (Vercel)
Dominio y DNS
Analytics
Lo que construí yo:
La lógica de matching entre gestorías y clientes
El crawl de datos de asesorías por provincia
La UI específica del flujo de búsqueda local
❌ Error de solo-dev júnior: Construir auth propio "porque es más seguro", hostear en DigitalOcean "para ahorrar", gestionar DNS manualmente.
✅ Acierto de solo-dev con restricciones: Supabase para auth y DB, Vercel para deploy, todo gestionado. El tiempo que ahorras en infraestructura lo inviertes en lógica de negocio.
La decisión Supabase vs Firebase no es técnica. Es estratégica: ¿vas a escalar contigo (open-source) o vas a escalar para otro (propietario)?
El solo-dev con experiencia elige Supabase. No porque sea mejor técnicamente (lo es), sino porque el vendor lock-in es una deuda que se paga cuando menos tiempo tienes.
---
Define 'done' como 'funciona para un usuario real'
El solo-dev no tiene recursos para cobertura del 100% de tests. Ni la necesita.
El vibe-coding acepta deuda técnica consciente y la refinancia cuando hay tracción.
El ciclo real no es "diseño → desarrollo → testing → deploy". Es:
1. ¿Funciona para un usuario real? → Despliega.
2. ¿El usuario se queja? → Arréglalo.
3. ¿Nadie se queja? → El feature era irrelevante. No pierdas tiempo en tests.
Esto no es cutrerío. Es eficiencia. Cuando tienes 90 minutos al día, no puedes permitirte testear edge cases que probablemente nunca ocurran.
El 41% de pipelines de agentes fallaban por errores de parsing JSON en producción durante las primeras fases de un estudio de 2026. La solución no fue "más tests". Fue dos líneas de código defensivo que reduzieron la tasa de fallo al 11%.
El solo-dev efectivo no previene errores. Los repara más rápido de lo que un equipo puede planificar.
Sin aprobaciones. Sin reuniones de retrospectiva. Sin code review. Detectas un error en producción y tienes el fix en 10 minutos. Eso es agilidad real.
---
Y si eres un solo-dev veinteañero sin ataduras, ¿qué haces?
El argumento más común contra este enfoque: "esto asume que tienes hijos o responsabilidades externas — ¿qué pasa si soy un solo-dev de 22 años sin nada más que hacer?"
Entonces necesitas crear restricciones artificiales.
El mejor consejo que puedo darte:
Consíguete un hobby demandante que ocupe tiempo real
Haz voluntariado 4 horas al día
Imponte deadlines con consecuencias reales
Sin restricciones reales, el desarrollador sin experiencia tiende a sobreingeniería infinita. He visto a devs de 22 años pasarse 6 meses reescribiendo su backend "para que sea más escalable" antes de tener un solo usuario.
La restricción no es el enemigo. Es el filtro.
---
Vibe-coding no es improvisación. Es disciplina invisible.
El debate actual confunde vibe-coding con falta de estructura.
No es eso.
El vibe-coding del solo-dev experimentado tiene estructura invisible: alternas entre sprints de flujo profundo (sin interrupciones, sin multitasking) y períodos de reflexión (paseando, en la ducha, con la peque dormida en el brazo).
Cuando Google AI Studio anuncia "native vibe coding support" y la capacidad de construir apps Android desde un prompt en el móvil, están validando lo que los solo-dev con restricciones reales llevamos años haciendo: codificar cuando puedes, donde puedes, como puedes.
La diferencia es que nosotros no tenemos el lujo de hacerlo porque es cool. Lo hacemos porque es la única forma.
90 minutos al día. Entre el taller de pintura y la cena. Con un bebé de 6 meses durmiendo en la habitación de al lado.
Y seis productos enviados que demuestran que funciona.
*La disciplina no es tener más tiempo. Es saber exactamente qué hacer cuando el tiempo que tienes se acaba.*
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