How to build side projects while working full-time and raising a newborn

If you want the short answer, building a side project while working full-time and raising a newborn is mostly a workflow problem, not a motivation problem.

Most side projects do not die because the idea was terrible.

They die because the builder secretly designed the project for a version of life they do not actually have.

That is the trap.

A normal side-project plan assumes long uninterrupted evenings, stable energy, and the ability to disappear into a feature for four hours without the rest of life changing the plan. A full-time job already breaks that assumption. A newborn destroys it.

So if you are in a season like that, I do not think the right question is "How do I stay disciplined enough to push harder?"

The better question is: what kind of project system still works when my week gets interrupted, my sleep gets weird, and my available energy changes day to day?

That is the only version that compounds.

I feel this directly in my own work. In the same general season that included a full-time job and a newborn at home, I kept shipping on PeerWealthy, ScreenshotEdits, PDFTry, and this site. The pattern that kept working was not heroic consistency. It was smaller bets, clearer restart points, and workflows that could survive interruption.

Why this question feels more relevant right now

The public builder conversation has changed a bit over the last few days.

The most interesting July 2026 posts are not really saying "grind harder."

They are saying two more useful things.

The first is that small teams can now do much more with the right system layer. A July 2, 2026 X post from Rasheedat Gee framed the next wave as one founder, a few AI coworkers, a shared operating system, and a long tail of integrations. The second is that building in public is looking less like overnight virality and more like compounding reps, visible progress, and repeatable output.

Those ideas also line up with the stronger operator guidance showing up elsewhere. Justin Norris's late-2025 operator roadmap for AI argues that the real leverage layer is context plus action: AI connected to the systems where work actually lives, not another disconnected chat window. Anthropic's Claude Code hooks guide makes the same point from a tool-design angle by focusing on deterministic lifecycle controls instead of vague autonomy. n8n's human-in-the-loop documentation does it from the workflow side by showing where automation should pause, wait, and let a human decide.

I do not bring those sources up because a side project needs enterprise architecture.

I bring them up because they all point to the same practical lesson: the work compounds when the workflow matches reality.

That matters even more when your reality is constrained.

The real constraint is not only time

Time is the obvious constraint, but it is not the hardest one.

The harder constraint is fragmented energy.

When you are working full-time and caring for a newborn, you often still have some pockets of time. What you do not always have is clean cognitive bandwidth.

That changes what kind of work is realistic.

A side project that depends on deep re-entry, perfect continuity, or long chains of hidden context becomes fragile very fast. If you miss two sessions, you are not only behind. You also forgot where the real decision was, what tradeoff was unresolved, and why you made the last technical or product call.

That is why I think a lot of side-project advice fails this season of life.

It is optimized for calendar space.

It is not optimized for interruption cost.

Those are different problems.

What started working better for me

I did not need more inspiration.

I needed a project shape that still made sense on low-energy days.

That changed five things.

1. I stopped designing projects around peak-energy fantasy

A lot of side projects are secretly built for the once-a-week superhero version of you.

The version that gets a free night, no urgent work spillover, no sleep debt, and perfect focus.

That version is great when it shows up. It is terrible as the dependency of your operating model.

The project needs to work for the tired version too.

That means smaller units of progress.

Not vague goals like "ship onboarding" or "rethink the homepage."

Clear actions like:

tighten one screen
write one positioning block
fix one broken workflow
publish one article
clean one data model edge case
improve one approval step

That is how a lot of my recent progress actually happened. Not through giant weekend sprints, but through smaller assets that could still move even when the week was noisy.

2. I made restart speed a first-class requirement

A side project dies much faster when every session starts with "Wait, where was I?"

That is why restart speed matters more than people think.

I want each project to answer three questions quickly:

what is the next useful move
what is the current constraint
what decision is still unresolved

If the answer is buried in memory, the project is too fragile.

This is one reason I keep coming back to workflow systems in my other writing. In The PM AI stack that actually compounds, I argued that context continuity is one of the real leverage layers. The same logic applies here. Durable notes, simple specs, and one explicit next step are not admin overhead. They are survival tools.

