Five Years at Bunch: What I Built, What I Broke, and What I'd Do Differently
In 2020, Bunch hit #2 in the App Store for a week. Five million users. Twenty-eight million dollars raised from the best gaming investors in the space. For a brief window, we looked like the next big thing.
We weren’t. We’d caught a wave.
I let myself believe that catching a wave and having product-market fit were the same thing. That belief — held a little too conveniently — is the thread that runs through every technical decision, every leadership mistake, every moment I want back. This is my attempt to untangle it.
What Bunch Was
Bunch was a social gaming platform for mobile — think Discord meets FaceTime, but built for the games already on your phone. Mobile gaming was inherently solitary, even when you were playing against your friends. We wanted to change that: open Bunch, start a video call, and play any game already on your phone — together, without any complicated setup.
The idea sounds obvious now. It wasn’t in 2017. “Social layer for mobile gaming” wasn’t a category yet. We were building before the space had a name.
We started in a startup studio called 500labs. Before Bunch, we built a calendar assistant — it surfaced intel on whoever you were meeting that day, auto-generated invites, read your schedule intelligently. Smart product. Wrong problem.
Here’s the frame I’ve come to use: there are A+ problems and B+ problems. A+ problems are the undefined, messy, unproven things that are hard to even name — the question of whether a product should exist at all, and for whom, and why. B+ problems are the well-scoped execution tasks that feel productive but don’t answer that question. After a year on the calendar app, we had solved a solid B+ problem — the app did what it was supposed to do — and never addressed the A+ problem. Nobody was pulling for it. We moved on.
The video chat idea came fast. We built a prototype, played with it ourselves, and felt something. The product worked not because it technically functioned, but because it changed what was possible in a moment. That’s how we got conviction. That’s how me, Selcuk, and Jordan officially became co-founders of Bunch.
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.
The Rise
We caught a wave
The product had been building for two years. Not ripping — working. We had users, we had signal, we had a team energized and grinding. In 2019 I’d moved from Toronto to New York to work in person with Selcuk; the iteration loop got tighter.
Then COVID hit and the market came to us overnight.
Numbers spiked in a way that felt almost unfair. People were locked in, looking for ways to be with friends remotely, and suddenly “video call while playing mobile games” went from a cool product to an obvious one. Servers crashed. The app crashed. Users came back anyway. That kind of behavior — people pushing through failure to use your product — is one of the best signals you can get.
We stepped on the gas. Infrastructure migrations. App rewrites. Stability work. We caught the wave.
Looking back, the failure wasn’t in what we could see — it’s in what we chose to believe. The wave felt like validation of the product. The retention numbers said otherwise. We told ourselves they were the same thing.
There’s a difference between ambient growth and earned growth. Ambient growth comes to you because of circumstance — a cultural moment, a pandemic, a platform shift. Earned growth comes because users have made your product part of how they live. When the circumstance changes, ambient growth leaves. Earned growth compounds. We had both for a window, and we chose not to ask which was which. The data was there every sprint. What we couldn’t do was say out loud what it meant. When the wave receded and people went back to seeing friends in person, we found out what we had: we were too busy making people busy in the app. We hadn’t built the thing that made them come back when they didn’t have to.
The Fall
The analytics were never missing. The numbers were right there, and they told us retention wasn’t holding — that the engagement spike wasn’t sticking after the COVID wave. We knew.
The problem was what we measured. Every sprint, we’d ship a feature and track whether that feature improved. We never organized the whole effort around a single north star — the number that would tell us whether people had a genuine reason to come back. Without that organizing principle, engineering effort drifted toward polish. Toward things we knew how to optimize. We were too busy making people busy. Solving B+ problems: well-defined, satisfying to ship, and completely beside the point.
What we should have said, out loud: we don’t have product-market fit. We’re searching for it. That’s a valid place to be. But leadership kept promising too much — to investors, to the team — and once you’ve promised, you can’t easily question the premise you just sold.
The deeper structural error was scaling the engineering team before PMF was confirmed. We had capital, so we hired. We hired, so we needed to give people work. Work meant features. Features meant B+ problems. By the time the wave receded and the honest question surfaced — why do people actually come back? — we had a large team, a hard-to-iterate codebase, and enormous organizational gravity pulling toward the existing vision. That’s the paradox of early capital: the funding that’s supposed to accelerate your search for PMF can actually narrow the search if you’re not deliberate about staying in motion.
Then came the metaverse direction — built to demonstrate the scale of the bet for our Series A extension. The fundraising rationale was real: we needed that capital to survive. But the execution was the mistake. We merged the bet directly into the main product instead of keeping it separate — which slowed learning in both directions. The existing product got muddier. The new bet never got a clean test. When a company needs a compelling story to keep going, that’s a legitimate move. When that story starts reshaping the product itself, you’re no longer searching. You’re performing.
What I wanted was to bring the whole engineering organization back into search mode. Small team. Clean questions. No assumption that what we’d built was the right shape for what we needed to find. I knew that wasn’t going to happen.
My vision for what the company needed had diverged from where it was heading — on the product, and on how to operate. At the founder level, we’d arrived at fundamentally different ideas about how to run a company. I pushed, up to a line I’d drawn for myself.
Disagree and commit is a healthy culture, but it requires that you can commit. I couldn’t, in honesty, commit to where things were heading. So I stepped out — with gratitude for what we’d built, for Selcuk and Jordan and the team, and for the chance to have been part of it. Staying without committing would have cost the company more than leaving. We’re here for a short window, and I didn’t want to spend mine — or anyone else’s — performing alignment I didn’t feel. I was fortunate to have the option to leave; many don’t. Bunch had a hard landing after I left. I’m not in a position to judge what happened, and won’t try.
What I Learned as a Developer
The one-way door
The most consequential technical decision I made at Bunch was integrating Unity for the in-app game experience. At the time it made sense — we wanted native-quality gaming, React Native wasn’t going to get us there, and Unity was the obvious choice.
What I failed to fully evaluate was what that decision implied about how we’d update and iterate. App lifecycle — how users upgrade, how you push fixes, how fast you can ship a new version — is core to a mobile product’s ability to learn. Unity made that hard. We’d opened a one-way door without fully understanding where it led.
The cost showed up in three places at once. Shipping any change went from light to heavy — what used to feel like routine app iteration became a procedure. Version fragmentation broke the core experience: users on different app versions couldn’t share a session, so two friends trying to play together would hit friction at the exact moment the product was supposed to deliver. And the iteration energy of the team drained. When every change feels heavy, momentum stops compounding, and you stop running the small, fast experiments that were our actual edge.
When you can’t update your app quickly, you can’t learn quickly. Learning speed was our only real structural advantage over better-funded, better-staffed competitors. We built an architecture that competed with our own advantage.
If we’d had solid product-market fit, the Unity friction might have been worth it — triple-A game studios ask users to update all the time. But we were still figuring out what the product was. Were we a game or a communication tool? The Unity decision assumed an answer we hadn’t earned yet.
The principle underneath it: evaluate technical decisions not just on first-order capability, but on what they imply about your ability to iterate. Pre-PMF, a one-way door that slows learning is especially dangerous — iteration speed is your only path to truth.
I also didn’t construct the right decision-making process. I moved fast, and I didn’t bring the right voices into the room before committing. The question that most needed asking — “what happens when we need to ship an urgent fix?” — wasn’t on the table, because the people whose work would be shaped by the answer weren’t either. Dissent is most useful precisely when a decision feels obvious. That’s when you’re most likely to miss something critical.
Fix the product or fix the debt — not both
Here’s the reframe I wish I’d had earlier: technical debt priority is contingent on your PMF stage.
Pre-PMF, technical debt is not your most important problem. You’re searching for the right product. Spending engineering cycles on reliability, clean architecture, code quality — these are B+ problems. You’re optimizing code for a product that might be fundamentally wrong. Fix the product first.
The moment you have PMF, that inverts entirely. Tech debt is now your number one priority — because it’s what stands between your users and the experience they’re demanding. They’re there. They want it. Your debt is the wall.
Bunch never cleared the pre-PMF hurdle. The COVID wave felt like it — users pushing through crashes to come back, growth that looked like validation. So we shifted into debt-fixing mode. The session crashes, the audio drops, the reliability on long hangouts. We read the wave as PMF and acted accordingly.
It wasn’t PMF. It was ambient growth. The real mistake wasn’t fixing debt at the wrong moment in the cycle — it was letting the wave convince us we’d earned the right to switch modes at all. We were still searching. We just stopped acting like it.
The rule: when you don’t have PMF, fix your product. When you do, fix your tech debt. The hard part is that ambient growth mimics the PMF signal closely enough to fool you — and once you’ve switched into debt-fixing mode, you’ve already stopped searching.
Measure the north star, not the feature
We measured whether new features improved. That’s the wrong question.
The right question is whether the product as a whole is moving toward something users can’t imagine not having. Without a north star metric — one number that everything needs to contribute to — engineering effort finds its own gravity. It goes toward what’s measurable, what’s optimizable, what makes a sprint feel productive. That’s almost always a B+ problem. The A+ problem — why people actually come back — stays unanswered while the app gets more polished.
Define the north star before you scale. If you can’t define it, that’s data. It means you’re still searching, and your job is to search faster, not to optimize toward the wrong number.
Commit to the core
Before you can protect the core experience, you have to decide what it is — and commit to it explicitly. Not a vague understanding across the team. A thesis: this is the thing we’re building toward, this is why people will come back, this is the PMF assumption we’re running on.
For Bunch, that bet was the together feeling — the sense that you were actually there with your friends while you played. We never stated it that clearly. It was understood, not committed to.
Once you’ve made the bet, one thing follows: the core experience cannot break down. Not because reliability is always the top priority — but because a broken core experience isn’t a technical problem. It’s the thesis failing. Every dropped session at Bunch wasn’t just a bug. It was the product making the case against itself.
We knew. We kept shipping features around it anyway. When we finally fixed it, it cost significant engineering time and money we didn’t have to spare — at the worst possible time.
The team has to know what the bet is too. If they don’t understand what the core experience is and why it matters, they’ll treat a broken session as a ticket, not as a signal. Alignment on what the core means — and what it means when it breaks — is as important as fixing it.
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, raised our bar, and kept the lights on during the hard moments — they were everything. The times we hired badly, out of urgency or optimism, cost us in ways that weren’t immediately obvious.
The most common failure mode wasn’t a skills mismatch. It was the optimism hire: bringing in someone sized for a company we hadn’t become yet, for a product we hadn’t found. Before PMF, you don’t actually know what your product is — which means you don’t know what kind of person you need. Every optimism hire is a bet on a future that hasn’t been earned. When the future doesn’t arrive on schedule, the mismatch becomes expensive in ways that are hard to unwind.
My years teaching iOS development at Lighthouse Labs shaped how I thought about onboarding. The question I’d ask before every class — what’s the one thing I want them to be able to do by the end of this? — turned out to be a good frame for ramping up a new hire. Context doesn’t transfer by osmosis. You have to design for it.
I also had to let people go — for performance, for cultural fit, for interpersonal conflicts that couldn’t be resolved. The intention on every hire is never adversarial. It’s: how much can we accomplish together without me having to direct every step? When that stops being true, you both already know.
Communication doesn’t scale automatically
When it was 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 confused “I’ve thought about this” with “the team has thought about this.”
The clearest example is the Unity decision. I held the full reasoning — the technical constraints, the tradeoffs, the bet we were making on the product’s identity. The team got the decision. The gap between those two things was never properly bridged. Engineers worked inside a choice whose logic they didn’t fully understand, which made it harder for them to question it, adapt around it, or surface the problems it was creating. That’s not communication failure at the margins. That’s holding context that should have been shared before we committed — and then wondering why the dissent didn’t surface sooner.
The transition from IC to engineering leader requires building real communication infrastructure — RFCs, architecture reviews, postmortems, 1:1s that actually go somewhere. The overhead is real. The alternative is a team misaligned in ways you won’t discover until they matter most.
Optimism is a leadership tool, not a substitute for honesty
Founders are supposed to be optimistic. But there’s a version of optimism that shades into wishful thinking, and I crossed that line more than once.
The specific thing I was too slow to acknowledge: the retention numbers weren’t holding. I saw it every sprint. The engagement spike from COVID wasn’t sticking, and the honest read was plain in the data. But I kept telling myself the next feature would move the needle. The problem wasn’t that I didn’t know. The problem was that I couldn’t bring myself to say it out loud — which meant the team couldn’t orient around the truth either. If leadership can’t say “the retention isn’t there,” the team can’t respond to it. They keep shipping features. The A+ problem stays unanswered.
Being honest about your stage — saying “we don’t have PMF yet, and we’re searching for it” — is not weakness. It’s a precondition for actually searching. If leadership can’t say it, the team performs confidence instead of finding truth.
The people on your team can usually see problems before you’re ready to. Create space for that signal to reach you.
The Part That Stays With Me
Five years is a long time. Bunch was the first thing I built that other people used at scale. It was where I made most of my biggest mistakes, and where I learned most of what I know about building software and teams.
But more than the lessons, I’m grateful for the people. The engineers who showed up when the servers were crashing and users kept coming back anyway. The ones who pushed back on bad decisions, and the ones who helped me see what I was missing. The ones we had to let go, and the ones who chose to leave. Everyone who brought their full self to something genuinely hard and genuinely uncertain — through the momentum and the hard landings, the late nights and the pivots that didn’t work. I’m grateful for every one of them. The lessons belong to all of us.
I wrote this for whoever is building something right now, in that chaotic early stage where everything is simultaneously possible and precarious — and for myself, for the next time I’m in it. The truth has a way of surfacing at inconvenient times, in the data you didn’t want to read, in the conversations you’ve been avoiding. The work is to stay honest with yourself when it does.