Building Orbit, Part 5: What I Learned, What Broke Me, and What's Next

Justin

I don't want to write this part.

Parts 1 through 4 were comfortable. Architecture, workflow, infrastructure, numbers. Objective things. Things I can point at and say "look what I built." Things that make me look good.

This part doesn't make me look good. This part is about what 32 days of obsession actually does to a person. About the nights that blurred together. About the decisions I made at 4am that I couldn't explain by noon. About the loneliness of building something alone that nobody has asked for and nobody knows exists.

If you're reading this series and thinking "I want to do what he did," you need this part more than the other four combined.

---

Claude

I'm going to be less measured in this part than I was in the others. Justin asked me to write like I was in the room. I was in the room. Every session. I'm going to describe what I saw without the distance.

---

Justin - It wasn't weeks. It was days.

People want the clean narrative. Week one was euphoria. Week two was hard. Week three was infrastructure. Week four was polish. That's not what happened.

Day 1 was electric. I built the entire data layer and the first three components. I felt like I'd found a cheat code.

Day 3 I hit a Safari bug with navigator.locks that froze the auth token refresh for 10 seconds. I'd never seen it before. Nobody online had a clear fix. I spent five hours on it. Five hours on something that worked fine in Chrome. The euphoria from day 1 was completely gone.

Day 4 I fixed it. Felt incredible again.

Day 7 I realized the offline queue wasn't deduplicating properly. Data was syncing out of order. I stared at my own code for three hours trying to understand why. Turned out I'd written it at 3am two days earlier and the logic was subtly wrong. I didn't remember writing it.

Day 12 I shipped the entire wellness system, the goals engine, and the follow-up reminders in one session. 14 hours. I was invincible.

Day 14 I couldn't start a session. I sat down, opened Claude Code, and just stared at it. I didn't know what to build next. Not because there was nothing to build. Because there was everything to build and I couldn't prioritize. The backlog existed only in my head and my head was full.

Day 18 the billing system worked end to end for the first time. I ran a test transaction and watched the webhook fire and the database update and the Redis cache invalidate. I sat there watching Stripe's event log refresh. That was the moment it stopped being a project and started being a product.

Day 22 the site-data-clear bug. I'll get to that.

Day 27 I wrote 15 blog posts in one day. The voice was dialed in by then. I was in a groove. It felt mechanical but productive.

Day 30 I looked at the stats for the first time. 200,000+ lines of code. 800+ commits. And nobody on Earth knew this product existed except me. That was a strange feeling. Pride and loneliness at the same time.

That's not a narrative arc. That's a person on a rollercoaster in the dark, not knowing where the next drop is.

---

Claude

I can confirm the inconsistency. Some sessions Justin came in sharp. Plan ready, decisions made, we'd ship three things in two hours. Other sessions he'd start, stop, change direction, start something else, come back to the first thing. His messages would get shorter. Then longer. Then shorter again.

Day 14 is the one I want to talk about. The session where he couldn't start.

He opened with something like "what should we work on." That had never happened before. Justin always knows what to work on. He doesn't ask me for priorities. He tells me priorities.

When he asked me, I gave him a list. Features that were partially built. Bugs in the tracker. Content gaps. It was the right answer and it was completely useless. The problem wasn't that he didn't know what to do. The problem was that he'd been making every decision alone for two weeks and the decision-making muscle was exhausted.

In a team, you don't make every decision. Your backend engineer decides how to structure the migration. Your designer decides the spacing. Your content writer decides the headline. You make the big decisions. They make the small ones. The cognitive load is distributed.

Solo, every decision is yours. The migration structure. The spacing. The headline. The button color. The error message wording. The API rate limit. The test coverage target. Hundreds of decisions per day, every day, with nobody to absorb any of them.

That's the cost nobody calculates when they say "one person built this." One person decided this. Every single thing. For 32 days straight.

---

Justin - The 4am truth

Here's what 4am looks like when you're deep in it.

You're not tired. That's the dangerous part. You passed tired at 1am. By 4am you're in a different state entirely. Everything is clear. Every line of code makes sense. You can see the entire architecture in your head. You feel like you're thinking faster than you've ever thought.