When a session ends, I want the next session to be cheap to restart.

That is much more valuable than squeezing out one more burst of output before bed.

3. I biased toward assets, not endless scope

During a compressed life season, the best side projects tend to produce visible assets early.

A page. A tool. A workflow. A draft. A product surface. A working slice.

That is part of why nielskaspers.com, ScreenshotEdits, PeerWealthy, and PDFTry have all been useful projects for me in different ways. They create visible proof surfaces. Even when the project is not fully done, there is something real to inspect, improve, link to, or show.

Asset bias helps because it keeps the feedback loop short.

It also protects motivation in a more honest way. Motivation becomes the result of visible progress, not the prerequisite for it.

If your side project only feels rewarding after six invisible months, the environment has to be unusually stable for it to survive.

4. I used AI to lower setup tax, not to manufacture fake progress

AI helps a lot in this season, but only when it removes real friction.

The highest-value use is usually not "make the whole thing for me."

It is reducing setup tax.

That can mean:

turning rough notes into a usable first draft
building the first pass of a small feature
rewriting a messy checklist into a cleaner workflow
preparing a spec so the next build session starts warm
handling repetitive transforms that would otherwise eat the whole session

That is the same practical lesson behind How I use Claude Code to build products as a PM. The win is not novelty. The win is that the artifact arrives sooner, which means the real judgment can start earlier.

But there is an important line here.

If AI gives you more outputs than you can realistically review, refine, or ship, it is not helping. It is just creating cleanup.

In a low-bandwidth season, that is deadly. You do not need more pile. You need less startup friction.

5. I protected the boring system more than the exciting idea

This is probably the least glamorous rule and the most useful one.

The side project does not need maximum excitement every week.

It needs a boring system that keeps it moving.

That system can be very simple:

one narrow active project at a time
one written next step before stopping
one repeatable slot or trigger for returning to the work
one quality bar before anything public ships
one clear reason the project deserves to keep existing

That is also why Why small teams beat big teams still feels true to me. Small teams win when the system is clear enough that momentum does not depend on constant coordination or emotional heroics.

A side project in a heavy life season is basically a one-person small team.

The same rule applies.

What I would stop doing first

If this season feels hard already, I would cut five things fast.

projects that require too many open loops at once
features that only matter after months of hidden build-up
tools that create more workflow overhead than shipped output
public accountability plans that add guilt instead of clarity
second or third active side projects that exist mostly because saying no feels boring

That last one matters.

A lot of side-project failure is really scope avoidance wearing a creative outfit.

One smaller project with visible progress usually compounds better than three exciting projects that never survive contact with your real week.

A checklist I would use before starting another thing

Interactive

Side-project reality check

Use this before you commit to a new project during a constrained season.

Completion

0%0/5 done

This is the gap between understanding the article and actually using it.

Use this block as the practical summary, not just the article ending.
If one item feels vague, the article probably needs sharper guidance.
A short checklist beats a long recap when the reader needs to act.

What still deserves ambition

None of this means lowering the standard for what the project can become.

It means changing the path.

I still think side projects are one of the best ways to build leverage, learn faster, and create opportunities that your day job would never hand you cleanly.

Some of the most valuable things I have built came from exactly that dynamic. A side project can become a product. A workflow can become a system. A proof surface can turn into a client conversation, a job signal, a distribution channel, or a real business.

But that only happens if the project survives long enough to matter.

That is why the romantic version of side projects is not very useful to me anymore.

The useful version is the one that respects the life season.

My broader take

If you are building a side project while working full-time and raising a newborn, I would not optimize for max output.

I would optimize for sustainable restartability.

Make the project small enough to move. Make the next step obvious enough to resume. Use AI where it removes setup tax. Keep one quality gate before public output. And bias toward visible assets that teach you something quickly.

That is not a glamorous system.

It is a real one.

And in a season where the week can break at any moment, real systems beat motivational speeches every time.