A Day in the Life of an Indie Hacker: How I Manage Time

A raw look at how a Cloud Engineer and Indie Hacker balances a Masters degree, shipping code, and life. No productivity porn, just real systems.

The Myth of the Perfect Schedule

There is this romanticized version of the indie hacker life that floats around on X (Twitter). You know the one. It usually involves a picture of a MacBook sitting on a pristine wooden desk, a latte with perfect foam art, and a caption like "Deep work session starting now."

That is not my life. And if you are trying to balance a Masters degree in Cloud Computing, building a SaaS, and maintaining some semblance of sanity, it probably isn't yours either.

Here in Ireland, the weather is unpredictable. My schedule is pretty much the same. I don't operate on a rigid 9-to-5 block system because that falls apart the moment a server crashes or a lecture runs late. Instead, I manage my time based on energy output and context switching costs.

The hardest thing isn't finding the hours. It is finding the focus.

I want to break down exactly how I structure a day to maximize shipping velocity without burning out. This isn't productivity porn. It is survival.

06:00 - 09:00: The Maker Hours

I wake up early. Not because I want to join the 5 AM club, but because this is the only time the world is quiet. No emails. No slack notifications. No university deadlines looming immediately over my head.

This block is strictly for coding.

I have a rule: No consumption before creation. I don't check social media, I don't read news, and I definitely don't look at my university learning portal. I open VS Code immediately.

Right now, I am migrating my workflow from the WordPress ecosystem to a modern SaaS stack. That means Next.js, Tailwind, Shadcn UI, and Supabase.

Why this stack? Speed. When you are a solo developer, you cannot afford to waste time reinventing the wheel. In the WordPress days, I used to fiddle with PHP snippets and plugin conflicts. Now, I use Shadcn to copy-paste accessible components and move on.

Here is a concrete example of how I save time during this block. I don't write authentication logic from scratch. I use Supabase Auth with a custom hook in Next.js.

A typical morning might involve setting up a protected route middleware. It looks something like this:

import { createMiddlewareClient } from '@supabase/auth-helpers-nextjs'
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export async function middleware(req: NextRequest) {
  const res = NextResponse.next()
  const supabase = createMiddlewareClient({ req, res })

  const { 
    data: { session },
  } = await supabase.auth.getSession()

  // If no session and trying to access protected route
  if (!session && req.nextUrl.pathname.startsWith('/dashboard')) {
    const redirectUrl = req.nextUrl.clone()
    redirectUrl.pathname = '/login'
    return NextResponse.redirect(redirectUrl)
  }

  return res
}

Writing this code once and creating a snippet for it saves me mental energy. I am not thinking about how to secure the route. I am just implementing the pattern.

I focus on one feature per morning block. Maybe it's the billing portal integration with Stripe, or maybe it's refining the onboarding flow. If I try to do both, I fail at both. By 9 AM, I need to have committed code to GitHub. That green square is my dopamine hit for the day.

09:30 - 15:00: The Student / Cloud Engineer Gap

This is where the "Indie Hacker" identity clashes with the "Cloud Computing Student" reality.

I head to campus. My Masters program covers heavy topics. Distributed systems, AWS architecture, Azure governance, Kubernetes.

It is tempting to view this as "time away" from my business, but I've started treating it as R&D.

When we discuss scalability in class, I am filtering that information through the lens of a bootstrapper. The professor might be talking about enterprise-grade multi-region replication. I am thinking: "Okay, but how do I architect this so my AWS bill doesn't bankrupt me next month?"

This duality is actually a superpower.

Most indie hackers are self-taught devs who fear the infrastructure layer. They stick to Vercel because AWS feels like a cockpit of a 747. Because I am forced to study the underlying mechanics of the cloud, I feel comfortable spinning up a Docker container on an EC2 instance if I need to cut costs, or using Azure Functions for background jobs.

However, I have to be careful. The academic world loves complexity. The indie world loves simplicity.

If I applied everything I learned in class to my SaaS, I would never ship. I would spend six months designing a perfect microservices architecture for a product with zero users.

I keep a notebook (physical, not digital) where I write down "Cloud Concepts to Simplify."

Class concept: Kubernetes orchestration for container management.
Indie translation: Just use Railway or Render until you hit 10k MRR.
Class concept: Custom VPC peering and subnet segregation.
Indie translation: Default VPC is fine, just lock down the security groups.

This mental translation keeps me engaged in class without losing the pragmatic edge needed to build products fast.

15:00 - 17:00: The "Manager" Mode

