DEV Community: STACKFOLO

How I Track GitHub Commits Across All My Side Projects in One Place

STACKFOLO — Mon, 13 Apr 2026 11:08:51 +0000

How I Track GitHub Commits Across All My Side Projects in One Place

At one point last year, I had five active GitHub repositories. Two personal side projects, one open source contribution, a freelance client project, and an experimental thing I started on a weekend. Each had its own commit history, its own pace, and its own "when did I last touch this?" question that I could never answer without opening GitHub.

I found myself doing this multiple times a day: open GitHub, click into a repo, check the commit log, try to remember if that last commit was yesterday or three days ago. Then repeat for the next repo. It was a small friction, but small frictions compound.

Here is the system I built to see all my commits in one timeline without leaving my browser.

The Problem with Repo-Hopping

GitHub is excellent for individual repositories. The commit log, the PR history, the contribution graph. All great when you are focused on one project.

But when you are juggling multiple side projects, GitHub's repo-centric design works against you:

No cross-repo timeline. You cannot see "what did I do across all projects today?" without visiting each repo separately.
Context switching cost. Every repo hop breaks your train of thought. You went to check one commit message and now you are reading an old issue.
Progress blindness. Without a unified view, it is easy to think you are making progress everywhere when you are actually only pushing to one repo and neglecting the others.
Multiple accounts. If you have a personal GitHub and a work GitHub (or a client's org), the fragmentation doubles.

What I Tried First

GitHub's contribution graph. The green squares are motivating but useless for cross-project awareness. They show activity, not what you actually did or where.

GitHub notifications. These tell you about other people's activity, not yours. And the signal-to-noise ratio is rough.

A text file log. I tried keeping a manual log of daily commits. This lasted exactly four days before I forgot to update it.

Third-party dashboard tools. Most of these are designed for teams and managers, not solo developers tracking their own side projects. Overkill for what I needed.

The Unified Timeline Approach

What I actually wanted was simple: open one page and see a chronological list of my commits across all repos, mixed in with other project activity. No setup every morning. No manual logging. Just a timeline that updates itself.

The key insight was that this should live where I already spend time. Not in a separate app I would forget to open, but in my browser, visible every time I open a new tab.

I set this up using STACKFOLO, which connects to GitHub via personal access tokens and pulls commit history into a unified timeline. But the concept works with any system that aggregates commit data. Here is why the approach matters more than the specific tool.

What a Unified Commit Timeline Shows You

1. Where Your Time Actually Goes

When I first set up my cross-repo timeline, I had a surprise. I thought I was splitting time roughly equally between my two main side projects. The timeline showed I had made 23 commits to Project A in the past two weeks and 2 commits to Project B. Project B was not "on pause." It was abandoned, and I had not noticed.

2. Momentum Gaps

A timeline makes gaps visible. If your last commit to a repo was 9 days ago, you see it immediately. Without a unified view, these gaps hide behind your other activity. You feel productive because you pushed code today, but you pushed to the same repo you always push to.

3. Context Recovery

When you come back to a project after a break, the first question is "where did I leave off?" A commit timeline answers this in seconds. Your last three commit messages tell you what you were working on, and you can jump back in without re-reading your code.

4. Cross-Project Patterns

After a few weeks of data, I noticed patterns:

I only pushed to my open source project on weekends
My freelance commits clustered on Tuesday and Thursday evenings
My personal projects got attention in bursts (5 commits in one day, then silence for a week)

This was not intentional. Once I saw the pattern, I could decide whether to keep it or change it. I moved my open source contribution to Wednesday mornings, which turned out to be a better fit.

Setting Up Multi-Account Tracking

One thing that surprised me: most developers I talk to have more than one GitHub account. Personal, work, sometimes a client org account. Tracking commits across accounts is harder than tracking across repos within one account.

The approach I use:

Generate a personal access token for each GitHub account (read-only scope is enough)
Link each token to the projects that use that account
The timeline merges everything chronologically, regardless of which account made the commit

This means my personal side project commits, my work repo commits, and my freelance client commits all appear in one stream. I can filter by project when I need to focus, or see everything when I want the big picture.

Beyond Commits: The Full Project Timeline

Commits are the backbone, but a useful project timeline includes more:

Task completions. When you check off a to-do, it shows in the timeline alongside your commits.
Resource saves. When you bookmark a Stack Overflow answer or save a documentation page for a project, it appears in context.
Service events. Subscription renewals, deployment triggers, and domain renewals tied to specific projects.
Manual notes. Sometimes you need to log "decided to pivot from REST to GraphQL" and have it appear in the timeline.

This turns the timeline from a commit log into a project diary. When you look back at a project three months later, you see the full story, not just the code changes.

Practical Tips for Any Setup

Whether you use a dedicated tool or build your own, here is what I have learned:

Cache aggressively. GitHub API has rate limits. A 5-minute cache for commit data is enough for personal use and keeps things fast.
Show repo names clearly. When commits from 5 repos are interleaved, you need to immediately see which project each commit belongs to.
Make it visible. The timeline only works if you see it regularly. A browser new tab page, a pinned tab, or a widget on your desktop. Somewhere you cannot avoid.
Filter by project when you are focused. The unified view is for awareness. When you sit down to code on Project A, filter to just that project so you can pick up where you left off.
Do not over-engineer it. The point is awareness, not analytics. You do not need charts and graphs. A simple chronological list with dates, repo names, and commit messages is enough.

The Result

After three months with a unified commit timeline, I shipped two side projects that had been stalled for months. Not because the timeline gave me more time, but because it made my neglect visible. When you see "last commit: 12 days ago" every time you open a browser tab, it is hard to pretend you are still working on something.

The developers who finish side projects are not the ones with perfect plans. They are the ones who can see where all their projects stand at a glance.

Want a unified GitHub timeline in your browser's new tab? Try STACKFOLO on the Chrome Web Store. It is free to start, and GitHub integration works with public repos on the free tier.

How a Daily Dev Log Helped Me Actually Ship My Side Projects

STACKFOLO — Mon, 13 Apr 2026 11:05:18 +0000

How a Daily Dev Log Helped Me Actually Ship My Side Projects

I used to start side projects with excitement and abandon them within three weeks. Not because I lost interest, but because I lost track. I could not remember what I did yesterday, what I should do next, or whether I was making real progress or just staying busy.

The fix was embarrassingly simple: I started keeping a daily dev log. Not a fancy journaling app, not a 500-word diary entry, just a 2-minute check-in at the end of each coding session. Six months later, I have shipped two side projects and maintained a third. Here is the system.

Why Side Projects Die in Silence

Most side projects do not fail because of bad ideas or missing skills. They fail because there is no feedback loop.

At your day job, you have standups, sprint reviews, PRs that get comments. Someone notices when you ship something. Someone notices when you are stuck.

Solo side projects have none of that. You code for an hour, close your laptop, and the next time you open it you have lost all context. Multiply that by a few days and the project feels like a stranger's codebase.

The daily dev log replaces the feedback loop that a team normally provides. It is your personal standup, retro, and progress report rolled into one.

The 2-Minute Dev Log Format

My daily log takes less than 2 minutes and captures four things:

1. Focus Time (How Long Did I Actually Code?)

Not "time at desk" but actual focused coding time. I track this in hours, and I am honest about it. If I spent 90 minutes with my editor open but only 40 minutes writing code, I log 40 minutes.

This number alone changed my perspective. I thought I was "coding every day" but my log showed I averaged 25 minutes on weekdays and 45 minutes on weekends. Knowing the real number helped me set realistic expectations.

2. Mood Check (How Did the Session Feel?)

I pick one of five options: great, good, okay, rough, or terrible. Simple as that.

This sounds unnecessary until you spot patterns. I noticed that my "rough" sessions clustered on Mondays and Wednesdays. Turns out those were the days I had late meetings at work, and I was trying to code while mentally exhausted. Moving my side project time to mornings on those days fixed the pattern.

3. Wasted Time (What Stole My Focus?)

I log any time I spent on non-productive activities during my intended coding window. Scrolling Twitter, reading unrelated articles, rabbit-holing into configuration that did not matter.

The point is not guilt. The point is data. When I saw "30min researching the perfect ESLint config" three days in a row, I realized I was procrastinating on the actual hard problem (auth flow implementation).

4. One-Line Summary (What Did I Actually Do?)

One sentence. Not a paragraph, not a bullet list, one sentence.

Examples from my actual log:

"Added user signup form and validation"
"Debugged OAuth callback, still broken"
"Refactored database schema, no visible progress"
"Stared at the Stripe docs for 40 minutes"

This is the most valuable part. When you open your project after a 3-day break, reading the last few one-liners brings you back to context in seconds.

What Changes After 30 Days

The daily log does not feel useful on day 1. It starts paying off around day 14, and by day 30 it becomes something you actually want to maintain.

Week 1-2: Awareness. You realize how little focused time you actually spend on side projects. This is uncomfortable but necessary. You cannot optimize what you do not measure.

Week 3-4: Pattern recognition. You spot the days, times, and conditions where you do your best work. You also spot your procrastination triggers. Mine is "research" that never leads to a commit.

Month 2+: Momentum proof. When motivation dips (and it will), you scroll back through your log and see 30+ days of entries. The continuity itself becomes motivating. You have evidence that you are a person who works on side projects consistently, even if some days are only 20 minutes.

The Weekly Review: Where Shipping Happens

Once a week, I spend 10 minutes reviewing my daily logs. I ask three questions:

What did I ship this week? Not "work on" but actually ship. A deployed feature, a merged PR, a published page.
What blocked me? If the same blocker appears multiple days, it needs a different approach.
What should I focus on next week? Based on what I learned, not what I planned months ago.

This weekly review is where vague progress turns into concrete shipping. Without it, the daily log is just a diary. With it, the daily log becomes a project management system.

Satisfaction Rating: The Metric That Matters

I added one more thing to my log after the first month: a satisfaction rating from 1 to 5. Not "how productive was I" but "how satisfied am I with today's session."

This distinction matters. A 20-minute session where you fix one critical bug can feel more satisfying than a 2-hour session of boilerplate setup. The satisfaction rating helps you optimize for meaningful work, not just clock hours.

Over time, I noticed that my most satisfying sessions shared common traits:

I started with a clear, single objective
I avoided context switching mid-session
I committed and pushed before closing my laptop

Sessions with low satisfaction usually involved starting without knowing what to do, or trying to make progress on three things at once.

Tools for Daily Dev Logging

You can start with anything. A text file, a spreadsheet, or even a physical notebook. The format matters less than the consistency.

I tried several approaches:

Plain text file: Works but easy to forget. No structure enforcement.
Spreadsheet: Good for tracking numbers but clunky on mobile.
Notion/Obsidian: Powerful but too much friction for a 2-minute entry.

Eventually I built the daily log directly into STACKFOLO, my project dashboard Chrome extension. It captures focus time, mood, wasted time, satisfaction, and a one-liner, and it generates an AI summary at the end of each day. The new tab page means I see my log every time I open a browser tab, which keeps the habit visible.

But honestly, a spreadsheet works too. The system is what matters, not the tool.

Getting Started

If you want to try this, here is the minimum viable daily dev log:

Pick a time. Right after your coding session ends, not the next morning.
Log four things. Focus time (minutes), mood (1-5), wasted time (minutes), one-line summary.
Do not skip days. Even if you did zero coding, log "0 min, did not code today." The streak of entries matters more than the content.
Review weekly. Every Sunday, read your last 7 entries. Ask: what did I ship? What blocked me? What is next?

Start tomorrow. It takes 2 minutes. In a month, you will have 30 data points about your coding habits that no productivity article can give you.

The developers who ship side projects are not the ones with the most free time. They are the ones who know exactly where their time goes.

If you want a daily log built into your browser's new tab, try STACKFOLO on the Chrome Web Store. It is free to start.

How I Use a Weekly Timetable to Balance My Dev Job and Side Projects

STACKFOLO — Mon, 06 Apr 2026 09:04:11 +0000

How I Use a Weekly Timetable to Balance My Dev Job and Side Projects

Last year I had a problem that I think most developers share: I wanted to work on side projects, but after 8 hours of coding at my day job, I never had the energy or structure to make it happen.

I tried blocking "side project time" on my calendar. That lasted about a week. I tried waking up early. That lasted three days. I tried the "just do 30 minutes a day" advice, but without knowing which 30 minutes or what to work on, those sessions rarely materialized.

What finally worked was building a visible weekly timetable. Not a to-do list, not a vague calendar block, but a 7-day grid that mapped specific routines to specific time slots. Here is the system, and why it works when other approaches did not.

The Problem with "Find Time for Side Projects"

The advice you usually hear is some version of "schedule it" or "make it a priority." This is technically correct and practically useless.

Here is what actually happens when a developer tries to fit side projects into their week:

Monday evening: "I'll code after dinner." You eat, check your phone, and suddenly it is 10pm.
Tuesday evening: "Tonight for real." You open your laptop, stare at the code for 5 minutes, cannot remember where you left off, close the laptop.
Wednesday: You skip entirely. No guilt yet.
Thursday: You feel guilty. You open the project. Spend 20 minutes just getting back into context. Write 10 lines of code. Feel unsatisfied.
Friday: "I'll catch up this weekend."
Weekend: You do a burst of 4 hours on Saturday, feel productive, then do nothing Sunday.

Sound familiar? The pattern repeats because there is no structure holding it together. You are relying on motivation and willpower, which are both exhausted after a full day of knowledge work.

Why a Visual Timetable Works

A timetable is different from a calendar or a to-do list in one important way: it maps routines to time slots across the entire week at a glance.

When you look at a 7-day-by-24-hour grid, you can immediately see:

Where your committed time is (work, sleep, commute)
Where your available blocks actually are
Whether your side project time is realistic or wishful thinking

This visibility is the key. Most developers overestimate their available time because they think in terms of "evenings and weekends" without subtracting meals, exercise, family time, and the recovery period after focused work.

A timetable forces honesty. When you see that Tuesday evening has exactly one 90-minute block between dinner and sleep, you stop pretending you will "code for 3 hours" and start planning for what you can realistically do in 90 minutes.

My Weekly Timetable System

Here is the system I have been using for 6 months:

Step 1: Map Your Fixed Commitments

Fill in the non-negotiables first:

Work hours (e.g., 9am-6pm weekdays)
Sleep (e.g., 11pm-7am)
Meals, commute, exercise
Family or social commitments

This usually eliminates 70-80% of your week immediately.

Step 2: Identify Your Real Available Blocks

Look at what is left. For most employed developers, it comes down to:

Weekday mornings (30-60 min before work, if you are a morning person)
Weekday evenings (1-2 hours after dinner, energy permitting)
Weekend blocks (2-4 hour chunks)

Be honest about energy levels. A 7pm Tuesday slot after a day of debugging production issues is not the same as a 9am Saturday slot with fresh coffee.

Step 3: Assign Routines, Not Tasks

This is the critical difference. Do not put "fix authentication bug" in your Tuesday 7pm slot. Instead, assign a routine:

Tuesday 7pm-8:30pm: Side project coding
Thursday 7pm-8pm: Code review + planning for weekend session
Saturday 9am-12pm: Deep work on main side project
Sunday 10am-11am: Weekly review + milestone check

Routines repeat every week. Tasks change. When you assign a routine to a slot, you remove the daily decision of "should I work on my side project tonight?" The answer is already decided.

Step 4: Start with 3-4 Slots Per Week

The biggest mistake is scheduling side project time every single evening. You will burn out in two weeks.

Start with 3-4 slots per week. That is 4-8 hours of focused side project time. More than enough to make real progress if the sessions are structured.

Here is what a realistic developer timetable looks like:

         Mon    Tue    Wed    Thu    Fri    Sat       Sun
7:00am   --     --     Jog    --     --     --        --
9:00am   Work   Work   Work   Work   Work   PROJECT   --
12:00pm  Work   Work   Work   Work   Work   Lunch     --
2:00pm   Work   Work   Work   Work   Work   Free      --
6:00pm   Dinner Dinner Dinner Dinner Dinner Dinner    --
7:00pm   Free   CODE   Free   Plan   Free   Free      --
8:30pm   --     --     --     --     --     --        Review
10:00pm  Read   Read   Read   Read   Read   Read      Read

Four side-project slots: Tuesday evening coding, Thursday evening planning, Saturday morning deep work, Sunday evening review. That is roughly 7 hours per week, enough to ship meaningful features on a monthly cadence.

Step 5: Make the Timetable Visible

A timetable that lives in a spreadsheet you never open is useless. The whole point is that you see your weekly rhythm at a glance.

I keep mine in a place I see every day. Every time I open a new browser tab, there is my timetable. The visual cue is the difference between "oh right, it is Tuesday, that is my coding evening" and "I wonder what I should do tonight."

What Changed After 6 Months

Before the timetable, I shipped maybe one side project feature per quarter. Random, inconsistent progress.

After 6 months of the weekly timetable:

Shipped 3 features on my main side project
Reduced guilt about not working on side projects (if it is not a scheduled slot, I am allowed to rest)
Better work-life separation (side project time is defined, not infinite)
Weekend sessions became 2-3x more productive because Thursday evening planning meant I always knew what to work on Saturday morning

The counter-intuitive part: having less scheduled time made me more productive. Constraints force focus. When you know you only have 90 minutes on Tuesday evening, you do not waste 20 minutes deciding what to work on. You open your plan from Thursday and start coding.

Pitfalls to Avoid

Do not fill every evening. Recovery time is not wasted time. If you code all day at work and then code every evening, you will burn out.

Do not skip the planning slot. The Thursday evening (or whenever you schedule it) planning session is not optional. Without it, your coding sessions become aimless and you lose the momentum advantage.

Do not treat weekends as unlimited. Schedule a specific block (like Saturday 9am-12pm) and stop when it ends. "I'll just code all weekend" leads to skipping entire weekends.

Do not beat yourself up for missing a slot. You will miss sessions. Illness, social events, bad days. The timetable survives because it repeats every week. One missed Tuesday does not break the system.

Getting Started This Week

Draw a 7-day grid (paper, spreadsheet, or a timetable tool)
Fill in your fixed commitments first
Pick 3-4 realistic slots for side project work
Assign one slot specifically for planning/review
Put the timetable somewhere you see it daily

I built this system into STACKFOLO, which has a 7-day timetable grid where you drag routines into time slots and see your week at a glance on every new tab. But the approach works with any tool that lets you visualize a weekly schedule. The key is not the tool. It is the visibility.

Stop trying to "find time" for side projects. Build a timetable that shows you where the time already is.

I Had 400+ Bookmarks and Zero Organization. Here's What Fixed It.

STACKFOLO — Mon, 30 Mar 2026 09:15:08 +0000

I Had 400+ Bookmarks and Zero Organization. Here's What Fixed It.

Last month I counted my Chrome bookmarks. 437 items spread across 12 folders with names like "Useful," "Check Later," and my personal favorite, "Misc 2."

I could not find anything when I actually needed it. That React hooks tutorial I bookmarked three weeks ago? Buried somewhere between a CSS grid cheatsheet and a random Medium article about Kubernetes. The Stack Overflow answer that solved my auth bug? No idea which folder it ended up in.

Sound familiar? If you are a developer who saves web resources "for later," you probably have the same problem. The bookmark bar was never designed for knowledge management. It was designed for quick links to Gmail.

The Real Problem: Saving Is Easy, Organizing Is Not

Here is what typically happens. You find a useful article, tutorial, or documentation page. You hit Ctrl+D or click the star icon. Chrome asks you to pick a folder. You pick the closest match or just leave it in "Other Bookmarks."

Two weeks later, you need that resource. You open your bookmarks, scroll through 50 items in the wrong folder, give up, and Google the same thing again.

The friction is not in saving. It is in organizing at the moment of saving. When you are deep in a coding session and you find a useful resource, the last thing you want to do is:

Think about which category it belongs to
Add relevant tags
Write a note about why you saved it
Connect it to the right project

So you skip all of that, hit save, and move on. The bookmark becomes a digital post-it note you will never find again.

What I Tried Before

I went through the usual progression:

Browser folders: Created a careful hierarchy. Frontend > React > Hooks > Custom Hooks. Maintained it for about two weeks before defaulting back to dumping everything in "Misc."

Notion database: Set up a resource database with tags, categories, and a nice gallery view. The overhead of switching to Notion, pasting the URL, filling in fields, and switching back killed my workflow every single time.

Raindrop.io: Better than raw bookmarks. Decent tagging. But I still had to manually categorize everything, and I stopped doing it after the first month.

The pattern was always the same. Any system that requires manual organization at save time eventually gets abandoned. You need zero-friction saving with automatic organization.

The Shift: Let AI Do the Categorizing

The approach that finally worked was simple: remove the human from the organization step entirely.

Instead of deciding categories and tags myself, I started using a system where AI analyzes the page content at save time and generates the metadata automatically. You press a shortcut (Alt+Shift+S in my case), the page gets analyzed, and it comes back with:

A category (tutorial, reference, library, research, design, etc.)
Relevant tags based on the actual content
A one-line description summarizing why the page is useful

The difference is dramatic. Here is a real example:

Before (manual save):

Title: "useEffect cleanup explained"
Folder: React (if I remembered)
Tags: none
Notes: none

After (AI-analyzed save):

Title: "A Complete Guide to useEffect Cleanup Functions"
Category: Tutorial
Tags: react, hooks, useEffect, cleanup, memory-leaks
Description: "Explains when and how to use cleanup functions in useEffect to prevent memory leaks and stale state in React components"

Same resource, completely different findability. Three months later, searching for "memory leaks react" actually surfaces this bookmark.

Building a System Around It

AI categorization solved the save-time friction, but I needed a few more pieces to make it a real knowledge base:

Project-based filtering

Most of my saved resources relate to a specific project. That React hooks article matters for my SaaS frontend, not my CLI tool. Connecting resources to projects means I can pull up "everything I saved for Project X" in one click instead of searching through a flat list.

Star ratings for quality

Not all resources are equal. A comprehensive official docs page is more valuable than a quick blog post. I started rating resources on a 1-5 scale after actually using them. This turned my bookmark pile into a curated library where the best resources float to the top.

Active vs. archived

Resources have a shelf life. That webpack config tutorial from 2023 is probably outdated. Instead of deleting it (what if I need it?), marking it as archived keeps the active list clean while preserving the reference.

The Numbers After 3 Months

Here is where I landed after using this approach consistently:

437 bookmarks migrated and organized (took about a week of gradual AI re-categorization)
8 clean categories instead of 12 messy folders
Average 3.2 tags per resource (vs. zero before)
Time to find a saved resource: ~5 seconds (search by tag or category) vs. ~2 minutes of scrolling

The biggest win is not the organization itself. It is that I actually use my saved resources now. Before, bookmarking was just a way to feel productive without being productive. Now it is an actual reference system.

What I Would Tell Past Me

If you are sitting on hundreds of unorganized bookmarks right now, here is what I wish I had known:

Stop organizing manually. Any system that depends on your willpower to categorize things at save time will fail. Automate the categorization.
Connect resources to projects. A flat list of bookmarks is useless. Context matters. "I saved this for the auth system rewrite" is 10x more useful than "I saved this somewhere."
Do not migrate all at once. Re-organize gradually. Save new resources properly, and re-categorize old ones when you actually encounter them.
Rate after using, not after saving. You do not know if a resource is good until you actually reference it during work. Come back and rate it later.

This is the system I built into STACKFOLO, where the AI Smart Save feature handles the categorization automatically and connects everything to your project dashboard. But honestly, even a well-structured Notion database with consistent tagging habits would be a massive upgrade over raw bookmarks.

The point is not the tool. The point is removing yourself from the organization bottleneck. Let automation handle the boring part so you can focus on actually building things.

What is your bookmark situation like? Have you found a system that works, or are you still in the "Misc 2" folder stage? I would love to hear what approaches have worked for other developers.

How I Built a Daily Coding Habit (And Stopped Abandoning Side Projects)

STACKFOLO — Mon, 23 Mar 2026 03:08:10 +0000

How I Built a Daily Coding Habit (And Stopped Abandoning Side Projects)

I have started and abandoned more side projects than I can count. The pattern was always the same: a burst of motivation on a weekend, three intense coding sessions, then nothing for two weeks. By the time I came back, I had lost all context. The codebase felt unfamiliar. The enthusiasm was gone. Another repo joined the graveyard.

The problem was never ideas or technical skill. It was consistency. I could write code for eight hours when I was excited, but I could not write code for thirty minutes when I was not. And "not excited" describes most weekday evenings after a full day of work.

What changed was not willpower. It was systems. Specifically, separating what I need to do (tasks) from what I need to repeat (routines), and scheduling routines like immovable blocks in my week.

The Task vs. Routine Distinction

Most to-do apps treat everything as a task. "Implement auth flow" sits next to "practice algorithms" in the same list. But these are fundamentally different:

Tasks are one-time items with a completion state. You implement auth, you check it off, it is done.
Routines are recurring behaviors you want to sustain. Algorithm practice is not "done." You want to do it every weekday morning.

Mixing them in one list creates a problem: routines compete with tasks for your attention, and tasks always win because they feel more urgent. "Fix the deployment bug" will always beat "practice dynamic programming" when they sit in the same list.

The fix: separate them completely.

Building a Routine Grid

I started with a simple weekly grid. Days across the top, time slots down the side:

         Mon    Tue    Wed    Thu    Fri    Sat    Sun
Morning  Algo   Algo   Algo   Algo   Algo   ---    ---
Lunch    Blog   ---    Blog   ---    Blog   ---    ---
Evening  Side   Side   Side   Side   ---    Side   Side
         Proj   Proj   Proj   Proj          Proj   Proj

The rules were simple:

Each block is 30 minutes minimum. Not two hours. Not "until I feel like stopping." Thirty minutes, then done. Most days I do more, but the commitment is only thirty minutes.
Morning routines before checking email. Algorithm practice happens first because once I open Slack, the day takes over.
Evening routines have a fixed start time. "After dinner" is too vague. "8:00 PM" is specific. I set an alarm.
Weekends are optional but structured. Saturday and Sunday have side project blocks but no algorithm practice. Rest days for specific routines prevent burnout.

The ONE Thing Filter

The hardest part is not scheduling routines. It is choosing which routines earn a slot. There are dozens of things I "should" be doing: LeetCode, system design study, open source contributions, blog writing, learning Rust, reading technical books.

I borrowed a filter from Gary Keller's "The ONE Thing": what is the single most important thing I can do right now that makes everything else easier or unnecessary?

For my goal of launching a SaaS product, the answer was clear: ship code daily. Algorithm practice supports long-term career growth. Blog writing builds an audience. But shipping code is the ONE Thing that moves the product forward.

So "Side Project" gets the most slots (5 evenings + 2 weekend days). Algorithm practice gets weekday mornings only. Blogging gets three lunch slots. Everything else either fits into existing slots or waits.

This filter prevents the common mistake of scheduling twelve routines and sustaining zero. Three to four core routines is the realistic maximum for most people with full-time jobs.

What I Track (And What I Don't)

I track two things:

Streaks. How many consecutive days I completed each routine. Not to guilt myself when the streak breaks, but to notice patterns. If my evening coding streak breaks every Thursday, that tells me Thursdays are bad for evening work. I adjust the schedule instead of forcing it.
Weekly completion rate. Out of my 15 scheduled routine blocks per week, how many did I actually do? My target is 80%, not 100%. Hitting 100% every week is unsustainable. Hitting 80% means I missed three blocks, which is normal life.

What I do not track:

Hours spent. Time in seat is not the same as progress.
Lines of code. Meaningless metric.
"Productivity scores." Gamification makes me optimize for the score, not the work.

The Results After Three Months

Before the system:

Side project commits: 2-3 per week, clustered on weekends
Algorithm practice: "when I feel like it" (roughly twice a month)
Blog posts: 0 per month

After three months:

Side project commits: 8-12 per week, spread across all weekdays
Algorithm practice: 5 days per week, 20+ minutes each
Blog posts: 2-3 per month

The total hours spent did not increase dramatically. What changed was distribution. Instead of eight hours on Saturday and zero on Wednesday, I spent one hour on five different days. The context retention alone made each session more productive.

Practical Tips for Starting

If you want to try this system:

Start with two routines, not five. Pick the two that matter most to your current goal. Add more only after two weeks of consistency.
Make the blocks small. Thirty minutes is better than two hours because you will actually do thirty minutes on a tired Tuesday evening. You will not do two hours.
Schedule around energy, not free time. If you are mentally sharp in the morning, put the hardest routine there. Side project coding after a full workday needs the easiest possible entry point (fix a small bug, write one test).
Track visually. A weekly grid where you can see filled vs. empty blocks at a glance is more motivating than a list of checkboxes. Something about seeing the pattern makes you want to keep it going.
Review weekly, not daily. Daily reviews create anxiety. Weekly reviews let you see the bigger pattern and adjust without overreacting to one bad day.

Tools for This System

You can do this with a spreadsheet. Seriously. A Google Sheet with days as columns and time slots as rows works fine for the first month.

If you want something more structured, I built this system into STACKFOLO, a Chrome new-tab dashboard. Its Routine Blocks feature lets you drag habits into a visual weekly grid with Morning/Afternoon/Evening/Anytime slots, track streaks, and separate routines from one-time tasks. There are 50+ habit templates for developers (algorithm practice, code reviews, blog writing, etc.) so you do not start from scratch.

But the tool matters less than the system. Separate tasks from routines. Schedule routines as blocks. Use the ONE Thing filter to choose which routines earn a slot. Track streaks and weekly completion. Review and adjust weekly.

The goal is not to fill every hour. It is to show up consistently enough that your side project stops feeling like a stranger's codebase every time you open it.

Building a Chrome Extension with Manifest V3: Lessons from STACKFOLO

STACKFOLO — Mon, 16 Mar 2026 13:42:09 +0000

Building a Chrome Extension with Manifest V3: Lessons from STACKFOLO

When we started building STACKFOLO, a new-tab dashboard for developers managing multiple side projects, the timing was unfortunate in one specific way: Chrome was in the middle of deprecating Manifest V2.

We had to build entirely on Manifest V3 from day one. No migration to worry about, but also no safety net of "just port this from MV2." Every decision had to work within MV3's constraints. Here is what we learned.

Why MV3 Changes the Mental Model

If you built Chrome extensions on MV2, you are used to background pages. A background page is a persistent JavaScript context that lives as long as the browser is open. You can cache data in memory, maintain open WebSocket connections, and count on your event listeners always being registered.

MV3 replaces background pages with service workers. Service workers are not persistent. Chrome terminates them when idle, typically after 30 seconds of inactivity. They wake up when an event fires, handle it, and go back to sleep.

This sounds like a minor architectural change. In practice, it rewires how you think about state management and background processing.

The Problem With In-Memory State

On MV2, you might write code like this:

// background.js (MV2) - this worked fine
let userProjects = [];

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'GET_PROJECTS') {
    sendResponse({ projects: userProjects }); // always available
  }
});

