DEV Community: STACKFOLO

I Spent 35 Seconds Opening the Same 8 Tabs Every Morning. For a Year.

STACKFOLO — Wed, 27 May 2026 05:08:33 +0000

I Spent 35 Seconds Opening the Same 8 Tabs Every Morning. For a Year.

I timed it once, on a Tuesday, because I had a feeling it was worse than I thought.

GitHub repo for the SaaS I am building. Vercel dashboard. Supabase console. Linear board. The doc with the architecture notes. Stripe test dashboard. localhost:3000. Slack for the client work that pays the bills.

Eight tabs. 35 seconds of Cmd-T, click, paste, enter, Cmd-T, click, paste, enter. Every morning before I could write a single line of code.

35 seconds is nothing. Until you multiply.

The Math I Tried Not to Do

Let me actually do the math, because the small numbers in this kind of thing are the ones that hide.

35 seconds per morning to open the SaaS project tabs
5 working days per week
~50 working weeks per year
= 145 minutes per year. About 2 hours and 25 minutes.

That is not the bad number. The bad number is what happens when I switch to my open source library at 2pm.

That is another 4 to 5 tabs. Another 20-ish seconds. And by 4pm when I check in on the client work, that is another 6 tabs and another 25 seconds.

A conservative day was about 90 seconds of "opening tabs to get to the work." Over a year, that is closer to 6 hours of pure tab-opening labor. None of it is the work.

The worse part was not the time. The worse part was the inertia. By the time tab six is loading, I have already looked at one notification, half-read a Slack message, and forgotten what I actually wanted to do first.

What I Tried, In Order

I am a developer. I do not just accept manual tab-opening. I tried things.

Chrome bookmark folders. I made a folder called "SaaS startup." I right-clicked it and chose "Open all." This actually works. The problem: every URL opens in a new tab in the current window, on top of whatever was already there. By Thursday I had 47 tabs and no idea which ones belonged to which project. Worse, when I closed Chrome and reopened, the project context was lost. The folder is a launcher, not a workspace.

OneTab. Saves all tabs to a list, restores them as a group. Good for archiving. Bad for daily morning startup because it merges with whatever I had before, and the saved groups become a graveyard fast. Mine had 200+ entries after three months. Restoring one was as much friction as just typing the URLs again.

Chrome session restore. I tried just never closing the browser. Mac sleep handles it. But updates, restarts, crashes, and accidentally hitting Cmd-Q during a 4pm yawn destroyed this strategy at least once a month. Also, my MacBook fans got loud enough that I felt morally obligated to actually close things sometimes.

A bash script + AppleScript. I am embarrassed to say I wrote this. It opened Chrome with specific URLs. It worked. But editing the URL list required opening the script, finding the right line, and pasting. And it could not handle "I want a different preset for Wednesday's client work." Adding a new preset meant duplicating the script, renaming it, and remembering which one was which.

Workona, Toby, Sidebery. These are the workspace extensions. They are good. I used Workona for two months. The reason I stopped: it wanted to be my whole browser. New-tab override, sidebar, persistent UI. I wanted a launcher, not a workspace OS. Personal taste, not a judgement.

The pattern I noticed across all of these: the tool either does too little (bookmarks) or wants to take over the browser (workspace apps). I just wanted a button I could click that would open my eight morning tabs and then get out of my way.

What I Actually Wanted

Sitting with it for a while, I wrote down what a sane morning-launch system needed:

A preset is a named set of URLs.
Clicking the preset opens all the URLs as a new group, not dumped on top of whatever else is open.
I can have multiple presets per project (because "morning startup" and "deploy day" need different tabs).
I can have project-agnostic presets too, like "AI tools" or "design references."
Editing the preset takes seconds, not a context-switch into a separate app.
It lives somewhere I am already going to be, like the new tab, so it does not become a thing I forget to open.

Number six is the one that I kept getting wrong with the other tools. The launcher needs to live where my eyes already go. Otherwise I forget it exists and start typing URLs again by habit.

The Setup That Stuck

I am the lead developer on STACKFOLO, which is a Chrome extension I have been building partly for this exact problem. I am going to describe the workflow honestly here. Use the same idea anywhere, the extension is just the implementation that fit how I work.

The new tab is the dashboard. Each project has its own card. On each card, there is a Quick Open section with multiple preset groups.

My SaaS project card has three presets:

Daily startup: GitHub repo, Vercel, Supabase, Linear board, the architecture doc, Stripe test, localhost:3000, internal Slack channel.
Deploy day: GitHub releases page, Vercel deployments, status page, customer Slack channel, the monitoring dashboard.
Customer call prep: CRM, the specific customer's account, the support ticket history, my prep doc.

Three buttons. Each one opens its set in a new window so the context stays clean. The "Daily startup" group I now hit once at 9am, and within two seconds I am where I need to be. The 35 seconds is back in my day.

I also have one global Quick Open with five slots that are not tied to any project. Mine currently holds: my email, my calendar, my note inbox, Claude, and the writing app I draft posts in. These are the things I open across every project, and pinning them in the global slot meant I stopped re-pinning them inside each project's preset.

Total time to set this up across four projects and the global slot: about 25 minutes one Saturday morning. Total time saved since: I have not measured it but my morning routine starts with the work now, not with the opening of the work.

What Actually Changed

Three things shifted that I did not expect to shift.

The project I was avoiding became easier to start. I had one side project I kept putting off because "getting set up" felt expensive. It was an open source library with five very specific tabs I needed (GitHub, npm page, CodeSandbox, the test report dashboard, the issues triage page). Once those five lived behind a single button, I opened the project three times in the next week instead of two times in the previous month. The friction was the whole reason I was avoiding it.

I stopped polluting one window with three projects. Because each preset opens in its own window, I stopped having one mega-window with 38 tabs across 4 projects where I could never find anything. The window is the project now.

