The Productivity System I Used to Build 3 Apps While Working Full-Time

The Productivity System I Used to Build 3 Apps While Working Full-Time

For two years, I worked a demanding full-time engineering job while shipping three side projects: a SaaS tool, an open-source CLI library, and a developer course platform. People frequently asked how I managed it without quitting my job, destroying my health, or producing terrible code.

The honest answer is not glamorous. It is not a secret hack. It is a system — a deliberate developer productivity system built from hundreds of small decisions about how I spend my time and energy.

I did not work more hours than my colleagues. I worked different hours. I protected certain windows of my day with almost religious intensity, automated everything repeatable, and ruthlessly eliminated tasks that felt productive but produced no real output.

In this article, I am going to walk through the exact system: the daily schedule, the tools, the mental frameworks, and the honest mistakes I made along the way. By the end, you will have a complete blueprint you can adapt to your own life — whether you are trying to launch a side project, contribute to open source, learn a new stack, or simply stop feeling behind at work.

Why Most Developer Productivity Advice Fails

The standard productivity advice — wake up at 5 AM, hustle harder, grind on weekends — is not just unhelpful. It is actively counterproductive for deep technical work.

Software development is a cognitively demanding discipline. Writing good code requires holding large, interconnected systems in your working memory simultaneously. That cognitive capacity is a finite resource. The moment you exhaust it, code quality drops, bugs multiply, and every decision takes twice as long.

Most productivity frameworks are designed for knowledge workers doing shallow tasks: responding to emails, attending meetings, writing reports. Developers need something different — a system that protects and maximizes deep cognitive work.

The framework I built has three pillars:

1. Energy management over time management — Track when your brain is at peak capacity, not just how many hours you work
2. Time-blocking for uninterrupted depth — Reserve long, protected windows for hard problems
3. Ruthless task filtering — Eliminate everything that is not moving the needle

Let me show you exactly how each pillar works in practice.

The Time-Blocking Schedule That Made Everything Possible

Understanding Your Cognitive Peaks

Before you can block time effectively, you need to know when your brain is at its best. For most people, peak cognitive capacity lands in the first 2–4 hours after waking — before the mental overhead of meetings, decisions, and context-switching accumulates.

I tracked my coding output for six weeks — commits, lines written, features completed per hour — and found a clear pattern: my most productive code happened between 6 AM and 9 AM and again between 9 PM and 11 PM. The afternoon slot (2–5 PM) was consistently my worst.

Here is the time-blocking template I built around that data:

Daily Time-Blocking Schedule (My Actual System)

MONDAY — FRIDAY

5:30 AM   Wake up, no phone
5:30–6:00 Light exercise (20 min) + coffee
6:00–9:00 DEEP WORK BLOCK 1 — Side project coding (no Slack, no email)
9:00–9:30 Daily standup + urgent messages only
9:30–12:00 DEEP WORK BLOCK 2 — Day job core tasks
12:00–1:00 Lunch + walk (real break, no screens)
1:00–3:00  Day job meetings, code reviews, Slack catch-up
3:00–5:00  Day job shallow tasks (docs, PRs, planning)
5:00–7:00  Family/exercise/dinner — ZERO WORK
7:00–8:30  Learning block (reading, courses, research)
8:30–10:00 DEEP WORK BLOCK 3 — Side project or day job overflow
10:00 PM  Hard stop. Laptop closed.

SATURDAY
8:00–12:00 Extended deep work — largest side project tasks
12:00 PM   Stop. Rest. Recharge.

SUNDAY
Full rest. Zero coding. Non-negotiable.

The critical insight is that I protected the 6–9 AM block more fiercely than anything else. That window was the entire foundation of my side project output. Before most colleagues sent their first Slack message, I had already shipped 90 minutes of clean code.

Why the Hard Stop Matters as Much as the Start

I used to work until I felt done. That meant working until midnight and feeling guilty about stopping before then. The quality of code I wrote after 10 PM was reliably worse — more bugs, worse architecture decisions, more time wasted the next day debugging things I wrote while exhausted.

The hard stop is not a nicety. It is a performance decision. Ending at a fixed time forces you to be honest about what is actually important and what is just busyness. It also preserves the quality of your next morning's peak work block.

