Framework Agave: how I manage (and kill) my side projects

Over the past year, I've been building things non-stop. A Slack bot for managing vacations. A SaaS for time tracking. A daily puzzle game. A job offer generator. A salary calculator. A career site builder. A booking system.

Eleven projects at different stages. Some alive, some paused, some archived. And somewhere along the way, between the excitement of starting something new and the guilt of not finishing something old, I realized I needed a system. Not another productivity framework with Eisenhower matrices and Notion dashboards with 47 views. Something simple, personal, and honest.

I call it the Framework Agave.

Why the agave?

The agave is a fascinating plant. It grows for years accumulating energy, producing massive leaves, and then one day it blooms — a single, spectacular flower. After it blooms, it dies. It has completed its life cycle. It did what it came to do and said goodbye.

We, on the other hand, have this toxic obsession that everything we start must last forever or reach the same destination. 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 open a blog, I have to publish every week until the end of time.

The Framework Agave 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 because we stop watering them. And that's fine.

Each project is born with a contract with myself: a clear objective, an energy budget, and an implicit expiration date.

1. The Seed: define the real "why"

Before opening a new tab or a blank document, I force myself to answer two questions:

What type of project is this?

Not all side projects are 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 pleasure of it. Horizon: 2-6 weeks.
Product / Business: I want to create something that generates value or revenue long-term. Horizon: 2-6 months.
Personal: it solves a specific need of mine (a wedding website, a personal agenda...). No fixed horizon.

What's my blooming condition?

This is the key to the entire framework. A single concrete sentence that defines when the project "has fulfilled its purpose." 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. Bloomed. Archived.
"Have a playable puzzle game I can share with friends" — Fun. Built it, it's online, people play it. Bloomed. Maintenance mode.
"Get 5 active workspaces on Slack for my SaaS" — Business. Hasn't bloomed yet. Still watering.

If I can't define the blooming condition in one sentence, I don't start the project. That rule alone has saved me from starting at least three things this year.

2. The Watering: the energy budget (and brutal honesty)

My 9-to-7 belongs to my day job, which is my priority and pays the bills. 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 per week. That's what there is. Some weekends I get inspired and put in more; on weekdays I sometimes squeeze in an hour after dinner. But the average is 6-8 hours.

And here's the uncomfortable part: 6 hours a week is enough for 1-2 active projects. Not 5. If I have three "active" side projects simultaneously, in reality I have none: I have three projects receiving 2 hours each per week, which isn't enough to move anything forward.

So the rule is simple: maximum 2 projects being watered at a time. The rest is on conscious pause (which is not the same as abandoned — it's a decision, not a defeat).

If a project starts demanding more hours than budgeted, or worse, if it starts stealing my peace of mind, it enters the danger zone immediately.

3. The Pruning: my "minimum metrics" (when to cut your losses)

This is the hardest part, but the most liberating. More 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 should be left to die.

If a project doesn't pass these three filters, it gets cut:

Chronic inability to follow your own roadmap

If weeks go by and I'm consistently unable to complete the basic tasks I've set for myself — writing that blog post, dedicating that hour to outbound, finishing that feature — it's a clear signal. If the plan says one thing but my real calendar says another repeatedly, the project is too big for me right now, or it's simply not a priority.

The test is binary: have I completed at least half of my weekly tasks on this project for the last 3 weeks? If the answer is no, a decision needs to be made.

Lack of excitement (the energy ROI)

A side project, by definition, steals time from rest. It has to compensate by giving you energy. If sitting down to work on it doesn't generate excitement, if it feels like a chore and drains me instead of giving me something, it's time to kill it. It makes no sense to sacrifice time with my partner or stop exercising for something that doesn't excite me.

The 3-week abandonment rule

If 21 consecutive days pass without me proactively dedicating a single minute to it, it means my brain has already discarded it, even if my ego won't admit it. Archive it. No drama.

4. The Compost: document and let go

When a project dies — whether because it bloomed (fulfilled its objective) or because it didn't pass the minimum metrics — I do a quick closing. I open Obsidian and write down:

What I learned (tools, concepts, decisions)
Why it stopped (bloomed, abandoned, pivoted, no longer makes sense)
What I'm taking with me (reusable code, contacts, ideas for another project)

And I clear it from my head. That's the compost: what I learned from a dead project feeds the next one.

A concrete example: I built a Slack bot to manage vacations as a standalone project. It worked, the MVP was ready. But when I started building a more complete SaaS that included that same functionality, the standalone bot stopped making sense as a commercial product. Instead of dragging it along out of ego ("but it's already built..."), I released it as open source. What I learned about the Slack API, about approval workflows, about designing interactive modals — all of that went directly into the bigger project. The bot found a new purpose. Its knowledge never died.

The daily practice: from framework to routine

A framework that doesn't get executed is LinkedIn philosophy. For Agave to actually work, it needs a minimal ritual. Mine is ridiculously simple:

Every Monday (5-10 minutes): I open a note in Obsidian and answer three things:

What did I accomplish last week?
What are my 1-2 active projects this week?
What are my 3-5 concrete 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 carries over to the next week. Archive the note.

That's it. No Kanban board, no sprint planning, no standup with myself. One weekly note that takes less time to fill out than making a coffee.

So far, so good

Right now I have eleven projects at different stages. Two are being actively watered. Three are in production on maintenance mode. Four are on conscious pause. And two have bloomed and are archived.

Before, those eleven 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, accumulates, and when the moment comes, it blooms. And if the moment never comes, well, it has some pretty nice leaves anyway.

How many side projects do you have collecting dust that deserve a proper closing?