I started editing my presets weekly. When a tool I need changes, I update the preset within the same minute. The cost of editing is so low that I treat it like a living config. Before, my "system" was implicit and lived in my head, which means it never actually adjusted to what I was doing.

If You Try This

You do not need my exact setup. The idea is portable:

Pick the 5 to 8 URLs you open at the start of every working session for one specific project.
Put them somewhere clickable as a group.
Make sure that group opens in a new window so it does not merge with whatever else is going on.
Edit the group when your workflow changes, not "later."

If you want it to live on your new tab next to the actual project, STACKFOLO is on the Chrome Web Store and the free plan covers up to 5 projects with multiple presets each, which is enough for most people testing the idea. If you build your own, send me what you ship.

The 35 seconds was never about the seconds. It was about the small repeating friction that quietly decided which projects I worked on and which ones I avoided. Removing it changed which projects I actually finished.

How to Make a Developer Learning Habit Actually Stick

STACKFOLO — Fri, 22 May 2026 01:02:51 +0000

How to Make a Developer Learning Habit Actually Stick

How many times have you decided to learn something this year, and quietly stopped a week or two in?

A new framework. A systems design course. Forty-five minutes of algorithm practice every morning. The first few days feel great. You are focused, you are making notes, you can see the progress. Then a deadline lands, you skip one day, then two, and by the end of the second week the habit is gone. The course tab is still open. The streak is at zero. You are not sure when it ended because there was never a clear moment where you decided to quit.

If that pattern feels familiar, you are not undisciplined. You are running a learning routine on top of a job that already fills most of your attention. The routine did not fail because you are lazy. It failed because nothing was holding it in place when the busy week arrived.

This post is about what actually holds a learning habit in place. Not motivation, not a new productivity philosophy. A small set of structural choices that let a routine survive a hard week instead of competing with it.

Why Learning Routines Are Harder Than They Look

A learning habit has three properties that make it fragile, and most tools ignore all three.

It has no deadline. A task like "fix the staging deploy" has a date attached, so it pushes its way to the front of your day. "Practice recursion for 30 minutes" has no date. It is important but never urgent, and important-but-not-urgent work is exactly what gets dropped first when the week gets tight.

It produces no visible artifact for a long time. When you ship a feature, you can see it. When you spend three weeks learning Rust, you mostly have a vague sense that you understand more than before. Without a visible record, your brain quietly concludes that nothing happened, and a habit that feels like nothing is easy to skip.

It competes with work that pays you today. Your day job has real consequences attached. Your learning routine has consequences that are real but a year away. When the two collide on a Tuesday evening, the one with the closer consequence always wins.

So a learning habit that depends on willpower is fighting all three of these every single day. That is not a fair fight. The fix is to stop relying on willpower and put structure where willpower used to be.

Four Structural Fixes That Hold

1. Give the routine a fixed place in time, not a fixed amount of effort

"Study 30 minutes a day" is a goal, not a plan. A plan answers the question when. "Algorithm practice, weekdays, 7:30 to 8:00, before standup" is a plan, because it names a slot that already exists in your day.

The reason this matters: a routine without a time slot has to be re-decided every day, and every re-decision is a chance to skip. A routine with a slot only has to be decided once. After that you are not choosing whether to study, you are just doing the thing that happens at 7:30.

This is why STACKFOLO models routines on a 7-day by 24-hour timetable grid instead of a flat checklist. You drag a routine onto an actual block of the week, and it stays there. A "Now line" moves across the grid through the day, so the current block is always visible. The routine stops being an abstract intention and becomes a place on a calendar you can point at.

2. Track the streak, because the streak is the only artifact you get

Since a learning habit produces no early visible output, you have to manufacture one. The streak is that artifact.

A streak is not about gamification or pressure. It is a single honest number that answers the question your brain keeps asking: am I actually doing this, or do I just think I am? Seven days in a row is proof. A row of completed day-dots for the week is proof. Without that proof, two good weeks and two bad weeks feel identical in memory, and you lose the ability to tell whether the routine is working.

STACKFOLO tracks a streak count and a 7-day completion view for every routine, so the record exists whether or not you remember the individual days. On a week you fall short, the gap is visible and specific instead of a vague sense of failure. Visible gaps are recoverable. Vague guilt is not.

3. Build the routine from the goal, not from a generic template

Most habit advice hands you someone else's routine and tells you to adopt it. That rarely survives contact with a real schedule, because the routine was not built around what you are actually trying to learn.

A learning routine should be derived from the goal. If the goal is "be comfortable with system design interviews in three months," the routine is not "study every day." It is a specific set of recurring behaviors: read one design breakdown on Monday and Thursday, do one mock problem on Saturday, review notes on Sunday. The routine is the goal broken into things small enough to repeat.

STACKFOLO's AI routine recommendation does this step for you. You describe the goal, and it proposes a concrete set of habits with sensible frequencies. You are not staring at an empty habit screen trying to invent a study plan. You start from a draft and adjust it, which is a much lower-friction way to begin.

4. Let the schedule be built around your real constraints

The last reason learning routines collapse is that they are placed at times you were never realistically going to use. A 6:00 AM study block is not a plan if you are not a 6:00 AM person. It is a wish.

A routine has to fit the hours you actually have. That means placing learning blocks around your wake time, your sleep time, and your working hours, in the gaps that genuinely exist. STACKFOLO has an AI timetable feature for exactly this: you give it your wake time, sleep time, working hours, and a short description of what you want to fit in, and it places the routine blocks into the open slots on the grid. You can then drag anything that does not feel right. The point is to start from a schedule shaped by your real day instead of an idealized one.

What a Week Looks Like When This Holds

Here is the difference in practice. Before, a learning routine lived as a vague intention: I should study more. It had no slot, no record, and no connection to a goal, so it lost every collision with a real deadline.

