My docs editor SaaS app was, and still is, seriously flawed

I'm so fucking glad I didn't push my MVP aggressively to market until now. That sounds like the opposite of success, but I'm convinced it's a win, not a failure.

Right now I'm running into the exact thing I was most afraid of: lack of oversight, features, structure, and basic things that were supposed to work but don't.

Not long ago I admitted in a blog post that I was underusing my own SaaS build, and that self-criticism was justified.

Around the same time, I looked again at my attempt to build a Mac app, but before touching more code, I asked for an audit of where things stood.

Turns out that was the right call, because both of those decisions collided into a genuinely messy situation I'm still working through.

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

Context

The moment I realized I was underusing my own app, I changed how I worked. It took about 30 minutes to see how much I'd missed, just on the surface.

Subfolders couldn't be created. Moving docs within subfolders was broken. Moving docs to certain folders didn't work. Performance was off. And that was just the start.

Fuck, I could have kicked myself right there, and I nearly did. Instead, I started fixing things one by one.

This was mostly focused on personal use, not shared workspaces, which made it worse in a way, because I kept thinking: what the fuck am I still missing?

I thought my MVP was ready, and some of the most basic things weren't done at all. Most of it is fixed now and rolled out, and I wrote about it in a changelog, but I'm not close to done.

Read also: MVP is finally live, and I'm proud of it: update #7

The Mac app

This is what convinced me I shouldn't keep building a Mac app right now. Every time I change something in the web app, I'd have to update it in a half-ass-finished Mac build too, in Swift, which I'm nowhere near fluent in.

So I did what anyone with a functioning brain would do: a full audit first, then a list of what's done, and a decision on what to cut for now.

Claude Code is connected to Xcode, so I can give it instructions and spend my time verifying rather than writing Swift myself.

I'd already decided to focus on single-person use on the Mac app first, before touching shared workspaces at all. That instinct was right too. My own limits as a builder are still very much present, and diving into a full Mac app on top of everything else would have been reckless.

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

On September 8th, Claude Code gave me a full audit, which I turned into an artifact for future reference. I added some screenshots and timestamps in this blog post so I can check back later.

It's clear from that audit that I deliberately deferred the shared workspace module. It's too early for that, and that decision was made earlier on.

I took a break after that and started wondering:

• Is the current MVP ready?

• Am I missing anything critical?

If I'd already found this many fucking problems in private workspaces, what was I going to find in shared ones? Fucking hell, I wans't happy about that idea.

So I pulled that trigger too, and ran a long prompt in Cursor asking for a full report. The most critical findings are:

• The core premise of shared workspaces is broken.

• A viewer or commenter can currently create docs inside a shared workspace, which shouldn't be possible.

• An admin can't move a doc into a teammate's folder, which contradicts the rule that admins manage any folder, something I missed in my original role hierarchy prompt.

• There's a regression from that same prompt where the sidebar's quick "new folder" action doesn't check whether the request actually succeeded.And most move and delete handlers across the app update the local state optimistically without checking whether the request succeeded either.

When I read that the core premise of shared workspaces was broken, I fucking lost it for a second.

I'm working through all of it now, checking carefully that none of it touches core infrastructure like split view, syncing, or live edits. So far it doesn't, and it shouldn't.

The upside is that none of this touches individual accounts, only shared spaces. Worst case, if I can't fix it all in time, I temporarily suspend access to shared workspaces.

Shipping fast is a pipe dream

Some solo devs and a few influencers on X preach shipping fast like there's no tomorrow. Some of them got burned and heavily criticized for it once people found their code full of leaks, security risks, and half-finished features.

Their response? Shrug it off like it's no big deal.

And this, from my own experience, is exactly why I'd rather go slow now so I can go faster later. I'm sure there are plenty of people like me, touching code for the first time, thinking vibe coding is the ultimate fucking golden ticket to building frictionless apps and taking a moonshot at becoming the next unicorn.

Read also: My honeymoon phase with vibe coding is over

It's exactly why I lead with slow marketing, building organic growth and content before pitching aggressively to outsiders, let alone launching somewhere like Product Hunt.

The tooling to build something out of thin air is there, but a real docs editor app is not the same thing as a stupid $12 website with a few tweaks.

I don't need a perfect MVP. But I do need to recognize my own failure of underusing my own app, and then discovering how much of it was full of holes.

Imagine launching this in public with an MVP this broken, not even getting the folder structure right in private workspaces. I'd have been drained by customer feedback and spent more time stressing about things I should have handled in the first place.

I don't mind bugs in an MVP. What I do mind is not being able to tackle every front at once, then having to fix things once there are too many people already on board.

Shipping fast has never been my thing, and this is proof of why.

I hope this is a lesson for less experienced developers and vibe coders too: being diligent and slowing down gets you better results long term.

Game plan

I could have skipped writing about this, but I need this on record publicly to hold myself accountable and to register how much I need to adjust. The plan is simple:

Work through every missing item one by one. Run another full QA pass. Test shared workspaces completely and repeat that process. Pause the Mac app entirely, since it makes little sense to keep building it right now.

Final note

My app is flawed, and I'm okay admitting where I'm currently falling short. I see this as a cheap lesson rather than an expensive one, one I got to learn before real users were the ones complaining.

I'm confident in what I do, but I also know my limits. The biggest thing I've learned is that a bit of self-doubt is a form of prevention. It keeps me sober, keeps me from crossing into arrogance, and keeps me from pretending I'd already built a perfect web app, because I still haven't.