The Productivity Metrics That Revealed What Actually Mattered

One of the most useful things I did was measure my output — not my hours. Here is the tracking table I maintained weekly:

The most surprising finding: as my deep work hours increased, my bug rate dropped significantly. This confirmed something Cal Newport writes about in Deep Work — focused, uninterrupted coding is not just faster, it is categorically better quality than fragmented coding.

I tracked these metrics in a simple Notion database. Nothing sophisticated — a weekly entry with 6 numbers and a brief note about what worked and what did not.

The Task Filtering System: What Deserves Your Best Hours

Not all tasks are created equal. The fundamental mistake most developers make is treating all work as equally important, then wondering why the most important things never get done.

I use a simple filter with three questions:

1. Does this move the project forward in a meaningful way? Writing a core feature: yes. Refactoring code nobody reads: debatable. Tweaking the color scheme at 11 PM: no.

2. Can this be automated or templated? Setting up a new project? I have a shell script. Writing boilerplate components? I have snippets. Responding to common user questions? I have a template. Anything repeatable gets systematized.

3. Does this require my peak cognitive capacity? Architecture decisions, complex algorithms, debugging subtle race conditions: peak hours only. Updating documentation, reviewing PRs for style issues, writing changelogs: these go in the shallow work slots.

The Weekly Review (30 Minutes That Saves 5 Hours)

Every Friday at 4:30 PM, I spend 30 minutes on a structured weekly review:

• What did I actually complete this week?
• What is the single most important thing for next week?
• What is blocking progress? (Be specific — not "I need more time" but "I need to understand the OAuth flow before I can implement login")
• Clear my task inbox: every captured item gets processed, prioritized, or deleted

This 30-minute investment consistently prevents me from showing up Monday with no clear direction and wasting the first 2 hours figuring out where I left off.

The Tool Stack That Runs This System

Productivity tools are not the system — they support the system. Here is what I actually use and why:

The most impactful single tool is the distraction blocker. During deep work blocks, Freedom blocks social media, news sites, YouTube, and Slack on all my devices simultaneously. The absence of the option to context-switch is more powerful than willpower. I have never once regretted blocking these sites during a deep work session.

For more on the best tools in each category, see our Obsidian vs Notion comparison and our AI productivity system guide.

Mistakes I Made (And What I Learned)

Mistake 1: Starting Side Projects Without Scope Limits

My first side project had no defined scope. I kept adding features. Eighteen months later, I had a half-finished product with 40 features and no actual users. The next project, I wrote the scope on a single index card. It shipped in 3 months.

Mistake 2: Not Using AI Assistance Early Enough

I resisted GitHub Copilot for months, thinking it would make me a lazier programmer. When I finally adopted it, I was shocked. Not because it wrote better code than me — it often does not. But because it eliminated the cognitive friction of boilerplate. Starting a new file, setting up a test suite, writing CRUD operations — Copilot handles these instantly. My mental energy goes to the hard parts.

Mistake 3: Treating Weekends as Overflow

For the first year, I worked every Saturday and Sunday. I was consistently productive on Saturday mornings. Sunday work was almost always garbage — poor decisions, slow output, low energy. Now Sunday is untouchable. I am consistently a better developer Monday morning because of it.

The Mindset Shift That Made the System Stick

The hardest part of this system was not the tools or the schedule. It was the mindset shift from "I need to work more" to "I need to work better."

Full-time developers have roughly 8 hours of working capacity per day. Side project developers have roughly 2–3 additional focused hours. That is not a lot. You cannot afford to spend those hours on the wrong things.

Every time I sit down for a deep work block, I ask one question: "What is the single next thing that moves this project forward?" Not "what should I work on?" — that question is too broad. Not "what is most urgent?" — urgency and importance are not the same thing. The single next thing that moves the project forward.

That clarity, repeated daily, is what ships products.

If you are looking to upgrade your focus technique within these blocks, our Pomodoro technique for developers guide goes deep on the mechanics. And for automating the repetitive work that clogs your shallow work slots, see our Zapier vs n8n comparison.