The fantasy version of this post would start with: "I wake up at 4am, ship code for three hours before work, and somehow never burn out."
That's not the reality. Let me tell you what actually works.
I've been building software projects alongside a full-time engineering job for over two years. I've made every mistake in the book. I've launched things nobody wanted. I've burned out. I've also shipped things that got real traction and had real customer conversations that made every late night worth it.
Here's what I've actually learned.
The Central Tension
Building on the side is fundamentally a resource allocation problem. You have finite energy — not just finite time.
Most advice focuses on time. "Use mornings." "Optimize your lunch break." "Cut Netflix."
But the real constraint is cognitive energy, not hours. If you've spent eight hours doing complex engineering work at your job, you don't have eight hours of creative building left. You have maybe two, if you're lucky.
The question isn't "where do I find the time?" It's "how do I protect my best cognitive hours for my own projects?"
The System I Use
I've iterated on a lot of systems. Here's what stuck:
1. Morning blocks are non-negotiable
Before email. Before Slack. Before anything that creates reactive mode in your brain.
I spend the first 60-90 minutes of my day on my own work. Not just weekdays — every day. This sounds extreme but it's actually liberating. It means no day is ever completely without progress.
The math: 90 minutes × 7 days = 10.5 hours per week. That's meaningful time if you use it well.
2. Single focus per session
The worst thing you can do in a 90-minute window is try to switch between three different tasks. Context switching costs are enormous.
Pick one thing the night before. Not "work on the app." One specific, completable task: "Write the API endpoint for user auth." "Fix the layout on the project card." "Write the landing page headline variations."
I keep a running list of these micro-tasks in Obsidian. The list is always longer than I can work through, which means I'm never thinking "what should I do?" — only "which thing from the list?"
3. Don't wait for the perfect project
I wasted a year "preparing" to work on my startup ideas. Reading books. Writing notes. Planning architecture.
None of that is the same as building.
The real skill isn't planning — it's momentum. And momentum only comes from doing. Ship something ugly. Show it to someone. Get feedback. Improve.
The first version of anything should embarrass you slightly. If you're not slightly embarrassed, you waited too long.
4. Ruthlessly protect weekends for exploration
Weekdays are for incremental progress. Weekends are for thinking bigger.
I use at least part of Sunday for customer conversations, market research, or exploring a new technology. This is where strategy gets refined. It's much harder to think strategically when you're also in execution mode.
The Mental Model Shifts That Changed Everything
Ship for learning, not for perfection
This sounds obvious but it took me a long time to really internalize. Every feature I'm building is a hypothesis. The point of shipping it is to find out if the hypothesis is true — not to have a perfectly built feature.
This completely changes how I write code. I'm not trying to make it production-grade on the first pass. I'm trying to test an assumption. I can refactor later, if the assumption proved correct.
Treat it like a second job
Not in a punishing way. In a professional way.
The goal is to show up consistently, make progress, and maintain quality — not to go all-out and burn out. I give myself weekends. I take evenings off when I'm mentally fried. I'm not trying to be heroic. I'm trying to be sustainable.
The founders I know who have built significant things over multiple years are the ones who figured out sustainable rhythms. The ones who went 100 miles per hour for three months and then quit don't have much to show for it.
Your job is funding your startup
One mental shift I made that completely changed my relationship to full-time work: my salary is a grant from a very generous investor (my employer) who is also helping me develop skills.
This reframe makes you grateful for your job instead of resentful of it. It makes it easier to show up and do good work. And it makes the financial risk of building a startup much lower — you're not gambling your rent money.
Validate before you build
The most expensive mistake a developer can make is spending months building something nobody wants.
I've made this mistake. It's demoralizing in a specific way — you've invested time and energy, you've gotten attached to the product, and then you find out the market just doesn't care.
Now, before I commit to building anything, I try to answer: who are 10 specific people who would pay for this, and have I talked to them?
Not "who might pay for this." Specific people. Conversations. Objections I had to overcome. Enthusiasm that felt real.
If I can't find 10 people who would pay before I've written a line of code, I kill the idea.
What to Do When the Day Job Gets Crazy
There will be periods where your full-time job consumes everything. Crunch time, launches, incidents, performance review season, etc.
Here's my approach: don't fight it, but don't disappear either.
During intense work periods, I drop the 90-minute morning blocks and just commit to 20-30 minutes. Sometimes it's just reviewing what I was working on, making a small commit, or writing one paragraph of a blog post.
The goal is continuity, not heroics. 30 minutes of progress is infinitely better than zero.
When the intense period passes, I come back to normal rhythm. The project is still there. The momentum is still there.
The Energy Game
A few tactical things that protect energy:
Exercise is non-negotiable. The days I skip it, I have 30% less mental energy. No exception. Even a 20-minute walk counts.
Protect sleep. Building at midnight is real but it's a debt. I try to be in bed by 11pm and it dramatically affects the quality of the morning work session.
Limit alcohol. One drink is fine. Two is noticeable. Three destroys the next morning.
Weekly review. Every Sunday I spend 20 minutes reviewing: what did I accomplish, what am I working toward, what's the one thing that would move the needle most next week?
The Honest Truth About Timeline
If you're expecting to build something significant in 3 months while working full-time — recalibrate.
Meaningful projects take a year or more to gain traction. The first version ships. Customer feedback comes in. You iterate. You find product-market fit slowly. You get the first few paying customers. The curve starts to bend upward.
This is a long game. The question isn't "can I build this in 3 months?" It's "can I sustain this for 2 years?"
If the answer is yes, you have a real shot.
If the answer is no — maybe the idea isn't right, maybe the market isn't interesting enough, maybe you need to find a co-founder. The honest assessment matters.
What I Would Tell My Earlier Self
- Stop planning and start building sooner. The plan is always wrong anyway.
- Talk to customers before you write code.
- Your job isn't the enemy of your startup — it's funding it.
- 90 minutes of focused work beats 8 scattered hours.
- Consistency over heroics. Always.
- The best ideas often come from problems you've personally experienced.
- Build in public as early as you're comfortable. The feedback loop is invaluable.
The dream of quitting your job to work on your startup full-time is seductive. But the founders I most respect built traction while employed — and quit when the math made sense, not because they romanticized the leap.
Be patient. Build consistently. And don't confuse busyness with progress.
Curious what I'm actually building? Check out the Startup Lab page — everything is documented there.