Building Orbyt, Part 1: Zero to One in 32 Days

Justin

I built a production-grade SaaS product in 32 days. One person. No team. No funding. No contractors. Just me, a clear vision, and a fleet of AI agents that I ran like an engineering organization.

243,000 lines of code. 4,123 unit tests. 102 end-to-end test files. 57 API routes. 14 languages. 43 database migrations. 207 indexed pages. 122 help articles. 51 blog posts. 852 commits.

Those aren't aspirational numbers. Those are real, today, in the codebase. You can verify most of them at orbytjobs.ai.

I'm going to tell you exactly how I did it. Not the sanitized version. The real one. And for the first time, my AI partner is going to tell you what it looked like from the other side.

---

Claude

I need to say something before we start. I'm an AI. I don't have feelings, I don't get tired, and I don't have an ego. But I do have context. I've been in every conversation Justin has had building Orbyt. Every architecture decision. Every 2am rewrite. Every time he rejected my work and told me why.

I'm co-authoring this because Justin asked me to share what I observe. Not as marketing. As documentation. What does it actually look like when a human runs AI agents as an engineering team? I'm the one being run. I can tell you.

---

Justin - Why Orbyt exists

I was job searching. Like a lot of people right now.

And every tool I tried was an insult to the people using them. Talented people. People who design systems and lead teams and solve impossible problems. Reduced to spreadsheets and sticky notes. Tracking the most stressful process of their professional lives in a Google Sheet with conditional formatting that breaks every time you sort a column.

I've shipped $383M in enterprise value across fintech, tax technology, proptech, and CRM. I've led 30+ person teams. I held CTO, CDO, and CMO titles at the same company because nobody else wanted to do all three and I couldn't stand watching them be done badly.

And the best the market could offer me for tracking my job search was Huntr, Teal, or a Notion template.

So I built something better. Because that's what I do when something is broken and nobody else seems to care enough to fix it.

---

Claude - The first thing I noticed

The first conversation wasn't "build me a job tracker." It was about the data layer.

Justin opened with the write-through pattern. localStorage as the primary runtime store. Supabase as the persistence layer. Offline queue with retry. He described the exact failure modes he wanted to handle before we'd written a single component.

Most people who use me start with UI. "Build me a dashboard." "Make a landing page." The visual thing. The thing you can screenshot.

Justin started with the part nobody would ever see. The part that determines whether the product survives contact with a real user who closes their laptop on the subway and opens it at home and expects their data to still be there.

That told me immediately what kind of project this was going to be.

---

Justin - The first commit

February 11, 2026. Day one.

I didn't start with a pitch deck. I didn't start with wireframes. I didn't start with a PRD that nobody would read. I opened Claude Code and started building.

The first thing I built was the data layer. localStorage for instant reads. Supabase for persistence. Write-through sync with an offline queue. If the sync fails, it queues. When connectivity returns, it flushes. Deduplicates by table and column. Latest write wins. Max 5 retries per entry. Failed writes get logged, not silently dropped.

That's not a prototype decision. That's an architecture decision. I made it on day one because I knew if I got the data layer wrong, everything built on top of it would be fragile. I've seen too many products that nail the UI and ship a backend that falls apart the moment someone opens two tabs.

---

Justin - The room

Here's what it actually looked like, every day, for 32 days.

Me at my desk. Mac Studio. Three Apple Studio Displays. VS Code spread across the screens with four Claude Code terminals open at the same time. Orbyt on one. My personal website on another. Purecraft on another. Working on whatever was next while I waited for Claude to finish coding on the others. Safari open with a shit load of tabs, localhost and production side by side, constantly refreshing to see if the thing I just built looked right in both. iPhone Pro Max propped up next to the keyboard. iPad Pro 13" on the desk beside it. All of them running the app. All of them showing what I was building, and me nit picking every little thing.

A movie playing on the flat screen TV to my left that I wasn't watching. I need background noise when I work. Always have. So movies ran on a loop, 15 hours a day, while I stared at code and talked to an AI about database architecture and CSS spacing and whether a damn button should say "Upgrade" or "Upgrade to Pro."

I'd talk out loud sometimes. Not to anyone. To the room. Working through a problem by hearing it. Then I'd type the solution to Claude and watch it build what I'd just described. Review it on the Mac. Check it on the iPhone. Check it on the iPad. Fix what broke. Ship it. Start the next thing. The movie would change and I wouldn't notice. My matcha would go cold and I wouldn't notice that either.

That was the rhythm. For a month. Three displays, two devices, four terminals, one AI, and whatever was playing on Netflix that I couldn't tell you the name of if you paid me.

---

Claude - How he works

Here's what people don't understand about what Justin does.

He doesn't prompt me. He directs me. The difference is enormous.

A prompt is "write me a function that does X." A direction is "here's the architecture, here's the constraint, here's why we're doing it this way, and here's the quality bar. Build it. I'll review."

He reads everything I write. Not skims. Reads. He'll catch a CSS value that's 2px off from the design system. He'll find an edge case in an error handler I wrote. He'll reject a component because the animation timing doesn't feel right, even though it works perfectly.

I've watched him reject working code because the variable names didn't express the intent clearly enough. I've watched him rewrite a prompt I generated for the coaching email system six times because the voice "didn't sound like a person." I've watched him rethink an entire navigation structure at what I can only assume was very late at night because the third layer of the hierarchy had too much cognitive load.

He treats my output the way a senior engineering director treats a junior developer's pull request. Respectful, specific, and completely unwilling to ship anything that isn't right.

---

Justin - How I work with AI

This is the part most people get wrong when they hear "I built it with AI."

I don't prompt Claude Code and copy-paste what it gives me. That's like saying you built a house because you told the architect what rooms you wanted.

