Getting to Launch

There's a version of building that looks clean from the outside.

Idea → prototype → build → launch.

That version doesn't include the pauses. Or the rethinking. Or the small moments where you're no longer sure whether you're improving something or slowly losing clarity.

Girl Dinner Mode didn't move in a straight line. It changed shape as I built it. Not once — continuously.

At first it was a loose idea about decision relief. Then it became a set of interactions. Then a system. Then something closer to a product I had to actually ship into the world.

Each stage introduced a different kind of uncertainty.

Early uncertainty is abstract. You question the idea. Later uncertainty is more specific. You question every decision inside the idea.

Is this the right logic?
Is this too simple?
Is this too opinionated?
Is this not opinionated enough?

At some point, building stops being about inventing and starts being about choosing. And choosing forces tradeoffs you can no longer keep theoretical.

I expected some of this.

As a product manager, I've spent years inside scope discussions, MVP definitions, prioritization frameworks, and the gap between what people want and what can actually be delivered. I've been in rooms where we talked about cutting features I knew would matter later. I've also been in rooms where "later" became a place everything disappeared into.

So I knew the rules.

What I didn't fully anticipate was what it feels like when you are both the person defining the scope and the person resisting it expanding in real time.

Scope creep isn't just a backlog problem when you're building alone. It's a thought pattern.

A constant quiet suggestion that you could make it better if you just added one more thing. One more edge case. One more user type. One more layer of intelligence. One more safety net.

At some point, you have to decide what version of "better" you're actually building toward.

One of the hardest shifts was accepting that I could not design for everyone. This is something I've said in product strategy decks for years. It is much harder to believe when you are the one writing the product logic.

When you're close to every decision, it becomes tempting to hold the entire edge case space in your head at once. But those are not design inputs. They are infinite. And infinity is not shippable.

At some point, the product stops improving and just starts expanding.

There were also the practical edges of building that I used to sit one layer removed from. App Store submissions. Review cycles. Rejections that don't feel conceptual — they feel procedural, but they slow everything down in a very real way. Small formatting issues that become blockers. Reuploads that reset momentum. Waiting on systems that don't care about urgency. And then trying again.

There's a specific kind of fatigue that comes from building something that exists at the intersection of your own standards and someone else's review process. It's not failure. It's friction. But it still accumulates.

There were also moments where I questioned the way I was building. Not in a dramatic way. More like a steady background awareness that I was relying on whatever tools or approaches helped me move forward fastest — including AI assistance for parts of implementation.

Not because I didn't know what I wanted. But because knowing and producing are not the same thing.

I didn't treat that as a philosophical question. I treated it as infrastructure.

What matters is whether the decisions stay mine. Whether the product reflects my thinking. Whether the direction remains coherent. Tools don't remove authorship unless you let them. They just change the speed of execution.

The perfectionism was always there. But it behaves differently when there is no external deadline forcing closure.

In corporate environments, shipping is negotiated. There is always a point where "good enough" is defined by consensus, not instinct. When you're building something yourself, that boundary disappears. You have to decide it.

And that creates a different problem. Not "is this good enough for release?" But "when do I stop refining something I can always improve?"

Eventually, I had to treat launch less like completion and more like exposure. A point where the system stops being theoretical and becomes real enough to respond to. Real enough to fail. Real enough to teach something back. Real enough to stop being shaped only by me.

Getting to launch wasn't a single decision. It was a gradual reduction of options. A narrowing of what I was willing to keep changing. A choice to stop optimizing for an imagined final version and start observing what happens when it meets actual use.

And even now, it doesn't feel finished.

It feels like the first moment where the product stops being only mine.