On MV3, userProjects will be empty every time the service worker wakes up from sleep. Any in-memory state is gone.

The fix is straightforward but requires discipline: never rely on service worker memory for persistent state. Everything that needs to survive across events must go through chrome.storage or an external database.

// background.js (MV3) - correct pattern
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'GET_PROJECTS') {
    chrome.storage.local.get(['projects'], (result) => {
      sendResponse({ projects: result.projects || [] });
    });
    return true; // keep the message channel open for async response
  }
});

That return true is easy to miss and causes subtle bugs where sendResponse gets called after the listener returns, silently failing.

Firebase Integration: The Auth Challenge

STACKFOLO uses Firebase for cloud sync (Pro feature). Firebase Auth works fine in content scripts and popup pages, but the service worker context presented a specific problem.

The Firebase Web SDK assumes a persistent JavaScript environment. When you call onAuthStateChanged, it sets up a listener that fires when auth state changes. In a service worker, that listener is gone every time the worker restarts.

Our solution was to avoid relying on onAuthStateChanged in the service worker entirely. Instead, we:

Persist the auth token manually using chrome.storage.local after login
Initialize Firebase with the stored token on each service worker wake-up
Handle token refresh explicitly rather than relying on Firebase's automatic refresh

// Simplified pattern for Firebase auth in MV3 service worker
async function getAuthenticatedUser() {
  const stored = await chrome.storage.local.get(['authToken', 'tokenExpiry']);

  if (!stored.authToken || Date.now() > stored.tokenExpiry) {
    // Token missing or expired, user needs to re-authenticate via popup
    return null;
  }

  // Use the stored token for Firestore requests directly
  return stored.authToken;
}