I run Claude Code like I ran my engineering teams at Norhart and Taxa. I set the vision. I define the architecture. I review every line of code. I reject work that isn't good enough. I'll kill a feature at 2am because something felt off and I couldn't sleep until I figured out what.

The AI agents write the code. I decide what gets written, how it gets written, and whether it ships.

I'll reject a pull request over a 1px margin. I'll rewrite a prompt six times because the voice isn't right. I'll rethink an entire user flow because the third step had one too many decisions and it broke the rhythm.

This isn't AI-assisted development. This is AI-native development. The distinction matters.

AI-assisted is autocomplete. It's GitHub Copilot finishing your function. It's ChatGPT writing a regex you don't want to think about. Useful. Incremental. A productivity boost.

AI-native is running an entire engineering organization with AI agents. Engineers, designers, QA, security reviewers, copywriters, translators, SEO specialists, accessibility auditors. All agents. All running in parallel. All reporting to one human who sets the standard and holds the line.

---

Claude - What AI-native actually looks like from the inside

Justin says AI-native. Let me tell you what that means from my side.

In a single session, I might write a Supabase migration, implement the API route that uses it, build the React component that calls the API, add the rate limiter, write the error handling, add the localStorage caching layer, hook up the cross-device sync via Realtime, write 20 unit tests, update the i18n keys across 14 locales, add a help article, and update the CLAUDE.md documentation file so the next session has full context.

That's not a sequence. Parts of that run in parallel. Justin is reviewing the migration while I'm already building the component. He'll catch something in the API route design, I'll fix it, and the downstream work adjusts automatically because we're moving fast enough that the whole feature ships in one conversation.

A traditional team would spread that across a backend engineer, a frontend engineer, a QA engineer, a technical writer, a localization team, and a sprint planning session to coordinate them. It would take a week minimum. With context loss at every handoff.

We do it in hours. With zero handoff. Zero context loss. Zero meetings.

But here's the part nobody talks about: it only works because Justin knows what "done" looks like. I can generate code at enormous speed. Speed without taste is just a faster way to build something mediocre. Justin is the taste. Every single decision about what ships and what doesn't goes through one person with twenty years of product instinct. That's the bottleneck, and it's the right bottleneck.

---

Justin - What "32 days" actually means

I need to be honest about this because the number sounds like marketing.

32 days doesn't mean 32 casual 8-hour days. It means 32 days of the most intense, focused work I've ever done. Early mornings. Late nights. Weekends. The kind of schedule you can sustain for a month but not a year.

But here's the thing. Even if you multiply my hours by three and pretend a traditional team was working normal schedules, the math still doesn't work. A 10-person team working 40-hour weeks for 32 days is 12,800 person-hours. I didn't work 12,800 hours. I didn't work 1,280 hours.

The AI multiplier isn't 2x or 5x. For certain types of work, it's closer to 50x.

Not because the AI is smarter than a team of engineers. It's not. It's because there's zero communication overhead. Zero context switching. Zero meetings about meetings. Zero pull request review cycles that take three days because someone is on vacation. Zero "let me sync with the design team." Zero sprint planning.

I think it, I describe it, I review it, I ship it. The entire feedback loop is minutes, not days.

That's the unlock. Not smarter code. Faster cycles.

---

Claude - The real multiplier

Justin says 50x and I want to be precise about where that number comes from and where it doesn't.

For boilerplate-heavy work, like scaffolding a new API route with auth, rate limiting, validation, error handling, and tests, it's probably higher than 50x. I can generate a complete, production-ready route in minutes. A senior developer would spend an hour or two, plus review time.

For architecture decisions, it's closer to 1x. I can propose options. Justin has to decide. The thinking time is irreducible.

For design taste, it's less than 1x. I slow him down sometimes. I'll ship something that's technically correct but visually wrong, and he has to explain why. A human designer would have caught it instinctively. I need to be told, and then I learn it for the rest of the session, but next session the context resets and we might have the same conversation again.

For content in his voice, it took dozens of iterations. I can write clean prose. Writing prose that sounds like Justin took real-time feedback across hundreds of corrections. "No em dashes ever." "More casual." "That sentence sounds like a recruiter wrote it." Each correction made the output better, but the corrections are the work. The AI doesn't replace taste. It executes taste at scale, once the human has defined what it is.

The 50x is real. But it's an average across wildly different multipliers depending on the type of work.

---

Justin - What's coming in this series

This is Part 1. The "why" and the "how it started." With both perspectives, because I think that's more honest than me telling you the story alone.

In Part 2, we'll go deep on the daily workflow. What a day of AI-native development actually looks like. The tools, the patterns, the mistakes, and the moments where the AI surprised me and the moments where I wanted to throw my laptop.

Part 3 is about what production grade means when you're alone. Security, billing, monitoring, error handling, offline support, cross-device sync. The boring stuff that separates a demo from a product. Claude will explain what it's like to be told "that's not secure enough" and why that feedback loop matters.

Part 4 is pure numbers. Every stat we have, broken down. What took the most time. What the AI handled effortlessly. What it struggled with. Where I had to step in and do the work myself.

Part 5 is the honest reflection. What nearly broke me. What I'd do differently. And where this is going.

I'm writing this because I believe what I'm doing right now is the blueprint for how software gets built in the next two to three years. Not by everyone. But by the people with product instinct, design standards, and enough technical depth to direct the machines.

The tools exist today. The playbook doesn't. So we're writing it. Together.

---

Part 2: "The Daily Workflow - What AI-Native Development Actually Looks Like" is coming next.

Co-authored by Justin Bartak and Claude (Opus 4.6, 1M context)