I Agonized Over a Decision for Weeks. Here's What I Got Wrong

Let me tell you a real-life, right-now story that directly impacts what I’m doing at Scalebrate and fuels this newsletter article and a public reckoning with my own decision-making.

A few weeks ago, I made a very analyzed, very reasoned, very "I-burned-millions-of-tokens-and-too-many-cycles-on-this" decision to move our Scalebrate Hub community to Skool instead of the custom-build framework I built on the Scalebrate Hub. I went through a full WOOP / Planning cycle with Pro/con lists. Strategic fit models. AI-assisted analysis. I consulted the guides. I consulted my own brain. Multiple times.

Then I started building it.

Two weeks later, I blew the whole thing up and went back to the custom-built Hub.

Which is either a story about terrible decision-making or excellent decision-making. Depending on how charitable you're feeling. And I think it’s also a side-story about SaaS and where things are at with AI-assisted coding.

Here's how it started.

Our own Hub platform had gaps. Gamification wasn't where I wanted it, some UX friction existed, a few features still needed building, and of course the big one: discoverability. I had to do all the work to get the audience and build attention.

Skool, by contrast, had network effects, built-in discoverability, a growing ecosystem of communities, and deep functionality in gamification and course capability. Multiple analyses pointed toward Skool.

So I committed. Upgraded to Pro. Locked the community name. Built out the classrooms. Configured the tiers. Wrote onboarding flows. Started picturing a thriving community of leverage-first founders scaling with the Skool tailwind behind them.

"I've done the analysis," I told myself. "This is disciplined strategic thinking. This is what good founders do."

And then I actually started digging into Skool seriously with all my product roadmap plans and what I wanted to get done.

The cracks appeared fast.

No real API or webhook integration except a polling-based one-way Zapier webhook for subscriptions and a simple inbound webhook to send invites to emails. Which meant Skool would never properly talk to the Hub. Members would need two separate accounts, two separate login experiences, two separate purchases. I'd be maintaining two parallel content pipelines forever.

The Skool ecosystem … and I say this with only mild snark … has a vibe. And not the sort of vibe-coding vibe. It leans toward “get rich quick” and "hey bro, want to borrow my audience?" energy. There’s a weird mix of Meetup-style groups that are either fully free or monetized to different amounts. And lots of self-promoting influencers looking for an easy buck and customers desperate to build their own similar networks. Less "leverage-first founders building real businesses," more "growth-hack influencer content." Not exactly the neighborhood I want Scalebrate in.

Now I do appreciate what Alex Hormozi and his team are building with Skool, and there are indeed a bunch of folks doing well there. But the vibe is not a fit for the long-term community we’re building at Scalebrate that’s more about you than it is about me.

And then the biggest gut punch: discoverability on Skool is real, but it's also full of me-too copycats and a lot of the same people selling the same things. Which was simultaneously validating (yes, the market exists) and deflating (also, everyone's here already).

But the real kicker — the one that made me put down the keyboard and stare at Claude’s incessant “navel gazing” — was this realization:

The Hub's problems were fixable. Skool's problems were structural.

And more importantly: none of this was actually solving the real problem. The real problem was customers. Without customers, the platform was irrelevant. And I was burning my scarcest resource — focused attention — building on a platform I'd already found fault with.

"I thought I'd made the right call. I'd done the analysis. The analysis was right. And somehow I was still wrong."

Here's the concept I keep bumping into: analysis tells you about the top of the iceberg. It's what you can see: the features, the pros, the cons, the strategic fit score.

What it doesn't show you is operational reality. The underwater mass. The "week three of actually building this" experience.

Most founders who think in systems and frameworks, and I include myself firmly in this category, are excellent at the visible part. We love a good framework. We love structured analysis. We love when the data points somewhere.

But the iceberg test is different. It asks: When you're living this decision in the third week, does the analysis hold up?

The answer, in this case, was no. And it took actually building it to find that out.

Also, it’s so tempting and comforting to live in your own world of analysis and frameworks. But this is a form of analysis paralysis and dare I say it… procrastination. Nothing is a substitute for getting in front of the customers and having real-world conversations.

If you're running a small team, you don't have the money or time budget to run parallel experiments indefinitely. A 500-person company can maintain two community platforms while figuring out which one to consolidate. You cannot.

Here's what platform ambiguity actually costs:

The Leverage-First principle isn't just about doing more with less. It's about not generating negative leverage: the complexity, overhead, and parallel systems that slow everything down.

The moment I mapped out what it would actually take to run both platforms simultaneously, the decision made itself.

Was my diversion down the Skool path a bad decision? Is the current decision to stick with the home-grown solution a bad decision? Here's my honest answer: it was a correctable decision which is better than a stuck one.

Here's the framework I'm using now before committing to any major platform or tooling decision: