Five Years at Bunch: What I Built, What I Broke, and What I'd Do Differently
I co-founded Bunch in [YEAR] with [CO-FOUNDERS]. Over the next five years, I would go from writing the first line of code to leading an engineering team, raising venture funding, and eventually watching something I’d poured everything into come to an end. This is my attempt to make sense of that journey.
What Bunch Was
Bunch was a social gaming platform for mobile — think Discord meets FaceTime, but built for the games already on your phone. The idea was simple: mobile gaming is inherently solitary, even when you’re playing against or alongside your friends. We wanted to make it feel like you were actually together.
You’d open Bunch, start a video chat with your friends, and play any mobile game you already had installed — all at the same time. No complicated setup. No new game to download. Just your friends, your games, and your face in a little bubble on the corner of the screen.
At our peak, [PEAK METRIC — e.g., “we had X million users and were the #1 social app in the App Store for a week”]. We raised [TOTAL RAISED] from [INVESTORS]. For a while, it felt like we were really onto something.
Then it fell apart.
The Rise
We caught a wave
[YEAR] was a good time to be building social + gaming. COVID hit and suddenly everyone was looking for ways to hang out with friends remotely. Our numbers spiked in a way that felt almost unfair — overnight, we went from a scrappy product that was working but not ripping, to something that felt like it might actually be the next big thing.
Looking back, I didn’t fully understand the difference between catching a wave and having product-market fit. We had both for a moment, but when the wave receded, we found out how much of our growth was ambient and how much was earned.
Building fast, maybe too fast
In the early days, I wore every engineering hat there was. I wrote the iOS app, the backend, managed the infrastructure, did code review on PRs I had authored myself. It was scrappy and chaotic and honestly some of the most fun I’ve had building software.
We iterated quickly. If something wasn’t working, we’d rip it out by Friday. If users were doing something we didn’t expect, we’d lean into it by the following week. The feedback loop between what we shipped and what we learned was tight, and that tightness was a superpower.
The mistakes we made were the classic startup mistakes: choosing the fast path over the right path, accruing technical debt we told ourselves we’d pay down “after the next milestone,” prioritizing features over foundations.
The Fall
I won’t get into all the details here — some of it is still [STILL PROCESSING/COMPLICATED/ETC.]. But the short version: [YOUR VERSION OF WHAT WENT WRONG — market shifts, competition, internal challenges, funding, product-market fit eroding, etc.].
What I can say is that watching something you built with your hands fail is a specific kind of hard. It’s not just the loss of the company — it’s the loss of the future you’d imagined for it. Every product decision, every architectural choice, every hire becomes a question: did that contribute to this outcome?
What I Learned as a Developer
Technical debt compounds faster than you think
We made pragmatic shortcuts constantly. “We’ll clean this up later” is a lie you tell yourself when you’re moving fast. Later arrives, and now the shortcuts are load-bearing. The code you were embarrassed about in year one is the code that’s breaking in production in year three.
If I were doing it again, I’d be more ruthless about carving out time to maintain. Not refactor for its own sake — but maintain. Keep things legible. Keep the foundations sound. Future-you will be grateful.
Observability is not optional
We flew blind for longer than we should have. We’d ship something, it would break in a way we didn’t anticipate, and we’d scramble to figure out what happened. We didn’t have the instrumentation to understand our system’s behavior at scale until it was already causing problems.
Good logging, good metrics, good alerting — these feel like overhead when you’re small. They’re not. They’re the difference between reacting to fires and preventing them.
Your architecture is your hiring plan
The technical decisions you make in year one determine the shape of the team you need in year three. We made choices early that made certain kinds of scaling harder than they needed to be. [SPECIFIC EXAMPLE IF YOU WANT.] By the time we had the team to address it, we were mid-scaling and the cost of refactoring was high.
Think about what your architecture implies about what expertise you’ll need. Build for the team you’re going to have, not just the team you have now.
What I Learned as a Leader
Hiring is the job
Nothing I did as CTO mattered more than who I hired. The engineers who shaped our culture, who raised our bar, who kept the lights on during the hard moments — they were everything. And the times we hired badly, out of urgency or optimism, cost us dearly in ways that weren’t always obvious right away.
I wish I had spent more time on this. Not just sourcing and interviewing, but thinking carefully about what kind of people would thrive in our environment, what the team needed next, and what gaps we kept papering over.
Communication doesn’t scale automatically
When it was just three of us, information moved freely. Everyone knew everything. As we grew, that stopped being true, and I didn’t adapt fast enough. I held too much context in my head. I assumed people knew things they didn’t. I confused “I’ve thought about this” with “the team has thought about this.”
The transition from individual contributor to engineering leader requires building real communication infrastructure — not just Slack channels, but shared understanding. RFCs, architecture reviews, postmortems, 1:1s that actually go somewhere. The overhead feels real, but the alternative is a team that’s misaligned in ways you won’t discover until they matter.
Optimism is a leadership tool, not a substitute for honesty
Founders and CTOs are supposed to be optimistic. It’s part of the job. But there’s a version of optimism that shades into wishful thinking, and I crossed that line a few times. I was too slow to acknowledge when something wasn’t working. Too slow to have hard conversations about direction. Too quick to believe the next milestone would resolve the underlying tension.
The people on your team can often see problems before you want to see them. Create space for that signal to surface. Don’t shoot the messenger. Be honest with yourself first.
What I’d Do Differently
I’d build trust earlier. Not just with the team, but with myself. The moments I regret most are the ones where I let imposter syndrome or fear of conflict lead me to make the safe choice instead of the right one.
I’d instrument everything from day one. Metrics, logs, traces. The cost is low. The payoff is enormous.
I’d define technical principles early, then let the team diverge. Not rigid rules, but agreed-upon values: what do we optimize for? speed? simplicity? reliability? Those defaults shape a thousand small decisions. Without them, you get inconsistency.
I’d separate the product bets from the platform. We conflated them. The things that needed to be stable and maintainable got treated like bets. The bets needed more room to be experimental. Keeping those separate — in your architecture and in your team’s mental model — matters.
I’d be more comfortable saying “I don’t know.” To investors, to co-founders, to my team. The pretense of certainty is expensive.
The Part That Stays With Me
Five years is a long time. Bunch was the first thing I ever built that other people used at scale. It was the place where I made most of my biggest mistakes, and where I learned most of what I know about building software and teams.
I’m grateful for it, even for the hard parts. Especially for the hard parts.
If you’re building something right now — in that chaotic, uncertain early stage where everything feels simultaneously possible and precarious — I hope some of this is useful. Not as a warning, but as a reminder that the lessons are in the work, not just the outcome.
I’m currently at Mozi, where I get to keep building. If you want to talk shop — about startups, engineering leadership, or mobile apps — reach out.