We Launched. Just Not Where We Should Have.

We built Dodeez and launched it on the App Store in under a month. Ideation, design, development, submission. Four people. One month. Done.

I'm proud of that. I'd do it again.

But there's something I got wrong, and it took pulling the app off the App Store to see it clearly.

The Deadline Was Right

I gave the team 8 days for the final push to launch. Not a month. Not three weeks. Eight days.

My co-founder and the team pushed back. Not on the target, but on the timeline. They asked for more time, maybe a month extension. I said no.

People procrastinate with space. Give a university student three months to submit an assignment and they'll start in week eleven. Give someone 8 days and they move. That's not a theory. That's what I've watched happen, repeatedly, in every project I've run.

And the deadline works for another reason that has nothing to do with motivation. We weren't just four people building an app. We were an interdependent system. The developer's output was the designer's input. The launch date was the marketing team's starting gun. The timeline shaped the budget, the manpower allocation, the focus of every person involved. If one piece slips, everything cascades. The deadline wasn't pressure for pressure's sake. It was the skeleton that held the whole thing together.

So the 8 days: I'd do that again too.

Where I Pointed It

Here's what I got wrong.

I conflated launching with launching publicly. In my mind, "done" meant App Store. Live. Searchable. Real. I was so locked into that image of the finish line that I never questioned whether the App Store was actually the right venue for a version one with bugs, unclickable icons, and edges that hadn't been smoothed yet.

TestFlight exists exactly for this. It's Apple's official beta platform. You submit a build, invite testers, they experience the product, you iterate. Controlled. Contained. Real users, real feedback, without the permanence of a public listing that anyone can find and review.

We should have launched on TestFlight first. That's the mistake. Not the speed. The aim.

What Nobody Said

Here's the part that's harder to write.

My senior developer has five years of experience. He knows TestFlight. He'd used it before. The option wasn't invisible to him.

He didn't bring it up. Instead, he and the team asked for more time, a softer ask, one that didn't challenge the direction, only the pace. And when I said no, they executed.

I've been sitting with why. And I think I know.

During those 8 days, I was clear and I was dominant. The goal was stated once and it wasn't open for discussion. That kind of certainty moves things. It also closes rooms.

My senior developer probably had a moment where something in him flagged the venue. And then he looked at the energy in the room and let it pass. He didn't say it to me. He said something else, later, to my co-founder: that it's hard to find someone willing to work with someone this demanding, and still stay. He meant it as a kind of loyalty. I heard it as something else too. A signal that the things he couldn't say to me, he was routing around me instead.

One developer on the original team left. The pressure was too much. I don't blame him. But I also can't pretend I had nothing to do with it.

The Permission Gap

My co-founder is my brother. He pushes back on me regularly, and I listen. We disagree, we evaluate, we adjust. That dynamic works.

It works because there's a clear boundary. Technical decisions are his domain. When he tells me something won't work, or there's a better approach, I take it seriously because I've explicitly given him that authority. His judgment is final in his lane.

My team doesn't have that. They're in my domain, and in my domain I'm the one who moves fast and sets direction. There's no equivalent boundary protecting their judgment from mine. So when my senior developer knew something, he had nowhere to put it that felt safe.

The fix I used to think was obvious: run better brainstorming sessions. Give people a chance to raise concerns before we lock in. That's not wrong. But it's not enough either.

Because if I walk into that brainstorm already decided, people will feel it. They'll raise concerns softly. And the senior developer will stay quiet again.

The real fix is giving people a domain where their call is final. Not just a seat at the table, but a table of their own. "How we release and test this product" could have been his decision. It wasn't. Everything outside the technical build was mine. So he followed.

What I'm Taking Forward

Speed is not the problem. Urgency without clear ownership is.

The next launch, I'm not slowing down. But I'm being deliberate about who owns what decision before we start moving. Not who I'll consult. Who decides.

And TestFlight before App Store. Always, for version one. The public listing is not the finish line. It's the beginning of something harder to walk back.

We're on TestFlight now. The work continues.

---

Related: You're Heard. I Think. — the first time I sat with the cost of moving fast without checking if the room came with me. This post is the same lesson learning to actually change something.