The Product Decisions I Got Wrong (And What I'd Do Differently)

One of the things I committed to when I started building in public was being honest about the mistakes. Not just the technical ones — those are easy to talk about because they have clean solutions — but the product decisions that seemed right at the time and turned out to be wrong.

14 months in, I have enough distance to see some of them clearly. Here's the honest accounting.

In stream #1, I picked React Navigation for the app's routing. It was the obvious choice — most popular, most documented, most Stack Overflow answers. I didn't think hard about it because it felt like a solved problem.

Eight months later, I was fighting the navigation library on almost every complex screen transition. The nested navigator pattern I needed for the feed → profile → post → profile flow was producing bugs that took me three streams to debug. The community in the chat kept suggesting I look at Expo Router. I kept saying "I'll migrate later." (The chat being right about things I'm slow to act on is a recurring theme — I wrote about how the chat dynamic actually works in What Nobody Tells You About Streaming Your Code Live.)

I finally migrated in month 11. It took two weeks and broke four features in ways I didn't anticipate. The app is better now — the routing is cleaner, the deep linking works properly, the code is half the size. But I lost two weeks I didn't have, and I introduced bugs that some of my beta users hit.

What I'd do differently: Spend one full stream evaluating navigation options before writing a single route. The "obvious choice" in mobile development is often the legacy choice.

I built the core feed, the post creation flow, the profile system, the notification system — and then, three weeks before beta, I built the onboarding flow. In four days. While also fixing a critical bug in the feed algorithm (that rewrite has its own story — the algorithm rewrite that almost broke everything).

The result was an onboarding flow that worked but didn't convert. Beta users were dropping off at step 3 of 5. The step where I asked them to follow five accounts before seeing any content. I thought this was smart — seed their feed before they see an empty state. It turns out it felt like homework.

I've since redesigned it twice. The current version has a 73% completion rate, up from 41%. But those first 200 beta users got the bad version, and some of them formed an impression of the app that I can't undo.

What I'd do differently: Build a rough onboarding flow in month two, before any other feature. Onboarding is the first thing every user experiences. It deserves more than four days at the end.

In month six, I built a trending topics sidebar. It took three weeks. It pulls from post tags, weights by recency and engagement, updates every 15 minutes. It's technically solid.

Nobody uses it.

In the beta, I can see session recordings. The trending sidebar gets almost zero clicks. Users scroll past it. When I asked in the stream why they weren't using it, the chat was pretty direct: "I don't come here for trending topics, I come here for the people I follow." This is the same feedback I got from the first beta users — they care about the people, not the discovery surface.

I built a feature based on what social media apps look like, not what my specific users actually want. My users are builders. They want to see what the people they follow are building, not what's trending. Those are different products.

The sidebar is still there. I haven't removed it because removing features feels like admitting defeat, which is its own mistake. I'll probably remove it in the next release.

What I'd do differently: Talk to ten users before building any feature that isn't directly on the critical path. Not a survey — actual conversations. "What would make you open this app every day?" The answer would not have been "trending topics."

This one is subtle and I'm still working through it.

Because I stream the build, I'm always aware of what looks good on stream. A new feature that's visually impressive gets a better reaction than infrastructure work that makes the app faster. So I've consistently prioritized features over performance.

The app is slower than it should be. The feed loads in about 1.2 seconds on a good connection. It should be under 500ms. I know exactly what needs to change — better pagination, smarter caching, a few query optimizations. I've been putting it off for eight months because it's not exciting to stream.

This is a real problem. Daily active users care about speed more than features. I've been building for the demo audience, not the daily user.

What I'd do differently: Dedicate one stream per month explicitly to performance. Make the infrastructure work visible and interesting. The audience actually responds well to optimization streams — I've done two and they were some of my most engaged sessions. I just don't do them often enough.

Looking at these four mistakes together, there's a pattern: I consistently optimized for what was visible and immediate over what was foundational and long-term. The popular navigation library. The onboarding flow built last. The flashy feature. The demo performance.

This is a bootstrapper's trap. When you're building alone, with limited time, the pressure to show progress is constant. Progress that's visible — a new screen, a new feature, a new number going up — feels more real than progress that isn't. So you build the visible thing.

The problem is that the invisible things are usually the ones that determine whether the product actually works.

I don't have a clean solution to this. I'm still in it. But naming it helps.

If you want to follow along as I work through these, the streams are where the real-time problem-solving happens. The newsletter is where I write about what I learned after the fact. And if you want to see how these lessons are shaping the final push, 30 Days to Launch is where I'm tracking the current state of everything.