Cómo construir side projects mientras trabajas a tiempo completo: un sistema, no motivación

Seré sincero contigo: la motivación es una pésima estrategia para entregar side projects. Llevo años construyendo cosas por mi cuenta mientras desempeño un rol exigente de tech lead a tiempo completo, y los proyectos que de verdad salieron adelante no tuvieron nada que ver con arranques de inspiración. Fueron el resultado de sistemas aburridos y repetibles.

Si esperas “sentirte motivado” para trabajar en tu side project después de un día largo, vas a esperar para siempre. Esto es lo que realmente funciona.

Por qué la motivación falla y los sistemas ganan

La motivación es una emoción. Llega a su punto máximo después de ver un video de YouTube de alguien que construyó un SaaS en un fin de semana y se desploma en el momento en que te topas con una migración de base de datos complicada a las 9 de la noche de un martes. No puedes construir nada significativo solo con emociones.

Los sistemas, en cambio, son decisiones que tomas una vez y luego sigues. Eliminan la necesidad de decidir cada día si “tienes ganas” de trabajar. La decisión ya está tomada.

Mi sistema es simple:

• Bloques nocturnos de dos horas, tres noches por semana (martes, miércoles y jueves)
• Sábados por la mañana, de 7 a 11 AM — mi ventana más productiva
• El domingo es libre. Sin excepciones. Tu cerebro necesita recuperarse.

La clave: esos bloques de dos horas son sagrados. No reviso Slack, no arreglo “rápidamente” un bug de producción, no me pierdo en el doom-scrolling. El bloque empieza, abro mi editor y trabajo en la siguiente tarea. Eso es todo.

En seis meses, esos bloques suman aproximadamente 400 horas. Es suficiente para entregar un producto real. No un juguete: un producto real y utilizable.

Elegir proyectos de forma estratégica

Aquí es donde la mayoría de los desarrolladores se equivoca: construyen lo que suena genial en lugar de lo que resuelve un problema real. Yo también he caído en eso. Una vez pasé tres meses construyendo un gestor de tareas “revolucionario” que nadie necesitaba, empezando por mí.

Los mejores side projects nacen de tus propios puntos de dolor. Ya entiendes el problema a fondo, eres tu propio primer usuario y puedes validar al instante si la solución funciona.

Algunas de mis mejores ideas surgieron de fricciones que viví en el trabajo:

• Una herramienta de legaltech nacida de ver a abogados procesar a mano documentos que podrían automatizarse en minutos
• Una automatización interna que le ahorró a mi equipo horas de tareas repetitivas de deploy
• Un dashboard de monitoreo porque las herramientas existentes eran demasiado caras o demasiado complejas para equipos pequeños

El filtro que uso ahora:

1. ¿Este problema le cuesta a alguien (a mí o a alguien que conozco) tiempo o dinero reales?
2. ¿Puedo construir una V1 utilizable en menos de 8 semanas de tiempo de side project?
3. ¿Me interesa lo suficiente como para usarlo yo mismo durante meses?

Si alguna respuesta es no, sigo adelante. Las ideas son infinitas. Tu tiempo es el recurso escaso.

La mentalidad de MVP para quien construye en solitario

Cuando eres un equipo de una sola persona, tu MVP tiene que ser implacablemente pequeño. No hablo de la versión de MVP del pitch deck de una startup. Me refiero a esto: ¿cuál es lo mínimo absoluto que entrega valor a una persona (tú)?

Para un SaaS que estaba construyendo para automatizar la revisión de contratos, mi MVP fue:

• Subir un PDF
• Extraer cláusulas clave con un pipeline de NLP sencillo
• Mostrarlas en una lista

Sin cuentas de usuario. Sin sistema de pagos. Sin una interfaz bonita. Solo la propuesta de valor central funcionando de punta a punta. Lo construí en tres fines de semana.

Todo lo demás —auth, facturación, un frontend como Dios manda— vino después, cuando confirmé que la idea central realmente funcionaba y que la gente la quería.

# Mi checklist de MVP antes de escribir una sola línea de código:
1. Definir la ÚNICA cosa que esto hace
2. Dibujar el camino feliz (literalmente en papel)
3. Listar lo que NO voy a construir en la V1
4. Fijar una fecha límite (normalmente 4-6 sesiones de fin de semana)
5. Entregarlo, aunque esté feo

