How to Build a Side Project While Working Full Time
Working full time and want to ship a side project? Here's the exact system
Cristian Lascu
March 05, 2026
You've had the idea for months. Maybe longer. A tool you want to build. A newsletter. A small product that solves a problem you keep running into. You know exactly what it should do. You even know how to build it.
But you haven't started. Or you started and stopped. Or you've been "working on it" for six months and have nothing to show for it.
The root cause it's a systems problem. And most advice about side projects completely misses this.
Why Most Side Projects Die Before They Ship
The root cause isn't motivation. It's that most side project advice ignores the reality of building under constraints.
The standard advice is to "find time" or to "stay consistent." That's about as useful as telling someone who wants to run a marathon to "just keep running."
The reality of building something meaningful alongside a full-time job, especially a demanding one in technology, comes down to two forces that almost nobody talks about honestly.
The energy drain problem
After eight to ten hours of solving complex problems for your employer, your decision making tank is completely empty. Time is not the issue here as technically evenings and weekends still exist. The main problem is that you don't have the cognitive energy to make the thousands of small decisions that building something requires. What feature comes first? What technology stack? How should this component work? Should I refactor this now or later?
This is why so many side projects die on Friday nights. You sit down, open your laptop, stare at the code or the blank page, and nothing happens. This is not laziness. Is just your brain telling you it’s done after making decisions all day long.
Decision fatigue at end of day
Here's the less obvious part: it's not just that you're tired. It's that the decisions themselves are unbounded. When you're at work, someone else has defined the problem, the scope, the timeline. Your job is to execute within constraints that were set to you. Your side project has none of those guardrails. You have infinite options and zero external pressure. That combination can be paralysing.
The solution isn't more willpower. It's a system that removes decisions from the moment of execution.
The Mindset Shift That Changes Everything
Before any system works, you need to change how you measure progress. This is the part most people skip, and it's why their systems fail within a couple of weeks from starting.
Output vs. input thinking
Most people measure their side project by output: They keep asking themself if they have shipped that feature, launched it or simply pushed it to production. If the answer is "no" after few such weeks in a row, they feel like failures and ultimately quit.
The shift is to measure inputs instead. Did I sit down for my scheduled session? Did I work on the most important thing during that session? Did I make one decision that moves the project forward?
Inputs compound. Outputs are lagging indicators. If you protect your inputs, the outputs take care of themselves.
Progress over perfection
A live product with rough edges teaches you more in a week than a perfect plan teaches you in a year.
The second shift is accepting that your side project will be worse at start than what you build at work. It has to be. You have a fraction of the time, no team, and no QA process. If you hold your side project to the same standard as your professional work, you will never ship anything.
This is harder than it sounds for senior technologists. You've built your career on quality. Shipping something rough feels wrong. But the thing that separates people who build side projects from people who talk about them is the willingness to ship something imperfect and improve it later.
A live product with rough edges teaches you more in a week than a perfect plan teaches you in a year.
The Building Loop: A System for Constrained Builders
This is the framework I use for building under external pressure of work and constaints. I call it the Building Loop, and it has three phases that cycle continuously: Shape, Validate, Ship.
Shape: Define the smallest useful version
Before you write a single line of code or a single word of content, answer one question: what is the smallest thing I can build that is useful to one person?
Not the full vision. Not the roadmap. The smallest useful version.
When I started building this newsletter for example, the smallest useful version wasn't a website with a blog, an SEO strategy, and a content calendar. It was one email, sent to people I knew, that said something worth reading. Everything else came after.
Shaping means being ruthless about scope. Take your idea, cut it in half, then cut it in half again. What's left is probably still too big, but it's close enough to start.
The goal of shaping is to turn an overwhelming vision into something you can build in a few focused sessions. If you can't describe the scope in two sentences, it's not shaped yet.
Validate: Test before building
This is where most builders waste months. They build the full thing, then discover nobody wants it.
Validation doesn't have to be elaborate. It can be a conversation. "I'm thinking about building X feature: would you use it?" It can be a landing page with an email capture. It can be sharing the idea in a community and seeing if anyone responds.
The point is to get signal before you invest your scarce building time. An hour of validation can save you fifty hours of building the wrong thing.
For my Builder's Visibility Audit, a self-assessment tool I recently created, validation was simple: I mentioned the concept at the end of my first newsletter issue and watched the responses. Some people replied saying they wanted it. That was enough signal to build it.
Ship: Deploy before perfect
Shipping is a skill, not an event. The first time you ship something imperfect, it feels terrible. The fifth time, it starts to feel normal. By the tenth time, you understand that shipping is where learning begins.
Set a ship date before you start building. Make it uncomfortably soon. Then work backward from that date to decide what makes the cut and what doesn't.
The Building Loop then cycles: you ship, you learn what works and what doesn't, you shape the next iteration, you validate your assumptions, you ship again. Each cycle gets faster because you have real data instead of guesses.
Shape. Validate. Ship. Repeat. Each cycle gets faster because you have real data instead of guesses.
Practical Time Architecture
Frameworks are useless without the time to execute them. Here's how to actually find and protect building time when your calendar is already full.
Finding your "sovereign hours"
Not all hours are equal. You have periods during the week when your energy and focus are highest. For most people, this is early morning before the workday starts, or weekend mornings before the day fills up with obligations.
I call these your "sovereign hours": time that belongs to you, not your employer, not your family obligations, not your inbox. The key is to identify them honestly. Don't pick 10pm on a Tuesday if you know you'll be exhausted. Pick the slots where you actually have cognitive capacity.
For me, it's most of the mornings during a workweek as well as early Saturday and Sunday mornings. Two to three hours each, before anyone else is awake. That gives me six to eigh hours per week of high-quality building time. It's not a lot. But it's consistent, and consistency beats volume over any meaningful time horizon.
Weekly rhythm, not daily pressure
Daily commitments break within two weeks for most people with demanding jobs. A bad day at work, an unexpected meeting that runs long, a family commitment, and suddenly you've "failed" your daily goal and the whole system feels broken.
A weekly rhythm is more resilient. Set a target of hours per week, not per day. If you miss Tuesday, you can make it up Saturday. The psychology of weekly goals is fundamentally different: you're always recovering, never failing.
My rhythm: I aim for six to eight hours per week across three to four sessions. Some weeks it's four hours. Some weeks it's ten. The average is what matters, not any single week.
What to cut, what to protect
Building a side project means something else doesn't get your time. Be honest about what that is.
For me, it was passive screen time. I didn't cut exercise, family time, or sleep, those are load-bearing structures. I cut Netflix, blocked my phone from looking at social media, etc
You don't need to eliminate everything. You just need to eliminate low-value time that is mainly distracting you instead of being productive.
What to Build First
If you don't have a specific idea yet, or you have too many ideas, here's how to choose.
Start with your own problem
The best side projects solve problems the builder actually has. You understand the problem deeply. You know what existing solutions get wrong. You have immediate feedback on whether your solution works because you're using it yourself.
Every successful side project I've seen from senior technologists started this way. A tool they needed. A process they wanted to automate. A resource they wished existed when they were learning something.
The minimum viable asset
Think of your first project not as a product but as an asset — something that exists independently of your daily effort and provides value over time.
A blog post is an asset. A tool is an asset. A template is an asset. An email course is an asset. These things compound. They attract people to you. They demonstrate your expertise in ways that a résumé never can.
Start with the smallest asset you can create and ship within two weeks of sovereign hours. Then build the next one.
How to Keep Going When Motivation Drops
Motivation is unreliable. Every builder hits the point — usually around week three or four — where the initial excitement has worn off but the results haven't arrived yet.
Three things get you through this:
Make your progress visible. Track your building sessions, your shipped iterations, your decisions made. When motivation drops, look at the log. You've done more than you think.
Build in public. Share what you're working on, even if it's small. The accountability of having told people "I'm building X" is surprisingly powerful. It also attracts people who are interested in what you're creating, which creates its own momentum.
Connect with one person. One email from someone who used your tool. One reply to your newsletter. One comment that says "this helped me." That's enough fuel to keep going for another month. At this stage, you don't need an audience. You need one person who cares.
The One Thing
Your side project doesn't need more time. It needs fewer decisions at the moment of execution.
Build the system first. Protect your sovereign hours. Shape ruthlessly. Ship before you're ready. The Building Loop isn't just a framework, it's how you turn constraint into an advantage.
What I'm Building This Week
This article is itself an example of the Building Loop in action. I validated the idea by checking what people actually search for (and finding mostly thin articles without examples). I shipped it before I felt it was comprehensive enough, and here we are.
On the product side: I'm designing the next resource for The Sovereign Technologist, a practical toolkit that helps you set validate your idea more visually More on that in a coming issue.
What resonated? What did I get wrong? Hit reply: I read everything and I'm building this with you and with your input.
PS: If you haven't taken it yet, The Builder's Visibility Audit scores your career visibility across 6 dimensions in 2 minutes. Scored under 36? I'm still offering free Visibility Triage calls — book yours here.
P.P.S. Know a technologist building something on the side? Forward them this email. They can subscribe at thesovereigntechnologist.com.
That’s all for this week.
See you next Thursday.
