🌵 El Framework Agave

En mi último post os hablaba del "síndrome del pulpo": esa manía que tengo (y que sé que compartimos muchos) de querer abarcar mil side projects a la vez, compaginarlos con mi jornada en Samara y, además, pretender tener vida social, hacer deporte y descansar. Spoiler: las matemáticas no dan.

Así que necesitaba un sistema. No un framework de productividad= Algo simple, personal y sin complicaciones. Lo he llamado el Framework Agave.

¿Por qué el agave?

El agave es una planta fascinante. Crece durante años acumulando energía, echa unas hojas inmensas y, un buen día, produce una flor espectacular. Una vez que florece... muere. Ha cumplido su ciclo vital, ha hecho lo que venía a hacer y se despide.

Nosotros, en cambio, tenemos la obsesión tóxica de que todo lo que empezamos tiene que durar para siempre o que tiene que llegar al mismo fin. Si empiezo una newsletter, tiene que ser eterna; si aprendo a programar, tengo que acabar montando un SaaS; si abro un blog, tengo que publicar cada semana hasta el fin de los tiempos.

El Framework Agave es mi sistema personal para aceptar que los proyectos también tienen un ciclo de vida. Algunos nacen solo para enseñarnos algo rápido. Otros simplemente se marchitan porque no los regamos. Y no pasa nada. Cada proyecto nace con un contrato conmigo mismo: un objetivo claro, un presupuesto de energía, y una fecha de caducidad implícita.

1. La Semilla: definir el "para qué" real

Antes de abrir una pestaña nueva en el navegador o un documento en blanco, me obligo a responder dos preguntas:

¿Qué tipo de proyecto es?

No todos los side projects son iguales, y tratarlos igual es un error. Yo los clasifico en cuatro tipos:

• Aprendizaje: quiero entender una herramienta o tecnología nueva. Horizonte: 1-4 semanas.

• Diversión creativa: quiero construir algo por el puro placer de hacerlo. Horizonte: 2-6 semanas.

• Producto / Negocio: quiero crear algo que genere valor o ingresos a largo plazo. Horizonte: 2-6 meses.

• Personal: resuelve una necesidad mía concreta (una web para mi boda, una agenda personal...). Sin horizonte fijo.

¿Cuál es mi condición de florecimiento?

Esta es la clave de todo el framework. Una frase concreta que define cuándo el proyecto "ha cumplido". Ejemplos reales míos:

• "Entender cómo funciona chrono-node y montar un date picker funcional" → Aprendizaje. Lo hice, publiqué el componente en open source, floreció. Archivado.

• "Tener un juego de puzzles jugable que pueda compartir con amigos" → Diversión. Lo monté, está online, la gente juega. Floreció. Modo mantenimiento.

• "Conseguir 5 workspaces activos en Slack para mi SaaS" → Negocio. Todavía no ha florecido. Sigo regando.

Si no puedo definir la condición de florecimiento en una frase, no empiezo el proyecto. Esa regla sola me ha ahorrado empezar al menos tres cosas este año.

2. El Riego: el presupuesto de energía (y la honestidad brutal)

Mi día a día de 9:00 a 18:30 está en Samara, que es mi prioridad y lo que me da de comer. El resto de mi tiempo es sagrado: pareja, amigos, deporte, naturaleza. Así que seamos honestos: ¿cuánto tiempo real tengo para side projects?

He hecho las cuentas. 6-8 horas semanales. Eso es lo que hay. Algunos fines de semana me inspiro y le dedico más; entre semana a veces saco una hora después de cenar. Pero la media son 6-8 horas.

Y aquí viene la parte incómoda: 6 horas a la semana dan para 1-2 proyectos activos. No para 5. Si tengo tres side projects "activos" a la vez, en realidad no tengo ninguno: tengo tres proyectos recibiendo 2 horas semanales cada uno, que no es suficiente para mover nada.

Así que la regla es simple: máximo 2 proyectos regándose a la vez. El resto está en pausa consciente (que no es lo mismo que abandonado — es una decisión, no una derrota).

Si un proyecto me empieza a exigir más horas de las presupuestadas, o peor aún, si me empieza a quitar paz mental, entra directamente en zona de peligro.

3. La Poda: mis "métricas de mínimos" (cuándo cortar por lo sano)

