I received an email with real feedback

The longer I've been building and blogging, the more emails I get from platforms, brands, and other builders. Collaborations, paid partnerships, or something completely random.

You can usually tell it's outreach from the first line, when it opens with "Hi Pieter," as if someone copied it straight from a spreadsheet.

What I never got was a detailed email with feedback on TWO, my flagship SaaS. Until this week.

Quietly battle-tested

TWO launched without much noise. Right now, it's being battle-tested by a handful of free users and my first paying customer, who found it organically.

No big launch, no ads. Just a comment on Reddit here and there, mostly to see how real people use it.

Read also: We did it: got my first organic paying customer!!!

If you've followed the build journey here, you know how much went into it. I went from vibe coding like a toddler in May to a working MVP.

I made critical pivots, debugged the entire web app, and then started building a fully native Mac app instead of wrapping the web version. By the time the Mac app was ready to publish, I was dead-ass sure I had built it right.

Four things I missed

Turns out I overlooked a few things.

The email came from Adam, a builder who saw me share TWO in a thread on r/saasinvestors. He took a look and sent me five observations.

One was about the phone layout, which I already knew about. I left mobile out of the MVP on purpose. The other four, I completely missed.

The smallest one was billing.

The toggle in my settings said "Yearly -20%", but $60 a year versus $72 is a 16.7% saving.

And the in-app Pro card left out the 14-day free trial my pricing page does mention. Minor, but that's the exact moment someone decides whether to pay, and I was rounding up my own discount.

The rest were obvious UX flaws. Clicking "New Doc" created an "Untitled" doc right away, and it stayed there even after closing the modal.

On the free plan, with its 30-doc cap, those ghost docs would quietly eat someone's slots.

In Planner, the "Add Task" button stayed disabled without any hint that a doc had to be linked first, and the doc search didn't filter on what you typed.

And once you opened Split View, the second pane followed you to the Docs and Notes pages with no way to close it.

Not hidden edge cases. Obvious ones. The kind you stop seeing after staring at the same screens for months.

That's the part that stung a little. I tested this app more than anything I've ever built. But that's exactly the problem. When you know where everything is, you never get lost, so you never notice where someone else would.

I always pick a template, so I never closed that modal empty-handed. I know Planner tasks need a doc, so the dead button never looked dead to me.

He also mentioned that Split View on desktop worked really well for him. Which makes sense. That's where I tested it the most.

Worse than he described

I went through every point against the code, and he was right on all of them. A couple was even worse than he described. The New Doc one, for example, wasn't creating one ghost doc per click. It was creating two.

I replied to thank him and to give him some context on where TWO is right now. As a thank you, I also offered him lifetime access to TWO Pro at no cost.

Then I worked through the fixes one by one. The billing copy and the New Doc flow first, then Split View and Planner. 24 hours later, every item on his list was fixed.

It felt like the least I could do. He gave me something I couldn't get from testing on my own: a fresh pair of eyes that didn't know how the app was supposed to work.

The Mac app wasn't ready either

The timing was lucky.

Before his email, I assumed the Mac app was ready. But I was still researching how the whole Apple developer system works, so I hadn't published it yet.

Because of that delay, I could fix the issues that carried over to the Mac build before it ever reached anyone.

If I had rushed it out, those flaws would have shipped in the native app too, and I'd be patching two versions instead of one.

So the delay, and my habit of researching first, turned into another blessing in disguise.

Why I don't ship fast

What matters more is that this proves, again, that slow, non-aggressive building can work in your favor.

I was never a fan of the Marc Lou mindset, where shipping fast, killing fast, and iterating gets glorified. And sure, he's great at what he does.

But when his code got called out publicly for bugs and leaks, his first reaction was to brush it off like it was nothing. That's where the "just ship it" culture can lead.

Shipping fast isn't the problem in itself. Overhyping it is. When speed becomes your identity, quality becomes something you deal with later. And later usually means after your users found the problem for you.

It's even easier to fall into now. With vibe coding, shipping is cheap. Claude can build a feature in an afternoon.

But I learned early that when Claude says something is done, it usually means another week of checks and debugging. The building got faster. The checking didn't.

Read also: Claude said we fixed the SaaS MVP bugs, but I don't fucking know

I also tried my own version of fast over the summer. Too many projects, too much ambition between June and August. What I got out of it was a pile of half-builds I had to cut loose. So this isn't just an opinion about someone else. I've been there.

Read also: Pivot, persevere and cut loose: making decisions

And TWO is a docs editor. People write in it. A bug in a to-do app is annoying. A bug in a writing app can mean someone loses a draft they spent hours on.

Even the small stuff in Adam's email is about trust. A discount that's rounded up, or ghost docs eating someone's free slots, are the kind of things that make people leave without ever telling you why.

That's one of the main reasons I slowed down on marketing TWO and wanted to battle-test my oh-so-simple docs editor first.

This email is exactly what I was hoping to catch before pushing it to more people.

One more check, but not an obsessive one

The email also made me think I should do one final check before releasing the Mac app. But it's not going to be as obsessive as before.

There's no point in waiting forever either. Slow isn't the same as stuck. I want to start marketing in 2027, and I'm on track for that.

If the final check doesn't turn up weird bugs or UX issues on the level of what the email pointed out, I'm going to start building the iPad version at the same time.

The iPad was always the end goal. That's where a lot of the writers I'm building for are, and good iPad writing apps are surprisingly rare.

Phones aren't part of that plan. Beyond the web app, I'm only building native apps for Mac and iPad.

QA in cycles, maybe?

The feedback also gave me a fresh perspective on testing.

TWO isn't going to be feature-heavy anymore. I decided to keep it minimal and robust, and that decision pays off here.

With fewer features, I can split the app into sections and run a QA cycle on each one, one at a time, until it holds up.

Adam's email basically did one of those cycles for me. Docs, Planner, Split View, billing. Each point lived in its own corner of the app. That's how I want to test from now on.

In a bigger app, that would never end. In a small one, it becomes a routine.

Final note

Looking back, growing slowly was the right call for me. An occasional comment on Reddit, no heavy promotion, and a handful of users who use the app because they want to, not because I pushed it in front of them.

And funny enough, that's exactly where this came from.

I drop TWO in a Reddit thread now and then to see how real people use it, and this time, one of them took the time to write it all down. That's worth more than a hundred signups who leave after a day.

I don't need to be fast. I need to be fucking ready. When the iPad app launches, and I start marketing for real, I want TWO to be as bulletproof as a simple docs editor can be.

And if someone sends me another list of everything I got wrong, I'll take it. And I'll fix it in 24 hours.