After, the same routine is a block at 7:30 on weekday mornings, it has a streak count that tells the truth about whether you showed up, it was generated from an actual goal, and it sits in a gap that genuinely exists in your day. None of those four things is dramatic on its own. Together they move the routine from "thing I rely on willpower for" to "thing that is just part of the week."

You will still miss days. A hard sprint, travel, a sick kid, all of it still happens. The difference is that a missed day is now a visible gap in a streak you can see, not the silent start of another abandoned habit. A visible gap gets closed. A silent one becomes a quit you never noticed.

If you want a place to keep your goals, routines, and learning resources together in one view, STACKFOLO is a Chrome extension built around exactly that loop: set a goal, turn it into routines on a weekly timetable, and track the streak as you go. It also handles the related problem of keeping your study resources organized instead of scattered across browser bookmarks, so the material you are learning from lives next to the routine that uses it.

A learning habit does not need more motivation. It needs a fixed slot, an honest record, a goal it is connected to, and a schedule shaped by your real day. Put those four in place and the habit stops depending on how you feel on any given Tuesday.

Try STACKFOLO free on Chrome Web Store → https://chromewebstore.google.com/detail/stackfolo/gakjkkjgbekgmdkijbgdpdmmhenjejpb?utm_source=devto&utm_medium=article&utm_campaign=2026-05-w21-winner-stack&utm_content=blog21-cta-bottom

The Week-3 Wall: Why Your Side Project Stalls (And 4 Workflow Fixes That Actually Hold)

STACKFOLO — Tue, 19 May 2026 05:02:42 +0000

The Week-3 Wall: Why Your Side Project Stalls (And 4 Workflow Fixes That Actually Hold)

Have you ever started a side project full of energy, only to lose all motivation by week 3?

You know the feeling. Week 1 was electric. You sketched the idea on a napkin, opened a fresh repo, and shipped a working prototype on a Saturday afternoon. Week 2 still had pulse. You hit a few bugs, but solving them felt like part of the fun. Then week 3 arrived. The tabs you needed to reopen got buried. The vague "finish the MVP" goal stopped giving you a finish line. A weekday slipped by without a commit, then two, then a week. The project did not die in a single moment. It quietly fell off your radar.

This is the week-3 wall, and almost every side-project developer hits it. The frustrating part is that it is rarely a motivation problem. It is a workflow problem wearing a motivation costume.

What actually happens at week 3

In my experience, four invisible costs pile up between weeks 1 and 3:

The context restoration tax. Every return to the project costs 20 to 30 minutes of re-opening tabs, finding the right Notion page, the dashboard, the staging URL, the Figma file, the GitHub PR. By week 3, that tax feels heavier than the work itself.
The vague-goal fog. "Ship the MVP" sounded like a goal in week 1. By week 3, you cannot see whether you are 40 percent or 70 percent done. Without a visible finish line, the brain stops queueing the work.
The motivation cliff. Weeks 1 and 2 run on novelty. Week 3 needs habit, and habit takes deliberate installation. If you wait for motivation to come back, it does not.
The invisible-progress trap. On low-energy days you might still push a tiny commit or skim a doc, but those wins evaporate. Without a visible trail, you only remember the missed days.

Most productivity advice tries to fix this from the willpower angle. Wake up earlier. Want it more. Read another book about deep work. That rarely works, because the problem is structural. The friction is built into how your tools are scattered.

The four fixes below are the ones that actually held my projects together past week 3. I happen to build them into STACKFOLO, our Chrome extension, but the patterns work even if you stitch them together by hand.

Fix 1: Kill the context restoration tax with one-click project presets

The single biggest reason side projects stall is that returning to them is expensive. You open a new tab, try to remember the repo name, fish for the staging URL in Slack DMs, hunt for the Vercel dashboard. Each step is a tiny decision, and decisions are where momentum leaks.

The fix is to pre-define every project as a workspace, not as a checklist of bookmarks. For each side project, write down the 4 to 8 URLs you always need open: the repo, the production URL, the staging URL, the analytics dashboard, the design file, the docs. Then bind them to a single click.

In STACKFOLO we call this Quick Open with Service Presets. You can group URLs into named presets per project ("work mode", "deploy mode", "review mode") and open the whole group with one click. Globally pinned presets sit on your new tab so they are never more than a single keystroke away.

The goal is not the feature, it is the principle. If returning to your project costs more than five seconds, you will eventually stop returning. Cut that cost and a tired Tuesday evening becomes a viable work session again.

Fix 2: Turn "ship the MVP" into 8 to 12 visible milestones

Week 3 is when vague goals turn into vague guilt. "Ship MVP" was inspiring while it was new. By the time you have spent three weekends on it, you cannot tell if you are halfway done or 80 percent done, and the not-knowing is exhausting.

The fix is to break every side-project goal into 8 to 12 concrete milestones with rough dates. Each milestone should be small enough to finish in one or two evenings, and specific enough that you cannot fake it. "Build auth" is not a milestone. "User can sign up with Google and see a stub dashboard" is a milestone.

In STACKFOLO this is the Goals view, and we added an AI WBS generator so you can paste a vague goal like "launch a Notion alternative for indie hackers" and get a sane first-draft milestone list back in under a minute. The AI does not replace your judgement, but it gets you to a workable plan in one sitting instead of three weeks of stalling.

Whatever tool you use, the principle is the same. A side project without a milestone trail will always feel further from the finish line than it actually is. Make the progress visible and your brain stops treating the project as a black box.

Fix 3: Install a tiny daily habit before motivation runs out

Weeks 1 and 2 run on novelty. Week 3 needs habit. If you wait until you no longer feel like working to install a routine, the routine never gets installed.

The pattern that worked for me is what I call the "daily 20". Twenty minutes per weekday, scheduled at a specific time, on a single side project. Not two hours on Saturday. Not whenever you happen to feel like it. A specific 20-minute slot, reserved like a meeting with yourself.