La lista de “lo que no voy a construir” es más importante que la lista de funcionalidades. Te mantiene honesto cuando el scope creep te susurra dulces palabras a las 10 de la noche.

Decisiones de stack tecnológico para ganar velocidad

Aquí es donde los desarrolladores con experiencia tienen en realidad una desventaja. Conocemos demasiadas herramientas y nos tienta elegir la “correcta” para cada situación. En un side project, el stack correcto es aquel con el que puedes avanzar más rápido.

Mi stack para side projects:

• Backend: Go o Node.js con TypeScript, según lo que encaje mejor con el problema
• Frontend: Astro para sitios de contenido, Angular o React para aplicaciones (lo que domine más en ese momento)
• Base de datos: PostgreSQL. Siempre. No voy a aprender una base de datos nueva a las 9 de la noche
• Hosting: Railway o Fly.io para backends, Vercel o Cloudflare Pages para frontends
• Auth: Lucia o un proveedor externo. Nunca implementes el tuyo

El principio: minimiza las decisiones que no se relacionan directamente con tu problema central. Cada hora que pasas debatiendo sobre ORMs es una hora que no dedicas a la funcionalidad que importa.

He visto desarrolladores pasar semanas configurando el monorepo “perfecto” con Nx, Turborepo, configuraciones personalizadas de ESLint y pipelines de CI/CD, para un proyecto que nunca entregó una sola funcionalidad. No seas esa persona.

Cómo lidiar con el burnout

Hablemos del elefante en la habitación. Trabajar a tiempo completo y construir por tu cuenta es agotador. Si no administras tu energía de forma intencional, te vas a quemar. Yo ya pasé por ahí.

Señales que aprendí a reconocer:

• Temerle al bloque de la noche en lugar de sentirme neutral al respecto
• Escribir código que sé que es malo, pero sin importarme lo suficiente como para arreglarlo
• Saltarme bloques durante dos semanas seguidas y poner excusas
• Sentir resentimiento hacia el side project

Cuando noto estas señales, sigo un protocolo estricto:

1. Me tomo una semana completa libre del side project. Sin culpa.
2. Reevalúo si todavía me importa el problema. Si no, mato el proyecto. En serio.
3. Reduzco el calendario de forma temporal. Dos bloques en lugar de tres. Una mañana de sábado en lugar de la sesión completa.
4. Hablo con alguien que no sea desarrollador. La perspectiva externa de mi pareja me ha salvado de varios callejones sin salida.

El objetivo no es esforzarte hasta romperte. El objetivo es construir de forma constante durante años. No puedes hacerlo si te apagas cada tres meses.

El efecto compuesto

Esto es lo que nadie te cuenta sobre los side projects: el valor no está solo en el proyecto en sí. Está en lo que se acumula a su alrededor.

Después de dos años de trabajo constante en side projects, tenía:

• Un portafolio de productos reales y entregados (no clones de tutoriales)
• Conocimiento profundo en áreas ajenas a mi trabajo diario (legaltech, automatización, NLP)
• Una red de personas a quienes mis proyectos les resultaron útiles
• Opiniones probadas en batalla sobre arquitectura, porque cometí todos los errores yo mismo
• Confianza para tomar decisiones técnicas más rápido, lo cual mejoró directamente mi trabajo de tiempo completo

Cada proyecto me enseñó algo que hizo más rápido al siguiente. Mi primer intento de SaaS tardó seis meses y nunca se lanzó. El más reciente pasó de la idea a tener usuarios de pago en cinco semanas. La misma cantidad de bloques nocturnos, solo que con la experiencia acumulada.

Una reflexión final

Construir side projects mientras trabajas a tiempo completo no se trata de ser una persona de la “cultura del hustle”. Se trata de tener control sobre tu crecimiento como ingeniero y, potencialmente, sobre tu futuro financiero.

Los desarrolladores que más admiro no son los que se matan trabajando 80 horas a la semana. Son los que se presentan con constancia, construyen cosas que les importan y saben cuándo descansar.

Arma tu sistema. Protege tus bloques. Entrega algo pequeño. Y luego hazlo de nuevo.

La motivación va y viene. El sistema se queda.