🌵 The Agave Framework
Learning how to kill projects (and shed dead weight)
In my last post, I talked about "octopus syndrome": that habit I have (and I know many of you share) of trying to juggle a thousand side projects at once, balancing them with my full-time job at Samara, while still trying to have a social life, exercise, and get some rest. Spoiler: the math doesn't add up.
So I needed a system. Not just another productivity framework with Eisenhower matrices and Notion dashboards with 47 different views. Something simple, personal, and honest. I call it the Agave Framework.
Why the agave?
The agave is a fascinating plant. It grows for years, storing up energy and sprouting immense leaves, and then, one day, it produces a spectacular flower. Once it blooms... it dies. It has completed its life cycle, done what it came here to do, and says its farewell.
We, on the other hand, have this toxic obsession that everything we start has to last forever or reach the same ultimate conclusion. If I start a newsletter, it has to be eternal; if I learn to code, I have to end up building a SaaS; if I start a blog, I have to publish every week until the end of time.
The Agave Framework is my personal system for accepting that projects also have a life cycle. Some are born just to teach us something quickly. Others simply wither away because we don't water them. And that's okay. Every project is born with a contract with myself: a clear objective, an energy budget, and an implicit expiration date.
1. The Seed: Defining the Real "Why"
Before opening a new browser tab or a blank document, I force myself to answer two questions:
What kind of project is it?
Not all side projects are created equal, and treating them the same is a mistake. I classify them into four types:
Learning: I want to understand a new tool or technology. Horizon: 1–4 weeks.
Creative Fun: I want to build something for the pure joy of it. Horizon: 2–6 weeks.
Product / Business: I want to create something that generates value or income in the long term. Horizon: 2–6 months.
Personal: It solves a specific need of mine (a wedding website, a personal planner...). No fixed horizon.
What is my "blooming condition"?
This is the key to the entire framework. It's a specific sentence that defines when the project has "delivered." Here are some real examples of mine:
"Understand how chrono-node works and build a functional date picker" → Learning. I did it, published the component as open source, and it bloomed. Archived.
"Have a playable puzzle game I can share with friends" → Fun. I built it, it's online, people are playing. It bloomed. Maintenance mode.
"Get 5 active Slack workspaces for my SaaS" → Business. It hasn't bloomed yet. I'm still watering it.
If I can't define the blooming condition in a single sentence, I don't start the project. This rule alone has stopped me from starting at least three things this year.
2. Watering: The Energy Budget (and Brutal Honesty)
My daily 9:00 to 18:30 is at Samara—that's my priority and what puts food on the table. The rest of my time is sacred: my partner, friends, sports, nature. So let's be honest: how much real time do I have for side projects?
I've done the math. 6–8 hours a week. That's it. Some weekends I feel inspired and dedicate more; sometimes I squeeze in an hour after dinner during the week. But the average is 6–8 hours.
And here comes the uncomfortable part: 6 hours a week is enough for 1–2 active projects. Not 5. If I have three "active" side projects at once, I actually have zero: I have three projects receiving 2 hours a week each, which isn't enough to move the needle on anything.
So the rule is simple: maximum 2 projects being watered at once. Everything else is on conscious pause (which isn't the same as being abandoned—it's a choice, not a failure).
If a project starts demanding more hours than budgeted, or worse, if it starts costing me my peace of mind, it goes straight into the danger zone.
3. Pruning: My "Minimum Metrics" (When to Cut Your Losses)
This is the hardest part, but the most liberating. Rather than failure metrics, I see them as minimum metrics: the red line that tells me where it's worth continuing to invest effort and what I should let die.
If a project fails these three filters, it gets cut:
Chronic inability to follow the roadmap
If weeks go by and I am consistently unable to complete the basic tasks I set for myself—sitting down to write that blog post, spending that hour on outbound, finishing that feature—it's a glaring sign. If the plan says one thing but my actual calendar repeatedly says another, the project is either too big for me right now or simply isn't a priority.
The test is binary: Have I completed at least half of my weekly tasks for this project over the last 3 weeks? If the answer is no, a decision must be made.
Lack of excitement (Energy ROI)
A side project, by definition, steals time from your rest. It has to compensate by giving you energy. If sitting down to develop it doesn't generate excitement, if I feel lazy about it and it feels draining rather than rewarding, it's time to kill it. There's no point in sacrificing time with my partner or skipping the gym for something I'm not excited about.
The 3-week abandonment rule
If 21 days go by without me proactively spending a single minute on it, it means my brain has already discarded it, even if my ego doesn't want to admit it. It gets archived. With no drama.
4. Fertilizer: Documenting and Letting Go
When a project dies—whether because it bloomed (met its goal) or because it failed the minimum metrics—I do a quick wrap-up. I open Obsidian and jot down:
- What I learned (tools, concepts, decisions)
- Why it stopped (it bloomed, I abandoned it, I pivoted, it no longer makes sense)
- What I'm taking away (reusable code, contacts, ideas for another project)
And then I clear it from my head. That's the fertilizer: what I learned from a dead project feeds the next one.
A concrete example: I built a Slack bot for managing vacations as a standalone project. It worked; the MVP was ready. But when I started building a more comprehensive SaaS that included that same functionality, the standalone bot no longer made sense. Instead of dragging it along out of ego ("but it's already done..."), I consciously paused it. What I learned about the Slack API, approval flows, and designing interactive modals went straight into the larger project. The bot died. The knowledge didn't.
Day-to-Day: From Framework to Routine
A framework that isn't executed is just LinkedIn philosophy. For Agave to actually work, it needs a minimal ritual. Mine is simple:
Every Monday (5–10 minutes): I open a note in Obsidian and answer three things:
1. What did I achieve last week?
2. What are my 1–2 active projects this week?
3. What are my 3–5 specific tasks? (Maximum 5. If they don't fit, I'm trying to do too much.)
Every Friday (5 minutes): I write down what I did, what I learned, and what I'm carrying over to next week. I archive the note.
That's it. No Kanban board, no sprint planning, no stand-up with myself. A weekly note that takes less time to fill out than brewing a coffee.
So far, so good
Right now, I have 11 projects in various phases. Two are being actively watered. Three are in production in maintenance mode. Four are on conscious pause. And two have bloomed and are archived.
Before, those 11 projects would have given me anxiety. Now, they give me curiosity. Because I know exactly which ones deserve my energy this week, which ones are waiting their turn, and which ones have already fulfilled their mission.
The agave doesn't stress about blooming. It grows, it accumulates, and when the time comes, it flowers. And if the time never comes, well, it still has some pretty nice leaves anyway.
How many side projects do you have gathering dust that deserve a dignified ending?
Gonz.
¿Tienes ganas de más? Visita itwasgonz.com para conocerme mejor.