The popup page handles the actual Firebase Auth UI and login flow. Once authenticated, it stores the token in chrome.storage.local where the service worker can access it. The service worker never tries to maintain its own auth state.

This pattern is more verbose than the typical Firebase setup, but it works reliably under MV3's constraints.

Content Script Communication Patterns

STACKFOLO's AI Smart Save feature needs to analyze the current page content. That means the content script (which has DOM access) needs to talk to the service worker (which handles AI API calls).

MV3 makes this a bit more complex because of stricter message passing rules. Here is the pattern we settled on:

// content-script.js
async function saveCurrentPage() {
  const pageData = {
    title: document.title,
    url: window.location.href,
    description: document.querySelector('meta[name="description"]')?.content || '',
    // Extract main content for AI analysis
    bodyText: document.body.innerText.slice(0, 3000)
  };

  const response = await chrome.runtime.sendMessage({
    type: 'AI_SAVE_PAGE',
    payload: pageData
  });

  return response;
}

// service-worker.js
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'AI_SAVE_PAGE') {
    handleAISave(message.payload)
      .then(result => sendResponse({ success: true, data: result }))
      .catch(err => sendResponse({ success: false, error: err.message }));
    return true; // async response
  }
});

One thing MV3 is strict about: you cannot call chrome.tabs.executeScript from content scripts. All scripting API calls must go through the service worker. This bit us early on when we tried to inject helper code from a content script context.