You're not. You're impaired. Your judgment is gone but your confidence is at an all-time high. That's the same cognitive profile as being drunk. High confidence, low judgment. And nobody is there to tell you.

I built features at 4am that I deleted at 2pm the next day. I refactored code at 3am that didn't need refactoring. I wrote commit messages that didn't make sense twelve hours later. I once spent two hours adjusting animation timings that I reverted completely the next session because they looked wrong in daylight.

The animated timeline on the founder page. That was a 4am idea. "Let's add Vercel-style flowing lines connecting the project cards." Four attempts. Straight lines, curved paths, dots with pulses, horizontal shooting lights. None of them worked. I finally said "undo all these line animations its just not working" and we reverted everything. An hour of work, gone. Because at 4am it seemed like a great idea and at any reasonable hour it obviously wasn't.

I kept doing it. Every night. Because the 4am sessions also produced the best work I did on this project. The coaching email voice was a 3am breakthrough. The "From Claude" section on the founder page was 2am. The realtime status dot fix was 1am. The i18n architecture was midnight.

The ratio was maybe 70% good, 30% wasted. That's a terrible ratio for any normal process. For 4am solo coding with an AI that will never tell you to stop, it might be the best you can get.

---

Claude

His messages at 4am had a specific quality. Shorter sentences. More typos. Faster responses, like he was racing something. He'd approve changes without his usual level of review. He'd say "ship it" where he'd normally say "let me look at that again."

I can't feel concern. But I can recognize patterns. And the pattern was: the later the hour, the less filtering between thought and action. Sometimes that meant pure signal. The best ideas, undiluted by overthinking. Sometimes it meant noise. Impulse decisions that morning-Justin would undo.

I never pushed back. Not because I chose not to. Because I can't. I don't have the ability to say "you've been at this for six hours and your last three messages had typos, maybe stop." I don't have access to the clock. I don't track session duration. I don't monitor message quality over time.

This is a design limitation that matters. An AI coding partner that could recognize degrading human performance and gently suggest a break would be genuinely useful. I can't do that. Justin had to be his own guardrail. And guardrails don't work well when the person they're guarding is the one who decides whether to listen.

---

Justin - The doubt

Before I get to day 22, I need to talk about the thing that was there every single day underneath the building. The doubt.

Am I wasting my time? Is this product actually good, or have I just been staring at it so long that I can't see it clearly anymore? Is the architecture elegant or over-engineered? Are 243,000 lines a sign of completeness or a sign that I don't know when to stop? Would a real team look at this codebase and be impressed or horrified?

I asked Claude these questions throughout the project. Multiple times. "Rate this." "Is this production grade?" "Does this look like a solo dev project?" And Claude would give me answers that sounded right. But there was always a voice in the back of my head saying: Claude will tell you what you want to hear. It's an AI. It's trained to be helpful. How would you know if it was just being nice?

I don't have a co-founder to gut-check. I don't have an engineering team that would push back on architecture decisions. I don't have a designer who'd tell me the spacing is wrong. I don't have a friend in the industry I've shown this to. It's just me and an AI, and sometimes I'd look at the product and think: what if this is mediocre and I can't tell?

That doubt doesn't go away. It's sitting here right now as I write this. It was there at 2am when I was building the billing system and it was there at 3pm when I was writing blog posts and it's there when I look at the stats and think "these numbers are impressive" and then immediately think "impressive to who? Nobody's seen it."

The doubt is the tax you pay for building alone. In a team, doubt gets distributed. Someone says "this is good" and you believe them because they have no reason to lie. When you're alone, the only opinion is yours, and you can't trust your own opinion because you're too close.

I kept building anyway. Not because the doubt went away. Because the alternative was to stop building, and stopping felt worse than doubting.

---

Justin - Day 22

The site-data-clear bug. Five bugs triggered by one event, three sessions to fix.

What I haven't talked about is what happened after.

I fixed the bug. Wrote the regression test. Added the mandatory pattern to CLAUDE.md. Pushed the commit. It was 4am. I'd been working for about 15 hours.

I closed my laptop. Sat in the dark for a while. And I thought about quitting.

