When people say "Since you're not a company employee, you have free time, right?" I'm never sure how to respond. It's not a lie, but it's not entirely accurate either. It's true that I'm not bound by a company, but whether I can actually use my time freely is another story—in fact, I spend more mental energy managing my time now than I did as a company employee.
The trigger for writing this article was something small: when someone in an indie development community asked me "How do you find time for development?" I couldn't give a proper answer. I kept saying "I manage somehow," but I hadn't really articulated it well myself. That frustrated me a little, so I decided to put it into words properly.
There's almost no technical discussion here. Rather than tools or systems, this is an honest account of how Lily, one maker, uses their day and where they've failed. You don't need to imitate anything you read, and I can't even say "please use this as reference"—it's that personal. But if it resonates even a little with someone else struggling with time management, I'd be happy.
The first few months after making indie development my main activity were rough.
I'd wake up at different times every day, and I couldn't even tell if I was working or not. I'd repeat "there's no deadline, so I'll do it later," then frantically write code in the middle of the night, release it in the morning with zero judgment, and regret it. That was the loop.
As a company employee, structure was given to me from outside. Starting at 9, meetings, and after 6 PM, naturally thinking "that's enough for today." Only when that structure disappeared did I realize how much easier it made things.
Creating your own structure is harder than I thought. "Do it when you're motivated" is just theory. Motivation isn't something that comes to you—it's something systems bring to you. When I relied on motivation as fuel, I'd collapse when it ran out. I stumbled many times because of that.
Lily's current day roughly looks like this. It's not perfect, and it falls apart some days, but this is my baseline now.
Mornings Are Only for "Creating"
In the morning, I basically disconnect from everything. No messaging apps, no social media, no email. I put all the most important decisions and work of the day into this time block.
Thinking through new feature logic, writing, refining design. I protect the time when my brain is clearest from being consumed by outside information.
At first, I felt guilty about not checking messages first thing. But after doing this for half a year, nobody got angry, and important messages were fine to check in the afternoon. I realized most things don't break if you don't respond immediately in the morning. Once I understood that, the guilt disappeared.
Afternoons Are for "Responding and Routine Work"
Afternoons are my reaction time. Replying to messages, checking social media, processing routine tasks, checking after releases.
I move work that doesn't require much thinking to the afternoon because I have no judgment left. I believe there's a limit to how many decisions you can make in a day, so I don't put important decisions in the afternoon. I pause and ask "Do I really need to decide this now?" and if I can push it to tomorrow morning, I do. Just that alone changes the quality of my mornings significantly.
Evening Onwards Is Loosely Off
I basically don't work after evening. Though I do lightly jot down "things I noticed today" in notes, or decide just three things to do tomorrow. Having this prep done makes the next morning completely different. A morning where I don't have to think "what should I do first?" means I can jump into work that much faster.
The biggest thing that helped create time was "automation." But this isn't about using specific tools or writing programs—it's about organizing work that doesn't require my brain.
Things I do the same way every day. File organization, backup checks, routine check tasks, distribution prep. When these flow without me having to think about them, the morning stress of "I have to do this manually again today" becomes zero. It looks like small stress, but accumulating daily, it's surprisingly heavy and gradually erodes your judgment.
I Sorted "Thinking" from "Working" First
Before automation, I sorted my tasks. I asked one question about every task: "Does this need judgment, or can I just follow steps?"
If the answer was "just follow steps," I'd automate it as much as possible or turn it into a procedure to just execute. If the answer was "needs judgment," that became a task only morning-me touches.
After this sorting, days where I was "busy all day but nothing progressed" decreased. I shamefully realized for the first time that busyness and progress are different things.
I'll be honest about what didn't work.
Trying to Solve Everything with Tools
In the early days of indie development, I kept trying new tools. Task management apps, time tracking apps, habit trackers, note apps. It was fun in itself, but managing the tools became the job, and actual development didn't progress—a completely backwards situation.
Now I intentionally use fewer tools. The fewer, the less you have to think. Time spent thinking "what should I use?" is time not spent creating.
Making "Daily Commits" My Goal
For a while, I made daily GitHub commits my goal. To keep the streak alive, I'd sometimes make meaningless small changes. Maintaining the record became the purpose, and whether the product was actually progressing went somewhere else. The ultimate backwards example.
Now I evaluate myself at the level of "did something move forward this week?" The granularity matters more than the record. Whether there's something usable a week later is far more important.
I Was Afraid to Take Breaks
There was anxiety that "indie development doesn't end unless you stop it yourself," so I'd work on days off without really thinking about it. But weeks where I didn't properly rest had clearly lower productivity the following week. Code written without rest, when I look at it later, has poor judgment and needs lots of fixes.
Once I thought of rest as a skill, I started intentionally creating days where I do nothing. People who can have days where they do nothing can sustain this longer.
One trap indie developers fall into with time management is "aiming for a perfect routine." Lily was stuck in this for a long time.
Wake at 6, exercise, focused work, sleep by 11. That itself is ideal, but the design was such that if one thing broke, everything broke. When things slipped even slightly, I'd think "today's done," blame myself for not being perfect, and spiral further. A loop of collapse.
Now I design with "something will break" as the premise. If morning work breaks, I make one important decision in the afternoon. If that's impossible too, today is just organization and recording. Having a line where I give up beforehand means one thing breaking doesn't break everything.
I personally think an indie developer who can recover from breaking down lasts longer than one with a perfect routine. A day where you do something even when things are terrible is more impactful half a year later than a day where everything went perfectly.
I've written at length about time management, but to be most honest at the end: even now, things don't go smoothly every day. There are days I can't focus, weeks where nothing progresses. There are periods where I can't tell if I'm creating or falling apart, and they come regularly.
But now I know that's "normal." If you could only make good things within perfectly managed time, there'd be no indie developers left.
Automation is for reducing decisions. Routines are for rebooting. Sorting is for protecting focus. They're all just tools for one thing: "creating every day."
Tools exist to be used. Not to be managed, not to be perfectly assembled. Remembering that makes things a little easier.
To those continuing to create while struggling with time like me, I hope this reaches you a little. Let's manage somehow, together.
Lily (@bokuwalily) — Indie developer. Creating iOS apps and web services in tandem with AI.