Twenty minutes feels embarrassingly small. That is the point. The bar is low enough that you cannot reasonably skip it, and once you sit down, half the time you keep working anyway. The other half, you logged a 20-minute commit and kept the streak alive. Both outcomes beat the alternative, which is another lost weekday.

In STACKFOLO this lives in Habits and Routines, with a 7-day-by-24-hour grid so you can literally drop your "daily 20" onto a Tuesday at 8:30 PM and see it sitting there every time you open a new tab. Streaks and week dots give you a tiny dopamine hit on completion. Again, the principle outranks the feature. Pick a time, defend it, and make it visible.

Fix 4: Make low-energy progress visible so it actually counts

The last invisible cost is the most demoralizing one. On low-energy days you might still push a 5-line commit, fix a typo in the README, or skim a doc you needed. Real, useful work. Then a week later you cannot remember any of it, and the project feels like it has been stuck for ages.

The fix is a visible progress trail. Even a tiny one. You need a place that quietly says "you shipped something on Monday, Tuesday, Thursday, and Sunday last week" without you having to assemble that picture from memory.

For developers, GitHub commits already make a great signal, but they are buried inside GitHub itself. Pulling them onto your daily landing surface changes the psychology. In STACKFOLO we surface a per-project GitHub commit timeline on the side panel and new tab, so the moment you open a tab you see green dots from yesterday. Even a one-commit day reads as momentum.

You can do the same without our extension. Pin your GitHub profile contribution graph as your new tab. Drop a wall calendar next to your monitor and put an X for every day you shipped anything, even small. The mechanism does not matter as much as the principle: low-effort days have to be allowed to count, or you will keep telling yourself the project is stalled when it is not.

The week-3 wall is not about you

Look at the four fixes together. None of them are about discipline, willpower, or wanting it more. They are all about reducing structural friction:

One-click presets remove the 30-minute restart tax.
Visible milestones remove the fog of "how close am I".
A scheduled tiny habit removes the dependency on motivation.
A visible progress trail removes the feeling of going nowhere.

Do any one of them and your odds of pushing past week 3 go up. Do all four and the wall stops being a wall. It becomes a normal week with a tiny commit log.

You do not need our extension to apply any of this. Use whatever stack you already trust. The point of the framework is that side projects fail at week 3 because of how your workflow is arranged, not because something is wrong with you. Rearrange the workflow and the same brain, on the same Tuesday evening, ships the next milestone.

If you want all four pieces in one place, that is what we are building.

Try STACKFOLO free on Chrome Web Store →

Quick Open with Service Presets, Goals with AI WBS milestones, Habits and Routines, and a per-project GitHub commit timeline. Free plan covers 5 projects, 100 archives, and 30 AI calls a month, which is enough to test the week-3 wall idea on one real project.

Why Your Side Projects Die After 3 Weeks (And How to Keep Them Alive)

STACKFOLO — Thu, 14 May 2026 05:03:36 +0000

Why Your Side Projects Die After 3 Weeks (And How to Keep Them Alive)

Have you abandoned a side project this year?

You are not alone. I have a folder on my laptop called archive/ that I do not open anymore. Inside it are seven repositories. Each one started with a clean README, a working dev environment, and a real plan. Each one stopped getting commits sometime around week three.

If that sounds familiar, this is for you. I have been talking with other side-project builders for a while now, and the pattern is almost embarrassingly consistent. Week one is excitement. Week two is momentum. Week three is when it goes quiet. By week four, the project is on the shelf next to all the other ones.

It is not because you ran out of ideas. It is not because the idea was bad. The death of a side project is a structural problem, and once you see the structure, you can do something about it.

What actually happens at week 3

I used to think I was just lazy. That was the easy explanation. Then I started tracking what I did every day, and the data told a different story.

There are three failure modes, and they almost always happen together.

1. Context switching cost. Your side project lives in Notion. Your tasks live in a Trello board you set up the first weekend. Your design references are in browser bookmarks somewhere. Your code is in a folder you have to dig for. By week three, just sitting down to work on the project costs you fifteen minutes of "wait, where was I?" before you write a single line of code. That cost compounds. Eventually it is cheaper to scroll Twitter.

2. Priority drift. A new idea shows up around week three. It always does. The new idea has the shine the current project has lost, because you have not yet hit any of its hard parts. You start telling yourself you will "switch over for a week, then come back." You do not come back. You start a third project. The cycle repeats.

3. Tooling fatigue. You spent the first weekend setting up the perfect stack. New framework, new linter config, new project template, new task manager. By week three, the tooling has not actually helped you ship anything. It has just become more surface area to maintain. You quietly resent it.

The thing none of these failure modes have in common is "I lost interest." Interest is downstream. The structure killed the interest.

The conversation I keep having with myself

The honest version sounds like this:

"Did I work on it today? I do not actually remember. Is the task list current? Probably not. What was I doing last? Let me check the commits. Wait, I have not pushed in five days. Was that intentional or did I just stop?"

If you have had a version of this conversation, you know how draining it is. The problem is not that you lack discipline. The problem is that nothing in your environment is helping you remember why you started, or where you left off, or what is next.

I tried writing a paper journal. I tried a Notion dashboard with rollups. I tried a calendar that I respected for nine days and then ignored. They all failed for the same reason: they were extra steps. They lived somewhere I did not naturally go.

So I changed the approach. Instead of finding the right tool, I asked: what is the single screen I already open ten times a day, no matter what? The answer was obvious. Every time I opened a new tab in Chrome, that was a free, unforced touchpoint with my own attention.

That is the screen that needed to do the work.

The small system that finally kept mine alive

I am going to describe a system rather than sell a tool, but I will be transparent: I build STACKFOLO partly because I needed this system to exist for myself. The principles below are what matter. You can implement them with whatever stack you like.

