Pine icon
Blogs
Back

The Morning Feature Factory: How 80% of My Features Were Built Before 9 AM

It Started With a Simple Question

"I wonder what Redis is actually good for?"

my-desk

That question, asked on a random Tuesday evening in September, led to 74 days of early morning coding sessions and a complete game leaderboard platform. But this isn't a story about waking up at 5 AM every single day. It's about something more interesting.

It's about what happens when you code in the morning versus when you code at night.

The Numbers Tell the Real Story

  • 115 commits over 74 days
  • 80% of features built during morning sessions (12/15 features)
  • 10 pure morning coding days where ALL commits happened before 9 AM
  • Peak productivity: 6:00 AM with 12 commits
  • 12 commits before 7 AM (the real early bird special)
github-stats

But here's what caught me off guard: Morning commits = Features. Evening commits = Bug fixes.

The Pattern I Didn't Expect

Looking at my git history, a clear pattern emerged:

Morning Brain (5-9 AM):

  • 12 features built
  • 7 bug fixes
  • Architecture decisions
  • New capabilities
  • Creative problem-solving

Day/Evening Brain (9 AM - Midnight):

  • 3 features built
  • 33 bug fixes
  • Refinements
  • Polish
  • Cleanup

My morning brain was building things. My evening brain was fixing things.

I didn't plan this. I just noticed that on days I coded early, I was tackling the hard problems - implementing WebSockets, designing the leaderboard system, architecting the API. The grunt work happened later.

hourly

Figure: Hourly Commits

The 10 Pure Morning Days

There were 10 days where I only committed code in the morning. Not a single commit after 9 AM. Those days weren't planned - they just happened when I had something interesting to build.

Looking back at what I built on those days:

  • Socket.io integration
  • Real-time leaderboard updates
  • API key management system
  • Game ownership system
  • Score processing queue

All the meaty features. The stuff that required focus and deep thinking.

What I Actually Built

SubbEngine - A leaderboard-as-a-service platform for games.

subbengine1 subbengine2

The Core Features

  • Multi-game support
  • Real-time leaderboards with WebSocket updates
  • Developer API key management
  • Player stats and analytics
  • Background score processing with BullMQ
  • Complete authentication system
  • Admin dashboard
  • Typescript SDK for developer use

The Tech Stack

  • Frontend: React 19, TanStack Router, Tailwind CSS
  • Backend: Hono, PostgreSQL, Redis, Drizzle ORM
  • Real-time: Socket.io
  • Jobs: BullMQ + Redis
  • Auth: Better Auth

The Journey

  • Separate API repo: 70 commits
  • Separate client repo: 33 commits
  • Migrated to monorepo: 12 commits
  • Total: 115 commits across 74 days

The Actual Morning Routine

People romanticize the "5 AM grind" but here's what it actually looked like: Week of October 19: 100% morning commits (peak motivation) Week of October 26: 25% morning commits (life happened) Week of November 2: 50% morning commits (finding balance) Week of November 9: 25% morning commits (shipping mode) Week of November 16: 58% morning commits (monorepo migration) I wasn't consistent. Some weeks I was all-in on mornings. Other weeks I coded whenever I could. But the pattern held: mornings = features, evenings = fixes.

Why Morning Coding Hit Different

After 74 days, I think I know why morning sessions were so productive for feature work:

  1. Zero interruptions - No Slack, no emails, no "quick questions"
  2. Fresh mental model - I could hold complex architecture in my head
  3. Long time horizon - I had hours before my day job started, so I could dive deep
  4. Creative energy - My brain wanted to build, not debug By evening, I was tired. I'd had a full day of work. But I could still fix bugs, refactor, clean up. That required less creative energy.

The Weekend Factor

52 commits happened on weekends. That's 45% of my total commits. This project was clearly something I wanted to build, not something I forced myself to build. When you're excited about what you're making, you don't need discipline - you need to resist the urge to code on Saturday morning.

What Actually Happened

Here's the honest timeline: September 10: "Let me try Redis"

  • Created a simple script
  • Basic SET/GET operations
  • "This is neat but... what do I build?"

Week 2: "Oh, I need a database too"

  • Added PostgreSQL
  • Set up Drizzle ORM
  • First actual feature: player registration

Week 3-4: "This needs an API"

  • Discovered Hono
  • Built REST endpoints
  • Added authentication
  • "Wait, I need background jobs for score processing"

Week 5-6: "I should build a frontend"

  • React setup
  • TanStack Router
  • Basic leaderboard display
  • "Actually, real-time updates would be cool"

Week 7-8: "This is becoming real"

  • Socket.io integration
  • API key system
  • Admin dashboard
  • Game ownership/permissions

Week 9-10: "Let's migrate to a monorepo"

  • Set up Turborepo
  • Migrated API + client
  • Added consumer service
  • Cleaned up architecture
monorepo

The Thing Nobody Tells You

Building something is way easier when you're genuinely curious.

I didn't wake up at 5 AM because I'm disciplined. I woke up because I was excited to see if I could get WebSockets working. I coded on Saturday mornings because the leaderboard update logic was interesting to figure out.

The "5 AM grind" narrative is cool, but it's not the real story. The real story is:

  • I found a problem I wanted to solve (leaderboards are annoying to build)
  • I had a tech stack I wanted to learn (Redis, Hono, BullMQ)
  • I gave myself permission to explore without pressure
  • Morning brain happened to be better at creative work
  • 74 days later, I had a working platform

What's Next?

I'm not sure. I have a few options:

  1. Open source it - Other developers might find it useful
  2. Make it a product - There's definitely a market for leaderboard-as-a-service
  3. Keep it as a portfolio piece - It's already taught me a ton
  4. Use it for my own games - That was kind of the original idea

For now, I'm just proud I actually finished something. And I learned that my best work happens when the house is quiet, the coffee is hot, and nobody's awake to bother me.

The Takeaway

If you're trying to build something:

  • Track your commits by time of day - you might discover your own pattern
  • Use morning sessions for creative work, evening for cleanup
  • Don't force consistency - some weeks will be better than others
  • Build something you're actually curious about
  • 74 days of small commits > 7 days of "I'll do it all at once"

And if you're wondering about that Redis question? I finally understand what it's good for. Turns out, a lot of things.

All stats are from actual git commit history across 3 repositories. Interactive visualizations and source code available on GitHub.

Appendix: By The Numbers

Commit Distribution:

  • Morning (5-9 AM): 23 commits, 12 features, 7 fixes
  • Day (9 AM-5 PM): 14 commits, 2 features, 8 fixes
  • Evening (5 PM-12 AM): 13 commits, 1 feature, 10 fixes

Pure Morning Coding Days: 10 out of 19 total coding days (53%)

Peak Productivity: 6:00 AM (12 commits)

Longest Streak: Not very long - I'm not a streak person

Most Productive Day: Saturday (35 commits)

Feature-to-Bug Ratio: 51 features to 40 fixes (healthy forward momentum)