Brad Murray on Building Things That Last: From Pebble to Beeper
Fourth Founder Dinner for W26: First engineer at Pebble. Co-founder of Beeper. A deeply technical builder who never left Waterloo.
TL;DR: Brad Murray joined us for Week 4 of the W26 Founder Dinner Series. His career arc, from Pebble’s fourth employee building a smartwatch OS from scratch, to co-founding Beeper and navigating a high-profile fight with Apple, to landing at Automattic as Head of Engineering for Beeper, is a masterclass in staying technical, staying curious, and staying local. The evening’s conversation touched on what it’s really like to build hardware before there was a playbook, how to manage remote teams without losing alignment, why async communication requires intentional design, and what it means to raise money and build a company in a market that changed dramatically between your first and second rounds.
Week 4 brought a different kind of energy to the table. Where earlier dinners featured founders and investors who could point to clear product-market fit and venture-scale outcomes, Brad Murray offered something just as valuable: an honest, unfiltered view of what it’s like to be the person actually building the thing. The one writing the OS, debugging the hardware, keeping the ship running.
Brad is Head of Engineering at Beeper, now part of Automattic, the company behind WordPress. He co-founded Beeper with Eric Migicovsky, and before that was employee number four at Pebble, arguably the company that put the smartwatch category on the map before Apple showed up and redefined it overnight.
He never left Waterloo. That fact alone says something.
The Pebble Story: Building the First Smartwatch
Most founders in the room knew the name Pebble. Fewer knew what it actually took to build it.
Brad joined as one of the first engineers in 2012, shortly after the Kickstarter campaign that raised $10 million, at the time the largest crowdfunding campaign ever run. The product was a watch that paired with your phone, showed notifications, and ran apps. That sounds obvious now. In 2012, it wasn’t.
“I would call it the first smartwatch, basically,” Brad said. “There were weird Casio things before it, but Pebble was the first popular one.”
The team had to build everything from scratch: the OS, the SDK, the developer ecosystem, all of it. They sold over a million devices. They ran three Kickstarter campaigns, the largest of which raised $20 million. They were, by any measure, doing something that mattered.
Then the Apple Watch arrived in 2015. Things got hard fast.
Pebble sold in 2016. The outcome was mixed: a real company, real users, real technology, but ultimately unable to compete with a hardware giant that had decided the market was worth owning. What’s interesting is what came out of it. The underlying frustration that drove Pebble’s co-founder Eric Migicovsky (why can’t developers get API access to text messages? why are platforms locking this down?) never went away. It eventually became the seed of Beeper.
Beeper: Taking on Apple (Again)
Beeper started with a simple premise: messaging is personal, and it should work across every platform. iMessage, WhatsApp, Signal, Telegram, SMS, one app, all of them. The technical challenges were enormous, and the business model challenges were arguably bigger.
Brad and Eric started the company remotely during 2021, a moment when raising money felt very different than it does now. “We were able to start a company during the good old days of 2021 where raising money was actually decent,” Brad noted. They raised a single significant round, a “monster” by his description, coming out of Y Combinator, and rode that runway for two to three years.
By 2023, the fundraising market had changed entirely. The metrics investors wanted had shifted. The story that worked in 2021 (DAUs matter, monetization comes later) didn’t land the same way. “Cash flow became king,” Brad said simply.
What followed was a high-profile battle with Apple over iMessage access that played out very publicly. The tension between building a product that depends on platform APIs and the platform’s willingness to honor that access is a structural problem for many founders. Beeper experienced the most visible version of it.
Automattic ultimately acquired Beeper. It turned out okay. But the journey from initial raise to acquisition was a clear illustration of how dramatically the funding environment can shift mid-company, and why founders who aren’t thinking about what it takes to stay alive can find themselves in serious trouble.
Workshop: Default Dead or Alive?
The evening was paired with a workshop focused on Paul Graham’s “Default Dead or Alive?” framework, and the timing felt right. Brad’s Beeper story is, in part, a story about runway, about what it costs to stay alive, and about what happens when the external environment changes the rules of the game while you’re in it.
The core concept isn’t complicated: a company is either on a path to profitability before it runs out of money, or it isn’t. Default alive means your growth trajectory gets you to breakeven before the runway ends. Default dead means it doesn’t, and you need either a new plan or new capital.
The nuance is that most early-stage founders don’t spend enough time thinking about this clearly. The temptation is to focus on product, on traction, on metrics that feel like progress without asking the harder question: what does it actually cost to be alive, and how do I get there?
As the workshop framed it: running out of money is what kills 100% of companies. The game isn’t valuation; it’s staying alive long enough to get lucky. And getting lucky requires a realistic picture of the math.
Brad’s story illustrated the point in both directions. Beeper had significant runway from their initial raise, which gave them time to build and iterate. But when they went back to market in 2023 and investors had changed what they were optimizing for, the company had to reckon seriously with what it would take to survive in a tougher environment. That’s not a failure of execution. It’s the reality of building a company across multiple market cycles.
Remote Teams: The Alignment Problem
One of the most practical conversations of the evening was about remote work, fitting given that Brad has been building remote-first teams since 2012, when the tooling barely existed and the concept was still experimental.
His perspective wasn’t that remote is bad. It was more specific than that: remote and async are not the same thing, and conflating them creates problems.
When Pebble scaled quickly after the Kickstarter, Brad and a colleague set up what was effectively a remote outpost in Waterloo while the core team operated elsewhere. The tools were primitive: Skype, early video conferencing, whatever worked. They made it work.
With Beeper, the team was distributed across multiple time zones, including engineers in Finland. The practical reality was that 11 AM Eastern was 6 PM in Helsinki. Someone always loses when you’re spread that far. “You just have to be straight with people,” Brad said. “Here are the four hours we must be online. If those hours don’t work for you, this isn’t the right company for you.”
But the deeper insight was about what remote removes without anyone noticing: the constant, ambient nudging back into alignment that happens when people share a physical space. In an office, you absorb what’s working and what isn’t through a hundred small interactions. You overhear what’s getting traction. You sense when something’s off.
Remove that, and people drift. Not maliciously, just gradually, quietly, in small ways that compound. Brad described a period about nine months into Beeper when the team was around eight to ten people and something wasn’t clicking. “We kind of had this come-to-Jesus moment where we thought, did we hire idiots? What’s going on?” The people were smart. The problem was structural. Without constant realignment, teams working on hard, ambiguous problems naturally diverge.
His solution wasn’t to mandate more meetings. It was to get serious about written communication as a primary tool for building shared context.
The Case for Writing
If there was one piece of tactical advice that landed hardest, it was this: learn to write.
Not journaling. Not documentation for its own sake. The specific discipline of writing out your thinking, your proposal, your reasoning, your tradeoffs, and giving people time to engage with it before responding.
“I write a lot of RFP-type things,” Brad explained. “Here’s a change I’m thinking about making. Here’s why it’s a good idea. Here are the tradeoffs I considered.” He puts it in Notion, links it in Slack, and lets it collect comments for a day before the live discussion.
The contrast is with how most decisions get made in chat: someone asks a question, a few people react quickly, the context collapses immediately, and when you look at it later it’s nearly impossible to reconstruct what problem you were actually trying to solve.
Writing forces clarity. It gives people time to think rather than just react. It creates a record. And for distributed teams operating across time zones, it’s often the only way to have real conversations about important decisions, since not every conversation will happen live.
This is a skill, Brad noted, not a natural instinct. Most people are better at talking than writing. Building companies that default to writing requires deliberate effort, especially at the beginning when it feels slower than just getting on a call.
On Staying in Waterloo
Brad has been in the Waterloo ecosystem for his entire career: Pebble, Beeper, and now Automattic. He’s watched cohorts of founders move through, some to San Francisco, some staying local, most doing a version of both. He chose to stay.
There’s something worth noticing in that. The dinner format, small group, honest conversation, founders at different stages in the same room, is exactly the kind of community infrastructure that makes it possible to build in Waterloo rather than feeling like you have to leave to be taken seriously. Brad’s presence was a reminder that the builders who stay are part of what makes that possible for the next generation.
Key Takeaways
The evening crystallized several ideas worth carrying forward:
Running out of money is the only cause of death that’s 100% consistent. Everything else, bad product, bad market, bad timing, can be survived or pivoted through. No runway can’t. Founders who don’t develop a clear picture of what it costs to be alive are operating on borrowed time.
Remote work doesn’t solve the alignment problem; it relocates it. Distributed teams lose the ambient alignment that happens in shared spaces. The answer isn’t more meetings. It’s intentional written communication that creates shared context and gives people time to think.
Write more than you think you need to. The discipline of writing out your reasoning, proposals, decisions, tradeoffs, before discussing them live is a superpower for distributed teams and a forcing function for clearer thinking generally.
Fundraising markets change faster than product cycles. Beeper raised in 2021 and tried to raise again in 2023. Those were completely different conversations. Founders who build assuming the market will look the same in two years are making a bet they may not have intended to make.
Staying technical is a competitive advantage. Brad has been writing code across every company he’s worked on. That foundation, understanding how things actually work, doesn’t disappear when you scale into leadership. It informs every decision.
The W26 Founder Dinner Series is hosted by Builders Club in Waterloo. Sessions run every two weeks through the winter term, pairing evening founder dinners with midday workshops. Thanks to our sponsors Osler and TD Innovation Partners for their continued support.