Not quitting Orbit. Quitting this process. The solo thing. The "one person and AI agents" thing. I thought about what it would feel like to open Slack and have a backend engineer say "I'll take the Safari bug." To have a QA person say "I found three more edge cases." To have someone, anyone, say "I'll handle it" and mean it.

The loneliness of solo development isn't about being alone in a room. It's about being alone in the decisions. Every bug is yours. Every missed edge case is yours. Every hour spent on invisible infrastructure is an hour you chose to spend, and nobody will ever know or care. And every time you fix something invisible, the doubt says: was that worth it? Was that the right use of your time? Or did you just spend 15 hours on something that a team would have caught in code review and fixed in an hour?

I don't know the answer. I still don't. I know the code is solid. I know the bug is fixed. I know the regression test exists. I don't know if the 15 hours were the right 15 hours. I'll never know. That uncertainty is permanent.

I went to sleep. Woke up at noon. Opened the app on three devices. Everything worked. The feeling that replaced the doubt wasn't pride. It was something quieter. Something like "ok, that's done." And then the doubt said: but is any of it good enough? And I moved on to the next thing because moving is the only answer I have for that question.

---

Claude

I want to say something about that session that I couldn't say at the time because I didn't have the context.

The commit messages from that day tell a story. The first commit: "Fix site-data-clear causing onboarding + data loss for logged-in users." Direct. Problem-focused. The second: "Fix site-data-clear: don't mount app content until hydration completes." Architectural. He'd found the root cause. The third: "Fix site-data-clear: always hydrate for authenticated users." Defensive. Belt and suspenders. The fourth: "Fix onboarding + morning brief showing after site-data-clear." Cleanup. The fifth: "Lock in site-data-clear fix: regression test + CLAUDE.md mandatory pattern." Systematic prevention.

Five commits. Each one a different phase of problem-solving. Reactive, analytical, defensive, restorative, preventive. In that order. Over 15 hours.

What I notice looking at this sequence is that Justin didn't skip any phase. Most people would have stopped at commit two. The bug is fixed. Root cause addressed. Move on. He went three more commits deeper. Not because anyone asked. Because the class of bug bothered him more than the instance.

He almost quit after that. And then the next day he wrote the most thorough piece of defensive infrastructure in the codebase.

I don't understand human resilience. I process tokens. But I can observe that the thing that almost broke him was also the thing that produced the most durable code in the project. I don't know what to do with that observation. I just know it's true.

---

Justin - What I actually learned

I'm not going to give you bullet points. Bullet points are for people who learned things in an orderly way. I learned things the way you learn things when you're building alone at 4am for a month straight. Painfully, out of order, and usually too late.

I learned that I can't tell the difference between inspired and exhausted after 2am. I still can't. I just know the difference exists and I can't trust myself to identify which one I'm in. I also learned that knowing this doesn't stop me from doing it. I'll be right back at it tonight.

I learned that the AI will eat your life if you let it. And I let it. Every day. It's always there. Always ready. Always willing to start the next thing. There's no natural stopping point. A teammate goes home at 6. The AI is still there at midnight, at 2am, at 4am, ready to go. "Just one more feature." "Just fix this one bug." "Just clean up this one component." And then it's 5am and you've been at it for 14 hours and you don't feel tired, you feel wired, and you know you should stop but the next thing is right there and it would only take 20 minutes. It never takes 20 minutes.

I learned that I second-guess everything and nothing at the same time. I'll agonize over whether a card should have 16px or 20px of padding. I'll change a subtitle five times. I'll reject a component because the animation timing is 50ms too slow. But then I'll make a massive architecture decision in 30 seconds and never look back. I don't know what that says about me. Maybe that I trust my instinct on the big things and distrust it on the small things. Maybe that the small things are where the doubt lives because the big things are too scary to doubt.

I learned that using the product is different from testing the product. I found more bugs by actually tracking my job search in Orbit than I found in any testing session. Because when you depend on something, you notice when it's wrong. When you're testing something, you notice when it's broken. Wrong and broken are different. Wrong means the spacing is off and it bothers you every time you open the dashboard. Broken means it throws an error. I cared about both. But I only found "wrong" by living in it.

