La Hija Durmiendo, el Código Saliendo: Por Qué 90 Minutos Entre Siestas Superan a 8 Horas Sin Hijos
Por qué 90 minutos de código entre siestas superan a 8 horas sin hijos. El Framework del Nap Unit para fundadores padres que priorizan mejor.
Tu Competidor Sin Hijos Escribe 8 Horas al Día. Tú, 90 Minutos. Y Su Código Es Peor.
Crees que necesitas más horas para construir un mejor producto. Que el fundador sin hijos, con jornadas de 14 horas frente al ordenador, te saca una ventaja insalvable.
*Te has equivocado de diagnóstico.*
El tiempo ilimitado no es una ventaja. Es una trampa. Cuando un fundador tiene 14 horas disponibles, el trabajo se expande para llenar esas 14 horas — refactorizando abstracciones para casos hipotéticos, moviendo pixels de CSS, reorganizando una codebase que nadie ha tocado. Esto se llama Ley de Parkinson, y es el asesino silencioso de la productividad técnica.
Yo escribo código entre siestas. Mi hija tiene 6 meses. Ella marca el ritmo. Cuando se duerme, tengo 90 minutos. Cuando se despierta, guardo el portátil. No hay prórroga.
Y he descubierto algo incómodo para los que tienen 8 horas diarias: mi código es mejor.
No soy más inteligente. No conozco más frameworks. Sencillamente, no puedo permitirme perder el tiempo.
---
El Problema: La Ley de Parkinson No Perdona al Fundador con Tiempo Ilimitado
La sabiduría convencional del ecosistema indie repite el mismo mantra desde 2010: "horas de silla". Más tiempo frente al teclado equivale a más valor entregado.
*Es falso.*
Los datos de mi propia experiencia — y la de decenas de solo-founders que he observado — muestran un patrón claro:
❌ Fundador sin hijos (8-14h/día): Pasa el 60% de su tiempo en trabajo performativo — reorganizar código, escribir documentación que nadie lee, tweakear animaciones que el usuario no nota. El valor real entregado por hora es bajo porque el coste de oportunidad de cada decisión es cero. Si metes la pinta a las 3 de la tarde, simplemente sigues hasta las 9.
✅ Fundador padre/madre (~4h/día reales): Pasa el 80%+ de su tiempo en producción real. Cada commit lleva el peso de saber que si no funciona, no habrá segunda oportunidad hasta la próxima siesta. El coste de oportunidad de cada decisión es máximo.
El resultado medible es este: 4 horas de trabajo real superan sistemáticamente a 14 horas de trabajo performativo. No porque seas más rápido. Sino porque no haces cosas que no importan.
---
La Evidencia: 90 Minutos Contra 8 Horas — Quién Gana y Por Qué
Tengo un competidor directo en el espacio de software para gestorías. No tiene hijos. Escribe de 9 de la mañana a 7 de la tarde. Su producto tiene más funcionalidades que el mío. Su panel de admin tiene más botones. Su documentación es más bonita.
*Su producto es peor.*
¿Por qué? Porque cuando tienes 90 minutos para entregar algo, te haces preguntas distintas. No preguntas "¿es esto elegante?". Preguntas "¿resuelve esto el problema del usuario antes de que la niña se despierte?".
Esa presión genera tres comportamientos que el fundador con tiempo ilimitado nunca desarrolla:
1. Arquitectura legible en 15 minutos. No puedo permitirme una codebase que requiera 2 horas de re-contextualización. Mis APIs tienen que ser obvias. Mis endpoints, auto-explicativos. Si un nuevo desarrollador (o yo mismo dos semanas después) no entiende el flujo en 15 minutos, es un problema de arquitectura, no de tiempo.
2. Deuda técnica bajo cero. No existe "lo arreglo luego". Porque luego es la siesta de mañana, y mañana tengo que entregar otra cosa. Si metes deuda técnica ahora, pagas los intereses en tu próxima ventana de 90 minutos. No puedes permitírtelo.
3. Priorización quirúrgica. Cada funcionalidad nueva compite con el tiempo de mi hija. No es abstracto. Es físico: si construyo X, no veo a mi hija durante esa siesta. X tiene que merecerlo.
---
Análisis: El Cambio de 'Constructor' a 'Cirujano'
Hay un cambio psicológico que ocurre cuando operas bajo restricciones de tiempo extremas. Pasas de ser constructor a ser cirujano.
El constructor mira el código como un craft project. Disfruta el proceso. Refactoriza porque es bonito. Añade abstracciones porque "quizás algún día".
El cirujano mira el código como una intervención. Entra, localiza el problema, corta lo mínimo indispensable, sutura y sale. No hay margen para lo estético.
*El constructor optimiza por calidad de código. El cirujano optimiza por valor de usuario por minuto.*
Y aquí está la ironía: el cirujano termina produciendo código más limpio. No porque lo intente, sino porque no tiene tiempo para ensuciarlo. Cuando solo tienes 90 minutos, escribes la función más simple que funciona. Sin abstracciones prematuras. Sin over-engineering. Sin "por si acaso".
Esa simpleza forzada es, objetivamente, mejor ingeniería.
---
El Framework del Nap Unit: Cómo Convertir 90 Minutos en tu Máquina de Ship
Aquí está el marco que uso cada día. Lo llamo el Framework del Nap Unit, y funciona porque trata el tiempo de siesta como la moneda fundamental — no negociable, no ampliable, no acumulable.
1. Define tu 'Nap Unit' — El Bloque de 90 Minutos
Tu unidad de tiempo no es el día, ni la semana. Es la siesta. 90 minutos. Todo tu trabajo tiene que caber en esa ventana.
❌ "Hoy voy a construir el sistema de facturación."
✅ "Esta siesta voy a implementar el endpoint de creación de facturas con test básico."
Si una tarea no cabe en un Nap Unit, no es que necesites más tiempo. Es que la tarea es demasiado grande. Descomponla hasta que cada pieza quepa en 90 minutos.
2. Aplica la Regla de las 3 Líneas
Antes de abrir el editor, escribe un comentario de 3 líneas describiendo exactamente lo que vas a enviar en esta sesión.
```typescript
// Nap Unit: 14:30 - 16:00
// Objetivo: Implementar endpoint POST /api/invoices
// Criterio de éxito: Un test que cree una factura y devuelva 201 + ID
```
Si no puedes articularlo en 3 líneas, la tarea es demasiado grande. Descompón.
3. Implementa el Reverse Parkinson Measurement
Mide tu ratio real de output. Calcula (tiempo escribiendo código que se envía) / (tiempo total de trabajo). Tu objetivo es que al menos el 60% de tu Nap Unit sea producción real.
```
Nap Unit de 90 minutos:
Escribir código: 55 min (61%) ✅
Debuggear: 10 min (11%)
Pensar/leer docs: 15 min (17%)
Context-switch (abrir Slack/Twitter): 10 min (11%) ❌
```
Si estás por debajo del 60%, algo huele mal. O estás procrastinando, o la tarea no estaba bien definida.
4. Adopta la Regla de 'Una Sola Cosa' por Deploy
Cada commit o deploy debe resolver exactamente un problema de usuario.
❌ Commit: "Refactor invoice module and add PDF export"
✅ Commit: "Add PDF export for invoice #234"
Sin "while I'm here". Sin refactor oportunista. Sin scope creep. Un problema, un commit, un deploy.
5. Auditoría de Código Huérfano al Viernes
Al final de cada semana, revisa qué código has escrito que nadie usa todavía. Si una funcionalidad enviada no ha sido interactuada por usuarios reales, se borra en el próximo Nap Unit.
Sin apego emocional. Sin "quizás más adelante". Si no lo usan, no existe.
---
El Código Que Sale Entre Siestas: Ejemplo Real
Voy a mostrarte cómo se ve una decisión de priorización bajo el Framework del Nap Unit. Aquí hay un ejemplo real de un sistema de priorización de features que implementé para gestoriascercademi.com:
```typescript
// Función de scoring para features bajo restricción de tiempo
// Cada feature request se evalúa contra el tiempo disponible
interface FeatureRequest {
id: string;
userImpact: number; // 1-10 (usuarios afectados x gravedad)
implementationMinutes: number;
userFrictionLevel: 'critical' | 'high' | 'medium' | 'low';
}
function prioritizeForNapUnit(
requests: FeatureRequest[],
napUnitMinutes: number = 90
): FeatureRequest[] {
const scoped = requests
.map(req => ({
...req,
score: req.userImpact / req.implementationMinutes,
fitsInNapUnit: req.implementationMinutes <= napUnitMinutes * 0.7
// 70% del Nap Unit max — necesitas margen para debug
}))
.filter(req => req.fitsInNapUnit) // Si no cabe, ni lo consideres
.sort((a, b) => b.score - a.score);
return scoped.slice(0, Math.floor(napUnitMinutes / 30));
// Aprox 3 features por siesta si son pequeñas
}
```
El filtro clave está en la línea 18: si no cabe en el 70% de tu Nap Unit, no existe para ti. No es que lo pospongas. Es que no existe. El fundador con tiempo ilimitado no tiene este filtro. Construye cosas que tardan 4 horas en validadas. Nosotros no.
---
Y Cuando el Bebé Duerme Toda la Noche... Te Quedan los Hábitos
Hay un momento, alrededor de los 12-18 meses, donde el niño empieza a dormir del tirón. De repente, tienes más tiempo. El peligro real en ese momento no es que no sepas qué hacer con él. Es que adoptes los malos hábitos del fundador con tiempo ilimitado.
La disciplina que construyes bajo restricción no debería desaparecer cuando la restricción desaparece.
El Framework del Nap Unit sigue funcionando aunque tengas 8 horas. La unidad de tiempo cambia, pero la regla de priorización no. Porque el problema nunca fue la cantidad de tiempo. Fue la calidad de las decisiones tomadas dentro de él.
Tu competidor sin hijos nunca ha tenido que elegir entre un refactor y ver crecer a su hija. Tú sí. Y esa elección, repetida cientos de veces, te ha enseñado algo que él tardará años en aprender:
*El código que no escribes es más importante que el código que sí.*
La niña sigue durmiendo. Voy a aprovechar los próximos 45 minutos.
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