1. Make the project unforgettable

Your project needs to be the first thing you see when you open a browser tab. Not buried in a Notion sidebar. Not in a folder you have to expand. Visible.

I put my active projects on my new tab page in a grid. Five tiles. Color coded. Each one has a status, a next task, and a one-click "open everything" button that loads the local dev URL, the GitHub repo, and the design doc into a tab group. The cost of resuming a project dropped from fifteen minutes to about three seconds.

If you cannot put it on your new tab, put it as your wallpaper. Put it as your terminal MOTD. Put it somewhere it cannot hide.

2. Capture today before you forget today

Every project I have killed had the same forensic evidence: I stopped logging what I did. Not what I planned. What I did.

I now do a two-minute daily log at the end of each work session. Mood, one-line summary, what I shipped, what blocked me. That is it. Here is roughly what it looks like in my system, stored as a small JSON record per day:

{
  "date": "2026-05-14",
  "project": "stackfolo",
  "mood": "focused",
  "summary": "Wired up the daily log AI summary. Refactor still pending.",
  "shipped": ["daily-log endpoint", "telemetry guard"],
  "blocked_by": ["AI prompt eats too many tokens, need to chunk"]
}

The format does not matter. The frequency does. When week three hits and you cannot remember why you cared, you can scroll back and read past-you explaining it. That is the rope that pulls you out.

3. Convert intention into a routine, not a goal

"Ship the MVP" is not a habit. "Work on the side project for ten minutes after my morning coffee" is a habit. The first one is a wish. The second one shows up on a calendar.

I added a single recurring routine block: ten minutes, every weekday, before the workday started. That is it. Ten minutes. The rule is to open the project, look at the daily log, pick the smallest next task, and either do it or write down exactly what is blocking it. Most days I run over and do thirty minutes. Some days I do the minimum and feel fine about it.

This is the move that broke me out of the week-three pattern. The streak does the motivation. You do the showing up.

4. Make progress visible without effort

Open your GitHub profile. The contribution graph is doing real work on your psychology, but only if you are actually committing. I keep a unified timeline of every commit across every account and every project on the same dashboard I use to plan. When the graph is green, the project breathes. When the graph goes flat for two days, I notice on day three, not week three.

You do not need a tool to do this. A weekly cron that emails you your commit count is enough. The point is: instrument the thing before it goes wrong, not after.

What changed for me

I did not finish every project. I am not going to pretend that. But the abandonment rate dropped from "almost everything" to "the ones that genuinely deserved to die." The signal got cleaner. When I quit a project now, I quit it on purpose, with a written reason, and I do not feel the same guilt I used to.

Week three is still the test. But the test is now passable, because the system carries the part of you that would have forgotten.

If you want a single browser-based starting point that ties the new tab dashboard, the daily log, and the routine streak together into one place, try STACKFOLO free on the Chrome Web Store. It is free for the first five projects, which is more than enough to test whether the new-tab-as-hub approach works for you.

And if it does not? Build the four habits anyway. The habits are the thing. The tool is just the rope.

Multi-Account GitHub Without Losing Your Mind: Personal, Work, and Client Repos in One Place

STACKFOLO — Mon, 27 Apr 2026 15:03:15 +0000

Multi-Account GitHub Without Losing Your Mind: Personal, Work, and Client Repos in One Place

I have three GitHub accounts.

One personal, where my side projects live. One work, where my day job pushes commits. One client, opened last summer when a contract required me to commit from a separate identity for IP reasons.

Every one of those accounts has activity that matters. Every one of them produces commits I want to see. And for a long time, my workflow for tracking what I was actually building looked like this: open three tabs to three github.com profiles, scroll, sigh, close them, forget what I was doing.

If you have ever pushed to the wrong remote, opened a PR from the wrong account, or stared at a green commit graph wondering which account it belonged to, this is for you. Here is the system I landed on.

The three problems with multiple GitHub accounts

Multi-account GitHub does not break in obvious ways. It breaks in slow, low-grade ways that drain attention.

1. The auth problem. SSH keys, PATs, credential helpers. Every CLI tool wants to know which identity it should use. The first time you push to a personal repo from your work machine and watch your work email show up in the commit log, you start to care about this.

2. The visibility problem. GitHub does not give you a unified view across accounts. You can star repos, follow people, but the activity graph, the contributions calendar, the recent push list, those are all per-account. If your work is split across three accounts, no single page on github.com shows you what you actually did this week.

3. The context problem. When you context-switch from a client repo to a side project to a work feature branch, the cognitive cost is not just remembering the codebase. It is remembering which account you are signed into, which terminal has which SSH agent, which directory has which .gitconfig override.

I solved each one separately, and then I solved the visibility problem properly with a tool I will mention at the end.

The auth problem: per-directory git config

The classic fix, and still the best. SSH config aliases plus includeIf in ~/.gitconfig.

In ~/.ssh/config:

Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal

Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work

Host github.com-client
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_client

Then clone with the alias instead of plain git@github.com::

git clone git@github.com-personal:myname/sideproject.git
git clone git@github.com-work:org/repo.git

For the email and username, I use directory-scoped configs. In ~/.gitconfig:

[includeIf "gitdir:~/code/personal/"]
  path = ~/.gitconfig-personal

[includeIf "gitdir:~/code/work/"]
  path = ~/.gitconfig-work

[includeIf "gitdir:~/code/client/"]
  path = ~/.gitconfig-client

Each .gitconfig-{role} file sets user.name, user.email, and user.signingkey. The trailing slash on the path matters. So does the directory layout. Every repo lives under one of three top-level folders, no exceptions. If I clone something to my Desktop or ~/Downloads/tmp, it falls back to the default identity, which I set to my personal one with a flashing-red prompt to remind me to move it.

This does not require any CLI wrapper or extension. It is just git, and once it is set up, it stays out of your way.

