How do you vibe code a Mac app? Part 3: reset and Claude doing dumb stuff

On Tuesday, I got my first organic customer for TWO Docs. I let it sink in for a day, then went straight to the next big milestone: picking up the Mac app again.

This series is me trying to vibe code a fully native Mac app for my own SaaS with zero Swift experience. At the end of part 2, I said some huge Titanic disaster or dumbass fuckery would surface along the way. It didn't take long.

Read also: How do you vibe code a Mac app? Part 2: decluttering

Starting with a simple question

I opened Claude, asked for the current status, and repeated that I just needed an audit of the old build. I also asked what my options were for building a native Mac app.

The joke? Claude immediately suggested cutting corners. It pushed for a simpler version that leans heavily on the web app, the way Notion or Linear do it.

I said no. I need a fully native Swift Mac app, because the endgame is building the best possible version for iPad users. That's my ultimate target audience.

Claude kept pushing back and even pulled out a side-by-side comparison table to convince me. After a lot of debating, it finally came around and agreed I'm going for the right build, even if it takes longer.

Why I won't take the easy route

To be fair, the pushback was kind of understandable. Claude pointed out that most of the existing builds and features were fine.

The real challenge is the editor: moving away from TipTap, which lives on the web, into something that works natively on the Mac. That's the hard part, and that's exactly where a web-based shortcut starts looking tempting.

But I think going fully native is better long-term. I want TWO to be a SaaS that's clearly built for Apple devices, because that's always been who I'm building for.

Maybe my reasoning is flawed. But just like the name and the domain, TWO tie the DNA to the application; going full native and eventually building for iPad keeps me in check. It stops me from wandering off and building other shit.

So I pushed through, no matter how hard Claude tried to talk me out of it.

Read also: I turned down $8,000 for my domain, and built TWO Docs instead

Then Claude pulled a dumbass Claude

My stress level was already climbing. And just when I thought it couldn't get any worse, Claude went full fucking dumbass.

For context, this was running on Opus 5.5 on high, which I consider the best model for my work right now. It's been a while since Claude acted this far out of line. But no AI is bulletproof.

Read also: Claude got so dumb, so I stopped relying on it alone

I wanted to start with a clean slate, so the setup stayed the same as before: Claude chat for guidance and thinking things through, and Claude Code plugged into Xcode doing the building.

The first thing I asked for was another audit. Go over what can be reused and what's missing. And this is where I made a big mistake.

Claude ran a prompt that went way beyond that. Instead of just doing the fucking audit, it started altering the repo and building an iPad app on top of it. For some fucking reason. Which I didn't ask for.

Without thinking, I tapped through the instructions to download Apple's iOS 26.5 platform for iPad. A few seconds later, I realized what was happening. Claude was going rogue.

I hit the brakes hard. And yes, my blood was boiling to the point where I was typing in caps lock again. A hundred curses later, after telling Claude to fuck off with this nonsense, I had to step back and write out detailed instructions all over again.

Read also: Yelling at Claude works, and caps lock is a debugging tool

I only just came out of my toddler phase in vibe coding. Building a native Swift Mac app is completely new territory for me. And this motherfucker decides, completely out of scope, to start producing an iPad app when I've made it clear I don't want that yet.

Going slow to go fast

If there's one thing I've proved to myself in my builder's journey, it's that going slow helps you go faster, especially when everything is new.

If I'd let that slide, I'd have an iPad target I don't understand sitting inside a codebase I barely understand, and every problem after that would be twice as hard to trace.

I don't want to become one of those people who ship fast and die fast, or put out badly coded apps. TWO is my flagship SaaS, for fuck's sake. Not a throwaway build or a one-day project.

Read also: SaaS MVP is finally ready for BETA. My goodness what a ride

Finally, a proper audit

After some breathing exercises and a lot of back and forth, I finally got Claude to understand what the hell I wanted first.

And then, at last, a proper audit. Here's the message and the screenshot that made it all click:

"Step 1 is done. The checklist is saved in the Mac app's repo: 185 features in 16 sections, all private-workspace, nothing extra. This is now the full list of what the Mac app needs to do, and every step from here ticks items off it.

Next is step 2: login. Log in, stay logged in, log out, with sign up and forgot password opening the web."

Fucking hell. A "simple," non-bloated, minimal SaaS app with no AI in it, and the list comes out at 185 features in 16 sections.

No wonder so many wannabe builders ship bad stuff. I can't imagine what that list looks like for something bigger than my app.

The good news is that I now have a full checklist to build the native Mac app from the ground up.

With this, I can take one item at a time, test it, iterate, and tick it off. No guessing what's left, no vague feeling of being almost there.

Lessons all day

If I hadn't started digging into how the mechanics work, and into what Claude is doing and prompting behind the scenes, I would have blindly followed its instincts and instructions.

Being this deep into building things, with this much focus, helps me understand the reasoning and the prompts so much better.

That wasn't the case four months ago, when I was still copy-pasting full file replacements into the GitHub web editor instead of using Cursor. Back then, I would have watched Claude build that iPad app and assumed it knew something I didn't.

None of this takes away my main concern from the previous post. This is an application that lives on someone's Mac. Security and app size are still going to be a challenge, and I need to be sure I didn't fuck anything up.

Should the checklist go public?

Now that I have the full checklist, there's a question I keep coming back to. Should I put it out in public on the TWO website? Or is there a better option?

I already have a roadmap. But I feel like building this with full transparency might be a good move. Maybe I should.

Final note

TWO has its first organic customer on the web app. The Mac app has a reset, a repo I'm keeping on a much shorter leash, and a list of 185 freakin' things standing between me and something I'd be proud to put my name on.

For the first time, I have real hope that I can vibe code my MVP into a fully native Mac app. Not because it got easier, but because I can finally see how things work.

Read also: How do you vibe code a Mac app? Fuck I don’t know.

Next up is login. Log in, stay logged in, log out. The first boxes on a list of 185.

And if this series has taught me anything, the next dumbass fuckery is already loading somewhere.