Part-time indie project: the real constraints nobody admits

In short — Building a part-time indie project isn’t just about “finding 2 hours a day”: it’s your cognitive energy reserves — not your calendar — that dictate what you can actually produce. The strategies that work under constrained conditions are radically different from what side-project gurus sell.

---

The line shows up in every thread. “Two hours a day, and in six months you’ve got a product.” Ten thousand likes, two hundred enthusiastic comments, and nobody asks: two hours of what, when, and under what life conditions?

I built my first products while working full-time. And since building SEK — my indie studio — I have a newborn son, a teenager, and a real life away from screens. The part-time question isn’t a temporary phase to white-knuckle your way through. For many of us, it’s a permanent condition. Better to look at it straight.

The “2 hours a day” illusion: what the gurus don’t show you

The promise sounds solid. Two hours a day is 14 hours a week. A month in, you’re approaching 60 hours. Over a year: 720 hours. The maths work. What doesn’t work is the premise.

The first mistake is confusing available time with usable time. There’s a fundamental difference between two free hours at 7am — rested, coffee in hand — and two hours scraped together at 10pm after a day of meetings, a family dinner, and a bedtime routine that dragged on too long. In both cases, the calendar reads “available.” In both cases, the output is nothing alike.

The second mistake is the silence around the type of work. Some tasks — complex debugging, database architecture, dense content writing — demand a state of concentration often called deep work. These tasks collapse the moment you’re tired or interrupted. Others — answering emails, updating a doc, testing an interface — can be done in degraded mode without much damage. Gurus never separate the two.

The third mistake is the quietest: attention debt. A day of salaried work consumes cognitive energy, even if you don’t feel like you’ve “worked hard.” Open-plan offices, blinking Slack notifications, meetings with no reason to exist: all of it erodes the most precious resource for a maker — the available mental bandwidth to make quality decisions.

This isn’t pessimism. It’s an honest diagnosis. And an honest diagnosis is the only useful starting point.

Map your available energy, not your calendar

Before you block out slots in your calendar, run a different exercise: map your energy over a typical week. Not your free hours — your mental state during those hours.

In practice: for 5 to 7 days, note at the end of each day the moments when you felt capable of solving a new problem. Not “I had time,” but “I had the bandwidth to decide, create, move forward.” For most people combining a job with a project, these windows number two or three per week, rarely more. And they tend to fall in the morning, earlier in the week.

The practical takeaway: stop spreading your tasks evenly across the week. Instead, identify your 2–3 “high-energy blocks” and reserve them exclusively for deep work — important decisions, code that requires clarity, product strategy. Everything else — mechanical tasks, reviews, small publications — can go in low-energy slots.

A generic example that illustrates the mechanics well: picture a developer with a full-time job and a young child. If they try to work on their project every evening, they produce little, produce poorly, and feel constantly drained. If they concentrate all their effort on Tuesday and Thursday mornings (getting up an hour earlier), with nothing else scheduled in those slots, they make real progress. This isn’t a discipline question — it’s a physiology and rhythm design question.

Family imposes its own non-negotiable constraints. With my young son and my teenager, weekday evenings are often off-limits for deep work. I don’t treat that as a tragedy — I treat it as a design parameter. The constraint is real; you work around it or plan for it, you don’t deny it.

The 3 types of tasks to prioritise when you have 45 minutes

Forty-five minutes is probably the most common slot length for an employed person with a life. Not two hours, not a full day: 45 minutes between commitments. Here’s how to use them without wasting them.

1. Irreversible decisions that unblock what comes next

This is the most high-return category and the most consistently avoided, because it’s uncomfortable. Choosing your tech stack. Defining your MVP scope. Deciding whether to pivot or hold your positioning. These decisions tend to stall because they’re scary — so we replace them with comfort tasks (more research, another wireframe redesign).

A well-disposed 45-minute slot is enough to settle one of these questions, provided you arrive with the problem already framed on paper, not figuring it out from scratch. The rule: if a decision is blocking two other downstream tasks, it takes absolute priority in your next high-energy slot. Not next week.

2. Immediately publishable micro-deliverables

These are the small units of value you can ship in one go: a landing page published, a short article posted, a tiny but functional feature deployed, an email sent to a list — even a small one. These micro-deliverables have two virtues. First, they make the project exist in the real world, which radically changes your mental dynamic. Second, they sometimes generate immediate feedback that orients you without you having to guess.