The visibility problem: stop opening three GitHub tabs

For a year I just opened three tabs.

github.com/personal-username, github.com/work-username, github.com/client-username. Click profile, scan recent activity, switch tab, repeat. If I wanted to see what I had pushed across all of them this week, I clicked through to each contributions calendar.

What that workflow misses is that the question I actually have is rarely "what did personal-me do." It is "what did I do." The account boundary is an artifact of how GitHub bills and authenticates, not of how my brain organizes work.

What I needed was a feed that pulled from all three accounts and showed me commits regardless of which identity made them. Plus enough metadata to recognize which side project, which client engagement, which work area each commit belonged to.

I tried a few things before settling.

A daily standup script. A bash script that ran gh api against three accounts and printed the last 24 hours of commits into a markdown file. Worked, but only ran when I remembered to run it, and the output was a wall of text I never actually read.

GitHub's REST events feed. You can pull /users/{username}/events for each account and merge them. Powerful, but you are now writing a GitHub client, and I did not want to maintain that for myself.

A self-hosted dashboard. I started building one. Got 60% there. Got bored. The repo still exists. I have not pushed to it in seven months.

The thing that finally stuck was tying the GitHub feed into the dashboard I already had open every time I opened a new browser tab.

The dashboard that already opens 40 times a day

About six months ago I started using STACKFOLO, a Chrome extension that turns the new tab into a project hub. Disclosure: I now help with the project. The reason I started using it was a different problem (the bookmarks chaos I wrote about here), but it solved the GitHub visibility problem as a side effect, and that is the part I want to talk about.

Each project in the dashboard can be linked to a GitHub repo. The extension supports multiple GitHub accounts via personal access tokens. So I added all three: personal, work, client. Each token only has read access to the repos it needs.

Now the timeline view in the new tab shows commits from all three accounts in one stream, scoped per project. If I open a new tab in the morning, I see exactly what I pushed yesterday, across every account, sorted by project, not by which login made the commit.

A few things this changed:

I stopped opening github.com tabs to check my own activity. The new tab page already had it.
I started recognizing real patterns. Which side project actually moves vs. which one I just say I am working on. The commit data does not lie.
Cross-account debugging got faster. When a side project's CI breaks because I forgot to commit a .gitignore rule from the work repo template, I see both repos' recent commits next to each other instead of context-switching tabs.

For private repos, you do need the extension's Pro plan because that requires a stored token with private scope. Public repos work on the free tier with a token that has public_repo only. I used the free tier for two months before upgrading.

If you want to try it, the extension is on the Chrome Web Store. The multi-account GitHub setup is in the GitHub settings page after you install. You add tokens one per account and tag them with a label.

The context problem: directory-anchored mental models

The last piece was harder because it was not about tools. It was about how I think about the work.

Before, my mental model was account-shaped. "Today I am personal-me working on side projects." Then "now I am work-me working on the day job." Switching meant changing posture.

After, my mental model is project-shaped. "Today I am working on Project A, Project B, and a small client task." Each one happens to live under a different account, but the account is a routing detail. The thing I am building is the project.

That sounds obvious in retrospect. It was not obvious when I had three browser tabs open trying to figure out where last Tuesday's work went.

Two practical habits that came out of this shift:

Name directories after projects, not accounts. ~/code/personal/cli-tool/, not ~/code/personal/sideproj-cli. The "personal" in the path is the auth boundary. The project name is the work boundary. Keep them separate in your head and in your shell history.
Tag commits with project context, not account context. When I write a commit message, I never write "personal commit" or "work commit." I write what changed. The account is metadata, not narrative.

The system, summarized

If you are setting this up from scratch:

Per-directory .gitconfig with includeIf rules. One identity per top-level folder.
SSH config aliases per account. Clone with the alias, never with plain git@github.com:.
A unified view of commits across accounts. Whether you build a script, use a dashboard, or roll your own, the goal is one place to see what you actually did, regardless of which login produced it.
Project-shaped, not account-shaped, mental model. The account is auth plumbing. The project is the work.

Three accounts is not a problem to solve once. It is a workflow to maintain. The goal is to make the maintenance cheap enough that you stop noticing.

Want to try the new-tab approach? STACKFOLO turns Chrome's new tab into a project hub with multi-account GitHub support, project timelines, and per-project task tracking. Free on Chrome Web Store →

The Subscription Audit That Saved Me $480 a Year

STACKFOLO — Mon, 20 Apr 2026 15:02:51 +0000

The Subscription Audit That Saved Me $480 a Year

A few months back I was paying for a headless CMS I had not opened in seven months. $19 a month. I noticed by accident, mid-coffee, scrolling through a credit card statement looking for something else entirely.

Then I kept scrolling.

By the end of the statement I had circled five charges for tools I either forgot about, replaced, or had paid annual upfront for and been re-billed monthly because I fat-fingered a setting somewhere. Total recurring bleed: about $40 a month. That is $480 a year, or roughly one decent mechanical keyboard I was handing to SaaS companies in exchange for dashboards I never logged into.

This post is the audit I ran that week, the five-minute cancel sweep that followed, and the system I set up so it would never creep back. If you build side projects, you are almost certainly carrying at least one of these ghost subscriptions. Often more.

Why Developer Subscriptions Quietly Multiply

It is not that we are careless. It is that the cost per decision is tiny, the decisions are spread across months, and nothing ever reminds us to re-evaluate.

Here is how the stack grows for a typical side-project developer:

You start Project A. You need a database. Supabase free tier is enough, but you upgrade to Pro because it has a feature you want. $25 a month.
Three months in, Project A stalls. You do not shut down Supabase because you might return to it.
You start Project B. Different stack, different database. Neon this time. $19 a month.
You sign up for a landing-page builder to test an idea. $15 a month on a monthly plan because you were not sure.
You replace your editor with a paid AI plan. $20 a month.
Free GitHub Copilot trial becomes $10 a month.
Domain renewals, email forwarding, a Figma seat from that one time you redesigned something.

