Think twice, ship once, swing often

Week #18 in Bangkok. I'm deep into infrastructure work, refining my AI development process and facing the uncomfortable truth about indie hacking success rates. And I went to play golf with the British crew this week!

How I work with AI: the research-first method

I've been heads-down on infrastructure work for the past two weeks. Cooking the backend systems that will power my tool's next features by retrieving data from the web.

And working on a scraping infrastructure is hard. Every decision matters. One wrong move in configuration and your server gets banned. One bad architecture choice and you're rebuilding everything from scratch.

I realized something: AI doesn't automatically give you the best solution. It gives you the most logical solution.

There's a huge difference.

The problem with trusting AI blindly

When you ask Claude Opus or any AI to solve a complex problem, it will confidently implement a solution. Not necessarily the best solution.

Why? Because AI models are trained on patterns. They recognize what typically works and suggest that. But "typical" doesn't mean "optimal" for your specific use case.

I learned this the hard way while cooking scraping infrastructure. I'd ask Claude to implement something, it would write clean code that looked perfect, and then... it would fail in production. Or work but be incredibly inefficient. Or miss edge cases I didn't even know existed.

The methodology that actually works

After burning through dozens of failed attempts, I developed a process that consistently gives better results:

Step 1: Research phase I don't let Claude code anything yet. Instead, I ask it to research different approaches: "Search the web for techniques to solve X problem. Find blog posts, Stack Overflow threads, GitHub repos, documentation."

Claude goes hunting. It comes back with 5-10 different techniques people have used to solve similar problems.

Step 2: Brainstorm and filter Now we discuss what it found: "Is this approach relevant? Does it fit our constraints? What are the tradeoffs?"

We brainstorm together. Claude explains the pros and cons of each technique. I add context it doesn't have: my specific infrastructure, my cost constraints, my scale requirements.

Step 3: Create a test list We make a list of what needs testing. Techniques that seem promising go into the todo list. Stuff that's clearly irrelevant gets discarded immediately.

This is crucial. You're not committing to build everything. You're just identifying what's worth testing.

Step 4: Test one by one Claude codes each test as a standalone experiment. I run it. We evaluate the results. We brainstorm again based on what worked or failed.

This is slow. But it's way faster than building the wrong thing and having to rebuild.

Step 5: Iterate or restart If we found a solution through testing: great, move to the next challenge.

If nothing worked: back to Step 1. Research again with different keywords. Find new techniques. Test new approaches.

Why this works

This methodology forces AI to think like a researcher first, not a coder.

Instead of jumping to implementation, it explores the solution space. It learns what's actually out there, not just what it thinks should work based on training data.

And it prevents me from wasting time building confidently wrong solutions.

Since I adopted this approach, my success rate on complex problems went way up. I'm solving challenges I couldn't crack before. And I'm doing it without burning servers or wasting days on dead ends.

If you're using AI for serious development work, try this. It's slower upfront. But it saves you days on the backend.

The uncomfortable truth about indie hacking

Let's talk about statistics.

I spend more and more time in indie hacker communities. I follow successful makers on X. I read success stories. And I now befriend with people hitting $10k MRR, selling their projects for six figures, living the dream.

It's inspiring. It's also survivorship bias at its finest.

Here's what the data from the internet actually shows:

90% of indie hackers fail. Not "struggle". Not "take longer than expected". Fail. As in, never reach sustainable income…

Out of 50 projects, only 16 generated revenue. That's a real stat from indie hackers who track their journey over years. A 31% hit rate if you're lucky.

Only 18% of first-time founders succeed. Event if you're a serial entrepreneur with previous wins (which is my case), your odds jump to only 30%. Still not great…

Most first products fail. Even legendary makers like Pieter Levels launched dozens of projects before finding hits. Nomad List and RemoteOK weren't his first rodeo. They were the ones that finally worked after many failures.

It takes 2-5 years to reach ramen profitability. Not 2-5 months. Years. The "I built a SaaS in 3 months and hit $5k MRR" stories are exceptions, not the rule. Or maybe they're fake!

Why I'm sharing this

Because I need to be realistic about what I'm facing.

I'm not shipping things as side projects. I’m full-time focus. I've given myself 4 years in Bangkok to make this work. I'm burning through savings. I'm betting everything on this path.

And statistically? I probably won't make it.

That's the truth. The odds are against me. Against all of us in this space.

But here's the thing: I'm okay with that.

I'd rather try and fail than never try at all. I'd rather spend 4 years cooking, learning, and pushing myself than stay in a safe job wondering "what if?"

The stats are brutal. The mountain is steep. The failure rate is real.

But I'm climbing anyway 💪

Friday night golf in Bangkok

After so much intense work, I needed to disconnect.

My British friends (James, Danielle, Hugh, and Morgan, plus Raz and his Thai wife), suggested we hit up Topgolf Megacity.

I'd heard about it but never been. It's located next to Mega Bangna, a massive shopping mall in the suburbs. The place is huge: 102 climate-controlled hitting bays spread across 4 floors.

The experience

We arrived around 7pm and got assigned a bay on the third floor. Each bay has comfortable seating for up to 8 people, HDTVs, and you can order food and drinks that get delivered directly to your spot.

The concept is simple but genius: you hit microchipped golf balls at targets on a massive range. The system tracks your shots in real-time and displays your accuracy and distance on screens.

But it's not just practice. They've gamified everything. We played Angry Birds Golf (yes, really!), where you hit balls to knock down structures.

The best part? You don't need to be good at golf. I'm terrible. Didn't matter. Everyone had fun!

We ordered food, grabbed beers, talked about projects and life in Bangkok. The vibe was perfect, competitive but casual, active but relaxed.

Why it's great

Topgolf fills a gap I didn't know existed in Bangkok. It's an activity where you can:

• Actually do something physical (not just sit in a bar)
• Talk and socialize (unlike a movie)
• Be competitive without taking it seriously
• Stay comfortable (climate-controlled, unlike outdoor golf)
• Eat and drink while playing

The facility is spotless. Staff are friendly. The technology works flawlessly. And the rooftop bar (The Pink Giraffe) has incredible views of the Bangkok skyline.

We stayed for 2 hours, played multiple games and left feeling energized instead of exhausted.

It was exactly what I needed after days of grinding on code. Sometimes you just need to hit things with sticks and hang out with great people 🏌️

*This was week #18 in Bangkok. My AI methodology is dialed in. The statistics are brutal but I'm climbing anyway. And Topgolf? Highly recommended *🔥