Esta es la parte más dura, pero la más liberadora. Más que métricas de fracaso, las veo como métricas de mínimos: la línea roja que me indica dónde merece la pena seguir invirtiendo esfuerzo y qué debo dejar morir.

Si un proyecto no supera estos tres filtros, se corta:

Incapacidad crónica de cumplir el roadmap

Si pasan las semanas y soy incapaz de cumplir consistentemente con las tareas básicas que yo mismo me he marcado — sentarme a escribir ese post para el blog, dedicar esa hora a hacer outbound, terminar esa feature — es una señal clarísima. Si el plan dice una cosa pero mi calendario real dice otra de forma repetida, el proyecto me viene grande ahora mismo o, simplemente, no es prioridad.

El test es binario: ¿he cumplido al menos la mitad de mis tareas semanales en este proyecto las últimas tres semanas? Si la respuesta es no, hay que tomar una decisión.

Falta de excitement (el ROI de energía)

Un side project, por definición, te roba tiempo de descanso. Tiene que compensar dándote energía. Si sentarme a desarrollarlo no me genera excitement, me da pereza y siento que me vacía en lugar de aportarme algo positivo, es momento de matarlo. No tiene sentido sacrificar tiempo con mi pareja o dejar de hacer deporte por algo que no me ilusiona.

La regla de las 3 semanas de abandono

Si pasan 21 días seguidos sin que le haya dedicado ni un solo minuto de forma proactiva, significa que mi cerebro ya lo ha descartado, aunque mi ego no quiera admitirlo. Se archiva. Sin drama.

4. El Abono: documentar y soltar

Cuando un proyecto muere — ya sea porque floreció (cumplió su objetivo) o porque no superó las métricas de mínimos — hago un cierre rápido. Abro Obsidian y anoto:

- Qué he aprendido (herramientas, conceptos, decisiones)

- Por qué se para (floreció, lo abandoné, pivoté, ya no tiene sentido)

- Qué me llevo (código reutilizable, contactos, ideas para otro proyecto)

Y lo borro de mi cabeza. Ese es el abono: lo que aprendí en un proyecto muerto alimenta al siguiente.

Un ejemplo concreto: monté un bot de Slack para gestionar vacaciones como proyecto autónomo. Funcionaba, el MVP estaba listo. Pero cuando empecé a construir otro SaaS más completo que incluía esa misma funcionalidad, el bot standalone dejó de tener sentido. En vez de arrastrarlo por ego ("pero si ya está hecho..."), lo pausé conscientemente. Lo que aprendí sobre la Slack API, sobre flujos de aprobación, sobre cómo diseñar modales interactivos, se fue directamente al proyecto más grande. El bot murió. Su conocimiento, no.

El día a día: de framework a rutina

Un framework que no se ejecuta es filosofía de LinkedIn. Para que el Agave funcione de verdad, necesita un ritual mínimo. El mío es simple:

Cada lunes (5-10 minutos): abro una nota en Obsidian y respondo tres cosas:

1. ¿Qué conseguí la semana pasada?

2. ¿Cuáles son mis 1-2 proyectos activos esta semana?

3. ¿Cuáles son mis 3-5 tareas concretas? (Máximo 5. Si no caben, estoy intentando hacer demasiado.)

Cada viernes (5 minutos): anoto qué hice, qué aprendí y qué arrastro a la siguiente semana. Archivo la nota.

Eso es todo; una nota semanal que tardo menos en rellenar que en preparar un café.

So far, so good

Ahora mismo tengo 11 proyectos en distintas fases. Dos están regándose activamente. Tres están en producción en modo mantenimiento. Cuatro están en pausa consciente. Y dos han florecido y están archivados.

Antes, esos 11 proyectos me habrían generado ansiedad. Ahora me generan curiosidad. Porque sé exactamente cuáles merecen mi energía esta semana, cuáles están esperando su turno, y cuáles ya han cumplido su misión.

El agave no se estresa por florecer. Crece, acumula, y cuando llega el momento, florece. Y si no llega el momento, pues tiene unas hojas bastante bonitas igualmente.

¿Cuántos side projects tienes acumulando polvo que merecen un cierre digno?

Gonz.

¿Tienes ganas de más? Visita itwasgonz.com para conocerme mejor.