The opposite temptation — accumulating invisible work for weeks before shipping anything — is the classic trap of the employed side-project builder. You prepare, improve, polish. And nothing escapes your hard drive.

3. Active feedback loops

A conversation with a potential user. A post in a makers community to test an idea. A Typeform posted in a Slack channel. These actions take 15 to 30 minutes and are worth more than hours of solo work, because they pit your assumptions against reality.

In an indie project, the feedback loop is often the most underused resource. People are afraid of outside eyes on something unfinished. But a part-time project can’t afford to build for 6 months before showing anything: you don’t have 6 months of cognitive runway to squander going in the wrong direction.

If this resonates, the solopreneur & AI statistics 2026 dossier gives context on the economics of these solo projects — without fabricated figures.

How AI compresses production time without compressing quality

This is where things genuinely changed compared to what was possible five years ago.

AI doesn’t create extra hours in your day. It compresses certain production phases that previously consumed entire high-energy slots for often mediocre results when you were tired.

Here are the phases where the gain is real and measurable, based on my direct experience:

Boilerplate code and plumbing. Generating a project’s initial structure, writing repetitive unit tests, creating database migrations — these are low-cognitive-value but high-time-consumption tasks. A well-configured agent handles them in minutes. You save your high energy for the architecture decisions that genuinely require human judgement.

First drafts of content. Articles, product descriptions, onboarding email sequences — AI produces a solid first draft from a well-written brief. The brief itself requires your own thinking. So does the revision. But the blank page and the base structure disappear from the problem.

First-level debugging. Pasting a stack trace into an agent and getting the three most likely hypotheses: it doesn’t replace diagnosis, but it halves the time spent looking in the wrong direction.

Invisible admin. Responding to standard requests, tracking tickets, reporting: the mental load of these tasks is disproportionate to their value. Partial automation (agents, workflows) isn’t laziness — it’s reclaiming bandwidth for what matters.

What AI doesn’t do, and this needs to be said honestly: it doesn’t make strategic decisions for you. It doesn’t know whether your product will find its audience. It doesn’t detect when you’re building the wrong thing. That judgement remains human — it requires perspective, real-world exposure, and the ability to pull signal from noise. No tool takes that from you, but no tool replaces it either.

The winning combination in part-time mode: AI absorbs the mechanical load, you concentrate your high-energy slots on the decisions and interactions that demand your judgement. This isn’t a promise — it’s what I practise in building SEK since AI tooling reached a genuinely useful level.

To go further on the technical side without getting stuck, /unstuck/ is built for exactly that: fast unblocking on a specific point, without losing half a day going in circles.

What part-time teaches you that full-time can’t

There’s something people who jumped straight into full-time indie don’t always realise: the part-time constraint forces ruthless selection.

When you have unlimited time (or something close to it), you can afford to work on low-priority tasks without feeling the damage. You can redesign three times, explore features with no validated demand, spend a week on a technical detail nobody will ever see. Part-time doesn’t allow that latitude.

Every slot counts enough that you ask yourself: is this the most important thing to do right now? That discipline, imposed by constraint, is often what separates projects that move forward from those that rot in an infinite backlog.

Employment also provides a safety net that the euphoria of “going for it” can easily mask. Decisions made under financial pressure are among the worst product decisions. Burning runway too fast, taking any client just to cover the bills, undervaluing your offer because you’re scared: these patterns happen almost systematically when you jumped too soon. Part-time, on the other hand, lets you validate before you depend.

That’s not a reason to stay employed indefinitely. It’s a reason to stay employed until your product has proved something. A traction signal, even a faint one — first paying users, a growing email list, enthusiastic feedback from a specific segment — completely changes the equation.

---

Building solo, with limited time and a real life around you: it’s a constraint, not a curse. What kills part-time indie projects isn’t a lack of hours. It’s the illusion that you can do everything, the failure to select tasks ruthlessly, and the energy wasted pretending exhausted evenings are worth the same as clear mornings.

What I practise at SEK isn’t a perfect system. It’s an honest system, adjusted to a real life with two kids, a studio to build, and zero desire to sacrifice one for the other.

If you’re also building something from a constrained position and want an outside perspective on your technical progress, Sébastien De Bollivier works freelance with projects at exactly this stage.

Got an idea to ship? A website, a SaaS, an AI automation — built with you.

Talk about your project