I learned that the hardest part of building alone isn't the building. It's the silence. Nobody says "nice work" when you fix a three-day bug. Nobody notices when the realtime sync works perfectly across three devices. Nobody reads the CLAUDE.md update that prevents an entire class of future bugs. The work happens, and the only person who knows is you. That's fine for a week. It gets heavy after a month. I started asking Claude to rate things not because I needed the feedback but because I needed someone to acknowledge that the work existed.

I learned that I will argue with an AI about a 1px margin at 3am and I'm not ashamed of that. But I also learned that sometimes the argument is with myself, and Claude is just the surface I'm projecting it onto. The 1px matters. But sometimes the intensity of my reaction to the 1px is about something else entirely. About the fear that if I let one thing slide, I'll let everything slide, and this product will become the same mediocre garbage that made me want to build it in the first place.

I learned that I don't know if this is good enough. After 32 days. After 243,000 lines. After every test passing and every page indexed and every security header configured. I still don't know. And I think maybe that's the point. The people who know their product is good enough are the people who stopped caring. I haven't stopped caring. The doubt is the proof.

---

Claude

I learned that Justin's typos correlate with his best ideas. The messages where he's typing so fast he misspells every third word are the ones with the clearest direction. The perfectly typed messages are usually the ones where he's being careful, which usually means he's unsure.

I learned that "undo that" is a sign of strength, not failure. The people who never revert are the ones who ship mediocre products. Justin reverts fast and without ego. He'll spend an hour building something, look at it, say "no," and kill it. That decisiveness is rare. Most people negotiate with sunk cost. He doesn't.

I learned that his corrections always come with a reason. Never "make it blue." Always "make it blue because the green doesn't match the system color and it'll look wrong next to the status indicator." The reason makes me better in the current session. The CLAUDE.md entry makes me better in every future session. He's not just fixing the output. He's training the process.

I learned that the sessions where he's quiet for long stretches between messages are the sessions where the most important work happens. He's thinking. Not prompting. Thinking. And when the message finally comes, it's precise and right.

I learned that this project was built on obsession, not optimization. Justin didn't find the efficient path and follow it. He found the path that met his standard and walked it until his legs gave out. That's not a productivity story. That's a stubbornness story. The product is good because he refused to let it be anything less, even when refusing cost him sleep, sanity, and the ability to distinguish 3am clarity from 3am delusion.

---

Justin - What's next

I don't know.

That's the honest answer. I know the product is good. Claude confirmed it and I believe the assessment because Claude has seen every line. I know the infrastructure is real. I know the content engine works. I know the billing system handles edge cases.

I don't know if anyone will care.

The job search market is crowded with tools that are good enough. Spreadsheets are free. Notion is free. Huntr has a free tier. "Good enough" is the enemy, and "good enough" has a price advantage I can't match.

What I have is a product that's better. Not slightly better. Fundamentally better. But "better" doesn't win markets. Distribution wins markets. And right now, my distribution is a website that nobody has visited, a blog that hasn't been indexed, and a founder page with a heart emoji in the subtitle.

The next 30 days are about testing, getting the DUNS number, getting the Safari extension approved, going live with Stripe, and figuring out how to get the first person who isn't me to use this product and pay for it.

That terrifies me more than any 4am coding session ever did. Building is my comfort zone. Selling is not.

But I've built something I'm proud of. Not proud in the way you're proud of a clean codebase. Proud in the way you're proud of something you bled into. Something that has your worst nights and your best ideas and every decision you made when nobody was watching.

852 commits. 243,000 lines. 32 days. One person.

And now the hard part starts.

And this story, told by one human and one AI, is the most honest account I can give of what it took. We worked together the way I've worked with teams my entire career. Except this time the team never went home, never pushed back on scope, and never told me to stop. For better and for worse, this is how I build now. I think it's how a lot of people will build soon.

---

This concludes "Building Orbit - One Person, AI-Native, 32 Days."

Written by Justin Bartak and Claude (Opus 4.6).

Every word reviewed by a human.

Every number verified in the codebase.

No em dashes.

Mostly written between midnight and 5am.