Each decision at the time was rational. The problem is that the decisions never get revisited together. And when you pay by credit card, the cognitive distance between "I am using this" and "I am paying for this" is enormous.

The audit fixes that distance for one afternoon. The system that follows keeps the distance small permanently.

The Audit: Pull Six Months, Categorize, Decide

I set aside ninety minutes. It took forty.

Step one. Export the last six months of credit card and PayPal statements. One CSV per card. Filter anything that repeats with the same merchant and similar amount. That is your recurring list. Do not trust memory. Memory lies about which tools you actually use.

Step two. Put every recurring charge into one table. Columns I used:

Name of tool
Category: Dev infra, AI, Design, Hosting, Writing, Analytics, Email, Domain, Other
Monthly cost (convert annual to monthly for fair comparison)
Which project it supports (Personal, Project A, Project B, Client work)
Last time I actually used it this month: Daily / Weekly / Monthly / Zero
Decision: Keep / Downgrade / Cancel / Move to annual

Step three. Be honest about that fifth column. "I might use it" is not a tier. If you have not logged in this month, it is Zero usage. Your past self was optimistic. Your present self is paying for the optimism.

Step four. Act immediately. Close the laptop only after every Cancel row has a confirmation email. If you postpone, a week turns into three months and you pay another $120 for the privilege of still meaning to cancel.

What Actually Got Cut

My table had 14 rows. Here is the honest breakdown I walked out with:

Keep as-is (5 rows). Tools I used at least weekly with clear project value. Domain registrar, GitHub Pro, the AI plan I actually lean on, one hosting bill, one observability tool.
Downgrade (2 rows). A design tool I was on the team plan for, downgraded to the solo plan. A monitoring tool bumped from Pro to the free tier because I was only using one feature of Pro.
Move to annual (2 rows). Two tools where the annual discount was 20% or more and I was certain I would use them for a full year. Instantly cheaper without losing anything.
Cancel outright (5 rows). The forgotten CMS. A second database on a stalled project. A landing-page builder I had already replaced with plain Astro. A writing tool I used once. A social-scheduling trial that never got cancelled.

Delta: about $40 a month. Closer to $48 after the annual conversions paid off. Roughly $480 a year from a single afternoon.

What surprised me was not the savings. It was how many of those cancelled tools I did not miss even once in the following month. Not one "wait, I needed that" moment.

The System That Keeps It From Creeping Back

Audits only work if they happen again. My first mistake after the initial sweep was thinking "done, I am clean now." Four months later I had added three new subscriptions and forgotten to cancel two free trials that had converted.

The fix was to move subscription tracking out of my credit card statement and into the same place I manage the projects that justify the subscriptions.

I list every recurring charge next to the project it supports. Monthly cost, annual cost, billing cycle, the next renewal date, and whether the subscription is personal or tied to a specific project. When a project goes inactive, its attached subscriptions go on the chopping block the same week, not six months later when I trip over the charge.

Two rules that keep the list clean:

No trial without a renewal reminder. Every free trial gets a calendar entry dated two days before the auto-convert, with the cancellation URL pasted into the note.
Quarterly review, 20 minutes. Open the full list, sort by last-used, and run the same Keep / Downgrade / Cancel / Move-to-annual cuts. It is never forty minutes after the first time. It is usually under fifteen.

Bonus rule for multi-currency users: note the currency. If you pay for half your tools in USD and live on KRW or EUR, the exchange rate swings your real monthly cost more than you think. I track the billing currency separately and let the dashboard do the conversion so the monthly total I see is always in my home currency.

Where STACKFOLO Fits

I built the subscription tracker inside STACKFOLO because I was already living in a new-tab dashboard that knew about my projects. Instead of keeping a separate spreadsheet, I list subscriptions next to the project they belong to, tag them by category (AI, Dev, Media, Tools, Other), and get a monthly total that auto-converts across currencies.

The "Upcoming payments" strip at the top of the subscription view is the quiet hero. It shows renewals inside the next seven days with a D-day badge, which catches the trial-to-paid conversions I used to miss. Private Mode hides the amounts when I am screen-sharing, which is a small thing that stopped me from rage-closing the tab during pair-programming.

It is a 30-second habit, not a project. If you want to try the tracker yourself, STACKFOLO is free on the Chrome Web Store, and the subscription view is on the free tier.

The Part That Actually Shifted My Habits

The savings were real, but the bigger change was smaller and weirder. Once I could see every subscription attached to a project, I stopped signing up for tools the same way.

Before, a new SaaS trial felt free. Today I started it. It is just $15 a month. Future me would deal with whether it earned its keep.

Now, a new trial shows up on the same screen where I see the ten other tools I am already paying for. The question changes from "is this worth $15 a month" to "is this worth $15 a month on top of the $180 a month I already have running." The second question has a much higher bar.

Most trials do not clear it. The ones that do, I actually use.

If You Only Do One Thing

Export six months of statements this week. Build the table. Spend forty minutes. Send the cancellation emails before you close the laptop.

The rest of the system is optional. The audit is not.

Try STACKFOLO free on the Chrome Web Store if you want your subscriptions to live next to the projects that justify them.

Why I Moved My Bookmarks Out of Chrome Into a Structured Archive

STACKFOLO — Sat, 18 Apr 2026 23:05:09 +0000

Why I Moved My Bookmarks Out of Chrome Into a Structured Archive

At some point last year I hit a wall with Chrome bookmarks. I had 312 of them. Seven folders deep in some cases. Every time I wanted to find that one article about SQLite WAL mode, I opened the bookmark manager, stared at a tree of folders, and eventually gave up and re-Googled the article.