AI Classification Architecture

The AI Smart Save feature is STACKFOLO's most complex piece. When you save a page, we want to automatically determine:

Which project this resource belongs to
A short purpose description (why you'd reference this)
A quality rating

Doing this inside a Chrome extension has two constraints that do not apply to regular web apps:

1. You cannot run AI models locally (practically speaking)

Chrome extensions run in a browser context with limited compute. While the Chrome AI APIs are improving, for production use we call an external API. The service worker makes the call.

2. The service worker has a strict timeout

Chrome enforces a maximum service worker lifetime. For AI API calls that can take 2-5 seconds, this is fine. But if we wanted to do bulk processing (saving 10 resources at once), we needed to be careful about chaining async operations.

Our architecture:

Content Script
    |
    | (page data)
    v
Service Worker
    |
    | (batched or single request)
    v
AI API (external)
    |
    | (classification result)
    v
Service Worker
    |
    | (write to Firestore)
    v
chrome.storage.local (cache)
    |
    | (message back)
    v
New Tab Page (UI update)

The new tab page is a Chrome Extension page (not a content script), so it has direct access to chrome.storage and can listen for storage changes to update the UI without going through the service worker.

// new-tab.js - listening for resource updates
chrome.storage.onChanged.addListener((changes, namespace) => {
  if (namespace === 'local' && changes.recentResources) {
    renderResources(changes.recentResources.newValue);
  }
});

This pattern keeps the UI responsive. The service worker does the heavy lifting asynchronously, and the UI reacts to storage changes rather than waiting for a message response.

The New Tab Page Is Different From Other Extension Pages

One thing that catches people off guard: chrome.newtab is not a standard API. Your extension provides a new tab by declaring it in the manifest:

{
  "chrome_url_overrides": {
    "newtab": "newtab.html"
  }
}

What is less obvious is that the new tab page behaves differently from popup pages in a few ways:

It loads fresh on every new tab open (no caching of the page state)
Chrome gives it slightly different permissions in some edge cases
Users can only have one extension override the new tab, so if you are replacing the new tab you are asking users to commit to your tool

That last point has UX implications. We put an onboarding step early in the flow that explains the new tab replacement and gives users an easy way to disable it. Extensions that hijack the new tab without explaining themselves get bad reviews.

Permissions: Ask for Less, Get More

MV3 introduced more granular permission controls. The principle is "least privilege," and Chrome will now warn users more prominently about extensions requesting broad permissions.

We made a deliberate choice to avoid tabs permission and use activeTab instead for most features. The difference:

tabs: Access tab information across all open tabs at all times
activeTab: Access the current tab only when the user explicitly invokes the extension

For AI Smart Save, the user clicks the extension icon (or uses the keyboard shortcut), which grants activeTab access at that moment. We do not need to read all open tabs passively.

This reduces the permission warning surface at install time, which measurably affects conversion from Chrome Web Store page to install.

What We Would Do Differently

Start with a clear storage schema. We iterated on our chrome.storage.local data structure several times, and each migration was painful. Treat your storage schema like a database schema. Version it from day one.

Write integration tests for the service worker lifecycle. Unit tests miss the class of bugs that only appear when the service worker restarts mid-operation. Write tests that explicitly terminate and restart the worker between operations.

Separate the extension logic from the UI logic early. We ended up with too much business logic in the new tab page initially, which made testing hard. The extension should be a thin layer. Logic belongs in the service worker or in shared modules.

Building on MV3 Today

MV3 is the present and future of Chrome extensions. The constraints are real, but they are workable once you internalize the service worker lifecycle.

The biggest mental shift: stop treating the extension like a long-running server process and start treating it like a collection of event handlers. Each handler should be stateless except for what it reads from storage.

If you are building a Chrome extension that needs persistent background processing, look into the offscreen API (MV3 adds this for use cases like audio playback that genuinely need a persistent context). For most extensions, the service worker model is sufficient once you stop fighting it.

STACKFOLO is the developer dashboard we built using these patterns. If you are managing multiple side projects and want to see how it handles AI resource classification in practice, you can try it for free.

Try STACKFOLO free on Chrome Web Store

My Developer Habit Tracking System: How I Use Routine Blocks to Ship Side Projects

STACKFOLO — Mon, 16 Mar 2026 05:03:07 +0000

My Developer Habit Tracking System: How I Use Routine Blocks to Ship Side Projects

I have started and abandoned more side projects than I can count. Not because the ideas were bad or because I lost motivation overnight. The pattern was always the same: I would work intensely for a few weeks, skip a couple of days, lose momentum, and never come back.

Last year I decided to figure out why. The answer was not about motivation or discipline. It was about the difference between tasks and routines.

The Task vs Routine Confusion

Most productivity systems treat everything as a task. "Build landing page" goes on the same list as "practice algorithms" and "review pull requests." But these are fundamentally different things:

Tasks are one-time actions with a clear endpoint. Build a landing page. Fix that auth bug. Write the README.
Routines are repeating behaviors that compound over time. Daily algorithm practice. Weekly code reviews. Morning planning sessions.

When I mixed them together, routines always lost. A task like "fix the payment bug" feels urgent. "Practice algorithms for 30 minutes" does not. So the routines got pushed to "later," and "later" became "never."

The moment I started tracking them separately, everything changed.

The Routine Blocks System

I call my approach "Routine Blocks" because it works like Tetris. Instead of a flat to-do list, I visualize my week as a grid of time slots and drop recurring blocks into them.

Here is what my weekly schedule looks like:

Weekly Routine Grid
═══════════════════════════════════════════════════════════
         Mon    Tue    Wed    Thu    Fri    Sat    Sun
Morning  [ALG]  [ALG]  [ALG]  [ALG]  [ALG]  [OSS]  [---]
         [PLAN]                              [BLOG]
Afternoon              [CR]          [CR]
Evening  [PUSH] [PUSH] [PUSH] [PUSH] [PUSH]
         [READ] [READ]               [READ] [READ]
═══════════════════════════════════════════════════════════

ALG  = Algorithm practice (30 min)
PLAN = Weekly planning session (Mon only, 20 min)
CR   = Code review on open source projects (45 min)
PUSH = Git push - commit something, anything (30 min)
READ = Technical reading - docs, articles, RFCs (20 min)
OSS  = Open source contribution (60 min)
BLOG = Write a dev blog post (90 min)

The key insight: these blocks are not tasks. I do not check them off and move on. They repeat every week, automatically. The question is never "should I do algorithm practice today?" but "it is Tuesday morning, algorithm block is up."

Why Visual Scheduling Beats To-Do Lists for Habits

Three reasons this grid format works better than a list:

1. You see the gaps. A to-do list hides the fact that you have nothing scheduled for Wednesday evenings. A visual grid makes empty slots obvious. If there is a gap, you can fill it or keep it intentionally empty for rest.

2. You see the overload. When I first filled in my grid, I realized I had packed every single evening slot. That was clearly unsustainable. The visual format made it obvious before I burned out.

3. You build spatial memory. After a few weeks, I stopped checking the schedule. Tuesday afternoon meant code review. It was automatic. The visual layout helped my brain create those associations faster than a text list ever could.

The ONE Thing Filter

The hardest part of routine blocks is deciding what goes on the grid. You cannot fill every slot, and not every habit matters equally.

I use a filter borrowed from Gary Keller's "The ONE Thing" philosophy. Before adding a routine block, I ask one question:

What is the ONE thing I can do consistently that would make shipping this project easier or unnecessary?

For my current side project (a developer tool), the answer was clear: the single most important routine was a daily Git push. Not because every commit is meaningful, but because maintaining the habit of touching code daily prevents the "I have not opened this project in two weeks" death spiral.

Everything else on my grid supports that core routine:

Algorithm practice keeps my problem-solving sharp so coding sessions are more productive
Code review exposes me to patterns I can apply in my own project
Technical reading prevents me from reinventing solutions that already exist
Weekly planning ensures I know what to work on during my Git push blocks

If a routine does not connect back to shipping the project, it does not earn a slot on the grid.

My Before and After

Here is what my side project output looked like before and after implementing this system:

Before (Q3 2025):

3 side projects started, 0 shipped
Average streak before abandoning: 11 days
No consistent coding schedule
Algorithm practice: "when I feel like it" (roughly twice a month)
Blog posts written: 0

After (Q4 2025 through Q1 2026):

2 side projects started, 1 shipped to production, 1 at 80% completion
Current coding streak: 67 days
Algorithm practice: 5 days/week (missed only 4 days in 3 months)
Blog posts written: 6
Open source PRs: 12

The numbers are not extraordinary. That is kind of the point. I did not become 10x more productive. I just stopped having zero-output weeks. The consistency compounded.

Practical Tips for Building Your Own Routine Blocks

If you want to try this system, here are the patterns that worked for me:

Start with 3 blocks, not 15. My first grid had 4 routines. I added more only after the first 4 felt automatic (about 3 weeks in).

Protect your morning slot. Whatever your highest-priority routine is, put it in the morning before work/meetings can steal the time. For me, that is algorithm practice. For you, it might be writing or reviewing code.

Use frequency tiers. Not everything needs to be daily:

Frequency tiers:
  Daily     → Git push, Algorithm practice
  Weekdays  → Technical reading
  2x/week   → Code review (Tue, Thu)
  Weekly    → Planning (Mon), Blog (Sat), OSS (Sat)
  Monthly   → Side project retrospective

Track streaks, not perfection. Missing one day is fine. Missing two days in a row is where habits die. I track current streak and longest streak for each routine. The goal is not 100% completion. It is avoiding two consecutive misses.

Separate the grid from your task list. This is critical. Your routine grid should live in a different place than your to-do list. If they are in the same view, tasks will crowd out routines again. I keep my task list in one view and my weekly routine heatmap in another.

The Tool I Use

Full disclosure: I ended up building the routine blocks system into STACKFOLO, the developer project dashboard I work on. It started as a spreadsheet, then a Notion template, and eventually became a feature because I wanted the routine grid right in my Chrome new tab where I would see it dozens of times a day.

The built-in version has a weekly heatmap, streak tracking, 50+ habit templates (algorithm practice, code review, pomodoro, and others), and time slot categories (Morning, Afternoon, Evening, Anytime). It also connects to the ONE Thing goal system, so each routine links back to a specific project goal.

But honestly, the system works with a spreadsheet too. The format matters less than the principle: separate your routines from your tasks, make them visual, and filter ruthlessly using the ONE Thing question.

If you have been struggling to maintain consistent habits around your side projects, try building a routine grid this week. Start with just three blocks. See if the consistency compounds the way it did for me.

If you want to try STACKFOLO's built-in Routine Blocks, it is free on the Chrome Web Store.

Try STACKFOLO free on Chrome Web Store →

Why Every Developer Needs a Project Dashboard

STACKFOLO — Sun, 08 Mar 2026 02:21:24 +0000

Why Every Developer Needs a Project Dashboard

You have 47 tabs open. Four of them are Stack Overflow answers you might need later. Two are GitHub repos you were comparing last Tuesday. One is a tutorial you bookmarked three months ago and forgot about. And somewhere in that mess is the actual thing you were working on.

If this sounds familiar, you are not alone. Developers who juggle multiple side projects deal with this chaos daily. The problem is not a lack of discipline. It is a lack of structure.

A developer project dashboard can fix that.

The Real Cost of Scattered Projects

Let's talk about what happens when your projects live across a dozen different places.

Tab Hell Is Real

According to a 2024 study from Carnegie Mellon University, knowledge workers keep an average of 25-40 browser tabs open at any given time. Developers tend to be on the higher end of that range because every project involves multiple contexts: the repo, the docs, the deployment dashboard, the design file, the issue tracker.

The problem with tab hell is not just visual clutter. It is the cognitive cost of context switching. Every time you scan through tabs trying to find where you left off, you burn mental energy that could go toward actual coding. Research on task switching suggests it takes roughly 23 minutes to fully refocus after a context switch. Even small interruptions, like hunting for the right tab, add up.

Bookmark Chaos

Bookmarks were supposed to solve this. In practice, they become a graveyard.

You bookmark a useful API reference with good intentions. It joins a folder with 200 other links. Some are outdated. Some are duplicates. Most are impossible to find because you saved them with the page's default title instead of something descriptive.

Browsers were built for navigating the web, not for organizing your development workflow. Bookmark folders are flat, static, and disconnected from the projects they belong to. There is no way to say "this link belongs to my e-commerce side project" and have it show up alongside your todos, commits, and deployment status for that project.

Resources Scattered Across Tools

Here is a typical developer's project ecosystem:

GitHub for code and issues
Notion or Google Docs for notes and specs
Figma for design references
Vercel or Netlify for deployments
Slack or Discord for team communication
Twitter/X bookmarks for inspiration and tutorials
YouTube playlists for video tutorials

Each tool does its job well. But none of them give you a single view of what matters for a specific project right now. You end up playing a daily game of "which app was that in?" and it is exhausting.

What a Project Dashboard Actually Solves

A developer project dashboard is not another project management tool. You do not need a replacement for Jira or Linear for your side projects. What you need is a single place that ties together the context around each project.

1. One View Per Project

Instead of mentally mapping "these 8 tabs are for Project A and those 6 are for Project B," a dashboard gives each project its own space. Your resources, links, notes, and progress all live together. When you switch projects, you switch contexts cleanly.

This sounds simple, but the impact is significant. No more searching. No more "wait, which tab was that?" You open your project view and everything is there.

2. Reduced Context Switching

When your project context is pre-loaded, you eliminate the startup cost of getting back into flow. You do not need to reconstruct your mental model of where things are. The dashboard remembers so you do not have to.

For developers managing 2-5 side projects alongside a day job, this is the difference between making progress on a side project in a 30-minute window versus spending 15 of those minutes just finding where you left off.

3. Resources That Stay Organized

The best project dashboards let you save resources directly to a project context. Found a useful tutorial? Save it to the relevant project, not to a generic bookmark folder. Need to reference an API doc? It is right there with the rest of the project's resources.

This project-first organization means resources are useful when you need them, not buried in a global list you will never scroll through.

4. Visibility Into Your Own Progress

When you are working on multiple projects, it is easy to lose track of which ones are moving forward and which are stalling. A dashboard that shows your recent activity, commits, or task completion gives you an honest picture of where your time is going.

This is not about productivity guilt. It is about making intentional choices. If you can see that you have not touched Project C in three weeks, you can consciously decide to either pick it back up or set it aside.

What to Look for in a Developer Project Dashboard

Not all dashboards are built for developers. Many productivity tools are designed for managers or teams, not for someone who needs quick access to a GitHub repo, a localhost URL, and an API reference at the same time.

Here is what matters:

Project-based organization: Resources, links, and notes grouped by project, not by type
Low friction to save resources: If it takes more than two clicks to save a link to a project, you will stop doing it
Browser-native: Developers live in the browser. A dashboard that shows up in your new tab is always accessible without opening yet another app
Integration with your actual workflow: GitHub activity, commit history, and other signals that reflect real progress
Speed: A dashboard that takes 3 seconds to load defeats the purpose. It needs to be instant

How STACKFOLO Fits In

This is exactly the problem we built STACKFOLO to solve.

STACKFOLO is a Chrome extension that turns your new tab into a project dashboard. Each project gets its own space with resources, links, and context. The AI Smart Save feature automatically categorizes web resources into the right project when you save them. Your GitHub commit timeline shows up alongside your projects so you can see real activity at a glance. And because it is a new tab extension, it is always one keystroke away.

The free plan gives you up to 100 saved resources and 30 AI-powered saves per month, which is enough to try the workflow and see if it clicks for you.

No more tab hell. No more bookmark graveyards. Your projects, organized in the one place you already open dozens of times a day.

Wrapping Up

The developer project dashboard is not a new category of tool. It is a recognition that developers who build multiple things need a better home base than 40 open tabs and a bookmarks folder they never check.

If you have been feeling the friction of scattered projects, the fix is not "be more organized." It is having a system that makes organization the default.

Try STACKFOLO free on Chrome Web Store