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

It's been a while since I picked this up again. I wrote the first post in this series on August 22nd, and honestly, I still have no fucking clue what I'm doing.

If you haven't read it,

start here: How do you vibe code a Mac app? Fuck I don't know.

Since that post, I've had a few lightbulb moments, including the slightly embarrassing realization that I was barely using my own SaaS. That led to a pivot, some real changes to the UX in the web app.

I'll get into those in a separate post. But while making those changes to the original app, I realized I was running ahead of myself.

The two parts I forgot to think about

Simply put, my docs editor has two major parts. There's the single, private workspace, which is the default for every user. And there are shared workspaces, which depend on which tier you're on.

During a sanity check on the MVP, I asked Claude a simple question:

"Should I build the Mac app completely, or focus on private workspaces first?"

Deep down, I already fucking knew the answer. And I think anyone with half a brain would agree with what Claude wrote back. I'm leaving the quote exactly as it was, because it's the quote that decided for me.

"Shared workspaces are not a small add-on. They're closer to a second product surface (their own homepage, their own permission model, their own set of edge cases around discoverability and consistency).

For an app that's already unpublished and needs a lot of foundational work, shipping a genuinely solid single-player experience first, matching TWO's actual core pitch of a focused personal writing tool, seems like the lower-risk sequencing.

Layering shared workspaces on afterward, once the web app's model is stable and battle-tested, avoids building Mac-native collaboration UI against a data model that might still shift. But this is your call to make, not mine; you know the roadmap and user commitments better than I do."

That's where it goddamn hit me: I should declutter and start slow.

I can barely walk in this field, let alone handle a full Mac app carrying every complex feature from the web version.

This is the first time I've done anything like this; my last post made that painfully clear, and my confidence level is still sitting at zero, if not under fucking zero.

Read also: I build software like a toddler learning to walk

So I asked myself something more useful: how do I build confidence in a field I know nothing about, while worrying about a piece of software landing on someone's computer that might eat memory or open up security holes?

Even though TWO is "just" a simple docs editor, I care a lot about compliance and security risk. Maybe there's no real risk there. I really don't fucking know. And that's exactly the problem; I can never be sure until I've built the freaking thing.

New game plan

I can't make drastic decisions right now. My original plan for September was to partially build the Mac app. But my BETA invites are out, my content strategy is set, and that changes things.

I still want to wait on BETA feedback before going further with features, but nothing is stopping me from building the local Mac app first, unpublished, just to get real experience with Swift and understand the process.

And since I'm only focusing on individual private spaces in the Mac app, a lot of the friction and stress disappears immediately.

In theory, I can try to build a first version of the Mac app before the end of September, leaving shared workspaces out completely, and test it with whatever small group of BETA users I can find along the way.

That feels far more sensible than trying to carry the full scope of the web app into native code on day one.

Read also: My honeymoon phase with vibe coding is over

Decluttering makes the whole approach better. I'm still not confident. But I'm a bit more optimistic than I was a few weeks ago, and I'll keep sharing exactly how this goes, good or bad, without leaving anything out.

But we all know some huge Titanic disaster or dumbass fuckery will surface in my Mac app journey.