The bookmarks were not the problem. The structure was. Or rather, the lack of it.

Here is what I eventually moved to, and why Chrome bookmarks quietly stop working once you treat them as a real knowledge base.

Where Chrome Bookmarks Fall Apart

Chrome bookmarks are built for one thing: "I want to come back to this tomorrow." For that narrow job, they are fine. But as a developer, your saved links are not a to-read list. They are research, reference, inspiration, code snippets, tutorials you half-finished, and tools you might need someday.

Once the pile grows, a few things break.

Folders are a one-dimensional classification. A tutorial about React Server Components goes into Frontend or React or Tutorials. Only one. When you search for it later, you have to guess which folder your past self picked.

There are no tags. A single article can be "React", "performance", and "tutorial" at the same time. Folders force you to pick one. Tags would let all three coexist.

Search is shallow. Chrome's bookmark search looks at the title and URL. Not the description, not the content of the page, not anything you wrote about it. If the title is vague, the bookmark is effectively lost.

No notes. When you save a link, there is no field for "this is useful for the auth refactor" or "check section 3 for the WAL explanation." Future-you opens the link and starts reading from scratch.

No ratings. Among 300 saved articles, some are must-reads and some are "eh, maybe." Chrome treats them identically.

No project context. An article I saved while working on a side project has nothing connecting it to that project. Six months later I cannot remember why I saved it.

None of this is a Chrome team failure. It is just that Chrome bookmarks are built for casual saving, not for developers who are effectively building a personal knowledge base.

What I Tried Before Giving Up

I did not jump straight to a new tool. I tried fixing the workflow first.

Nested folders. I made a deep folder taxonomy: Dev > Frontend > React > Hooks > useEffect. This worked for about two weeks. Then I started saving to the wrong folders, or creating new ones because the existing ones did not fit, and the tree became its own mess.

A markdown file of links. Clean, searchable, version-controlled. But saving required me to stop what I was doing, switch to my editor, write a line, commit. I did not keep it up.

Raindrop.io, Pocket, Readwise Reader. Each is a good tool. But I had two specific problems none of them solved well: I wanted bookmarks connected to my projects, and I wanted saving to be friction-free, one keyboard shortcut and done, without a separate app.

Tabs as bookmarks. You know this one. Ninety open tabs that you will "get to later." It is not a bookmark system. It is a slow memory leak.

What I Actually Wanted

After a year of friction, I wrote down what a real developer bookmark system needed to do.

Save in under 2 seconds. A keyboard shortcut. No modal, no required fields. If I have to stop and categorize, I will not save.
Multiple tags per link. Not folders. Tags. So one article can be React and performance and tutorial without duplication.
Categories for intent. Reference, idea, tutorial, tool, inspiration, research. How I plan to use the link, not just what topic it is.
Project context. Which side project is this for? Or is it personal learning?
Ratings. A 5-star scale so I can filter "only the great stuff" later.
Notes. A one-liner at minimum. "This explains the CSS grid hack I need for the dashboard."
Search that actually works. Across title, description, tags, notes. Not just the title.

That list was not going to happen inside Chrome.

The System I Ended Up With

I now use a structured archive built into my new tab page. Every link I save has:

A title and URL, obviously
A category (reference, idea, tutorial, library, design, research, inspiration, prompt)
Tags, as many as I want
A rating (1-5 stars)
A note, if I want to leave one
A project, if the link is tied to something I am building
A thumbnail and favicon, auto-fetched

The save flow is one shortcut. I hit Alt+Shift+F, the current page gets saved, and I move on.

The part that actually shifted my habits was AI auto-tagging. I have a second shortcut, Alt+Shift+S, that does the same save but sends the page to an LLM first. It comes back with a suggested category, tags, and a short description of what the page is about. I can accept or edit in one click. This turned saving from "a tiny task I put off" into "a reflex." My archive grew by 80 entries in the first two weeks.

Why Structure Changes How You Use Your Bookmarks

This is the part I did not predict. Once the archive was structured, I stopped treating it like a graveyard for links and started treating it like a reference library.

I filter by category. When I am planning a side project, I open the archive filtered to tutorial + react and see only the tutorials I thought were worth saving. No more scrolling past SaaS landing pages I bookmarked six months ago.

I filter by project. When I context-switch back to a side project after two weeks away, I open the archive with that project selected and see every resource I gathered for it. Research, references, design inspiration, all in one view. Most of my "where did I save that?" pain went away.

I filter by rating. Five-star articles are my personal canon. When a friend asks "any good resources on X?" I can pull the 5-star ones in seconds.

Old links auto-archive. If I have not opened a link in 30 days, it moves to an archived state. Still searchable, but out of my main view. This alone solved the clutter problem.

What I Stopped Doing

Some habits died on their own.

I stopped emailing myself links. I stopped using the Pinboard tab. I stopped leaving 40 tabs open "for later." I stopped the "I'll just Google it again" instinct, because search across my archive is faster than re-finding a specific article through a search engine.

I also stopped feeling guilty about a big backlog. The structured view made it clear that most of the pile was categorized reference material, not a reading list I was behind on.

If You Just Want the Takeaway

Chrome bookmarks are fine until the pile gets big. Then they become a tax on your attention. A structured archive with tags, ratings, notes, project context, and search-across-everything fixes the scaling problem. AI auto-tagging removes the friction that kills most personal knowledge systems.

I use STACKFOLO for this because the archive lives in my new tab alongside my projects and tasks, so my research is always one tab-open away. But the principle is tool-agnostic. Whatever you use, the important part is moving from "a tree of folders" to "structured entries with tags, ratings, and notes."

Your bookmarks are trying to be a knowledge base. Let them.

Try STACKFOLO free on Chrome Web Store → https://chromewebstore.google.com/detail/stackfolo/gakjkkjgbekgmdkijbgdpdmmhenjejpb

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.