After classes, I am mentally drained. My brain cannot write complex TypeScript logic anymore. If I try to code now, I will introduce bugs that will take me twice as long to fix tomorrow morning.

So, I switch roles. I take off the Engineer hat and put on the Manager/Marketer hat.

This block is for:

Responding to emails.
Engaging on Twitter/X.
Writing documentation.
Planning the next sprint.

Documentation is boring. Everyone hates it. But in my freelancing days, lack of documentation killed my margins. Clients would call me asking how to change a header image because I didn't write it down.

Now, building SaaS, I treat documentation as a marketing asset. Good docs show potential users that the product is serious. I use tools that integrate with my codebase to generate docs, or I just write simple Markdown files in the repo.

Marketing is the area I struggle with the most. As technical people, we want the code to speak for itself. It never does.

I force myself to write one thread or piece of content during this time. It doesn't have to be viral. It just has to exist. I talk about what I built that morning.

"Built a new auth flow today. Here is why Supabase makes it easier than Firebase."

Simple. Authentic.

18:00 - 20:00: The Second Wind (Or The Trap)

After dinner, there is a dangerous period. I often get a "second wind" of energy. The temptation is to go back to coding.

Sometimes, I give in. Especially if I am close to shipping a feature. But I have learned to be cautious.

If I code late at night, I ruin the next morning. My brain doesn't shut down. I lay in bed thinking about state management libraries or database schemas.

Instead, I try to use this time for infrastructure as code (IaC) or system maintenance. Things that are low-risk but necessary.

For example, tweaking my Terraform scripts. I am a big believer in defining infrastructure in code, even for small projects. It makes things reproducible.

Here is a snippet of how I might define a simple AWS S3 bucket for user uploads using Terraform. It’s declarative, so it requires less "logic" brain power than writing algorithmic code:

resource "aws_s3_bucket" "user_uploads" {
  bucket = "my-saas-user-uploads-prod"

  tags = {
    Name        = "User Uploads"
    Environment = "Production"
  }
}

resource "aws_s3_bucket_public_access_block" "user_uploads_access" {
  bucket = aws_s3_bucket.user_uploads.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Doing this kind of work in the evening feels productive but safe. I am setting up the rails for the future without risking a critical logic error in the application layer.

The Weekend Strategy: Sprints vs. Rest

Monday to Friday is about survival and incremental progress. Saturday is for Deep Dives.

Since I don't have university classes, I can pull an 8-hour shift if I want to. This is where I tackle the "Hard Problems."

Things like:

Integrating a complex third-party API.
Refactoring a messy component hierarchy.
Setting up end-to-end testing with Playwright.

Sunday is strictly off-limits for coding.

This was a hard lesson. In my freelance years, I worked 7 days a week. I made good money, but I hated my computer. I wanted to throw it out the window.

To build a SaaS that lasts, you need to stay in the game. You cannot stay in the game if you burn out in month three. Sunday is for hiking, exploring Ireland, or just sleeping. It resets the dopamine receptors so that when Monday morning comes around, I actually want to open VS Code again.

Tools That Save My Life

I want to list the specific tools that make this time management possible. I don't use a fancy productivity app with AI integration. I keep it simple.

Linear: For issue tracking. It is fast, keyboard-centric, and doesn't feel like enterprise bloatware (looking at you, Jira).
Notion: For general life management and notes. But I don't build "systems" in Notion anymore. I just write.
GitHub Copilot: This is non-negotiable. It handles the boilerplate. It writes the regex I can never remember. It saves me probably 30% of my typing time.
Vercel: I deploy my frontends here. The CI/CD is automatic. I push to main, it deploys. I don't have time to manage Jenkins pipelines.

Dealing with the "It's Not Enough" Feeling

No matter how much I get done, there is always a voice in my head saying I should have done more.

I see people on Twitter launching three startups in a month. I see my classmates getting job offers from Amazon.

It is easy to feel behind.

But I remind myself that I am playing a different game. I am optimizing for freedom, not just a paycheck. The transition from trading time for money (freelancing) to building equity (products) is painful. You work for free for a long time before the flywheel starts spinning.

My time management isn't about squeezing every second out of the day. It is about allocating my limited energy to the things that compound.

Learning Cloud architecture compounds. Building a reusable codebase compounds. Growing an audience compounds.

Everything else is noise.

Final Thoughts

If you are looking for a perfect routine, stop.

You will fail. You will have days where you stare at a blank screen. You will have days where university assignments take priority and you can't ship a single line of code.

That is okay.

The goal is consistency over intensity.

Keep showing up. Keep shipping small updates. Keep learning.

Now, if you'll excuse me, I have a database migration to run.