What Six Months of Building a Startup Taught Me

Even rock-paper-scissors is a sport

The word ‘sports’ usually sits next to professional leagues, broadcasts, and salaries. Our definition was different: if there's competition and an audience, it's a sport. Even rock-paper-scissors.

Professionals have leagues, records, and fans. Someone playing badminton in the neighborhood has none of that. When the match ends, it disappears into ‘I got some exercise.’ We wanted to build an app where everyday players could keep records, and those records could connect people.

Oddly, it started at a university competition unrelated to startups. I met another student who worked on product planning, and one coffee chat was enough. I was drawn to the person before the idea. It had been a while since I'd met someone who genuinely wanted to tackle a problem.

We incorporated first. Investment needed a legal entity, and running tournaments meant signing contracts as a company rather than individuals. A company name helped with promotion too. In other words, this never started as a casual side project.

Keeping it alive comes first

I handled development: infrastructure, backend, and frontend. I chose the stack I could move fastest with. It wasn't the ideal combination, but what we needed then was speed, not a perfect stack.

The catch was that the app was both a social network and a tournament operations system. When a typical app goes down, users refresh. When ours went down, people in a gym couldn't play their matches. That was the kind of incident we faced.

After that day, I looked at code differently. I'd believed that good code and clean design were what made you capable. But a perfect design means nothing if the service isn't alive. I started putting redundant fallbacks around every feature. My design philosophy shifted from ‘elegant’ to ‘keeps running.’

What logs don't tell you

Shipping the app to the store and making tournaments happen was the most intense part of those six months.

I remember the first time I watched participants open my app and enter scores at a tournament. It felt strange. Until then, a service had meant logs in a terminal. Now people were tapping a screen in front of me, and their actions were reflected in real time. That was the first day I felt like someone operating a service, not just building one.

I also saw uncomfortable moments. Someone hesitating on a screen. Someone looking around for a button they couldn't find. None of those problems appeared in the logs. On the tournament floor, I learned that a product's real problems don't always show up in telemetry. After that, I shifted priorities from adding features to improving the ones we already had.

People are harder than AI

Around this time, a few teammates joined.

I was used to producing fairly large results on my own with AI agents. Give AI the right context and it produces something. People were different. Defining what to ask them to do was work in itself, and code reviews took more energy than I expected. Working alone, the code was an extension of what was in my head. Working together meant putting that whole picture into words. Honestly, there were moments when building it myself with Claude felt faster than explaining it.

Was that wasted effort? No. I couldn't have gone that far alone. Shipping, hosting tournaments, and operating them within six months happened because of the people who worked alongside me. Tools gave us speed; people gave us scale. I learned that firsthand.

The harder we worked, the further we drifted

Everything above was a small blow compared with the real problem.

Outside the users we brought in through tournaments and marketing, almost nobody opened the app again on their own. Organic retention was terrible. Our first diagnosis was that the app wasn't entertaining enough, so we added a feed where people could browse others' matches like Reels. My co-founder and I even disagreed about whether to prioritize the feed or sales. I chose the feed because I thought people needed a reason to open the app more often. My point is that we didn't fail for lack of effort.

Looking back, the diagnosis itself was wrong. This business needed an existing community. People attract more people, and no amount of features creates the first group. It wasn't simply that the app was bad. The problem wasn't one we could solve at our stage.

Some startups fail from weak execution. But when the diagnosis is wrong, working harder takes you further from the answer. That was us. Six months of execution piled up without addressing the real issue.

The final blow came from outside. Around the same time, Karrot launched a local groups feature. They already had the community we were trying to build from scratch. Honestly, seeing that took a lot of the wind out of us.

When conviction ran out, the company stopped

The decision to stop was mine.

The service was still running, which made it stranger. We hadn't collapsed; we chose to stop while still standing. It's hard to explain what it feels like to incorporate a company, build an app, run tournaments, and then switch it off yourself. One thing was clear, though: continuing without knowing where we were headed was scarier than failing.

If I had to name one thing those six months left me, it would be an understanding of the world outside the logs. I learned painfully that perfect designs and intense execution can still be powerless against how users live and when a market is ready.

But the experience wasn't lost. It left me better able to look past a builder's assumptions and see what users actually lacked, and better able to keep a service running under pressure.

Our diagnosis was wrong; my desire to solve problems wasn't gone. I'm taking what I learned into the next problem, with a sharper eye.