Exiting to Apple - Dennis Pilarinos from Unblocked
The first version of Buddybuild's onboarding worked so well people assumed it was fake. Dennis Pilarinos had to build a streaming log viewer just so users would believe the green build was real. Buddybuild sold to Apple three years later; he's since built Unblocked on the same instinct for what should feel effortless.
Dennis Pilarinos is the founder of Unblocked, which lets developers ask broad questions about their codebase using source code plus Slack, Notion, and Linear. He previously founded Buddybuild, a mobile CI/CD tool acquired by Apple in 2018, after which he became a director in Apple's Development Technologies group.
We get into how a whole-team thumbs-up-thumbs-down vote decided the Apple acquisition, why he had to prove Buddybuild's builds weren't faked, the identity crisis that followed selling a company he'd poured three years of 60-70-hour weeks into, and the specific boundaries he's set this time around to avoid repeating that.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does Unblocked actually do?
The idea is to take your source code and complement it with all the code-adjacent systems you already use to have conversations about your application — Slack, Notion, Linear — so that combined with the source code, you can ask really high-level or very specific questions and get an answer to almost anything you might want to know about your codebase. We announced the company in October 2023, so we're a few months into being public, with a couple thousand developers using it, most of them almost daily.
How did Buddybuild actually start?
A couple of friends and I were trying to build an iOS app, and we were blown away by how hard the standard workflow was — git push, get a build, test it, give feedback. We gave up on the app itself and asked what if there was a hosted CI solution for mobile instead. I think it's a consequence of two things about me: I'm not a very patient person, and I'm a pretty mediocre developer — self-aware enough to know it — so whenever I try to do something, I always ask why does it have to be this hard. We optimized Buddybuild's developer experience so you didn't have to change anything about your project or workflow — you'd install an OAuth app, it would introspect your repository, and automatically create a build. People were skeptical it was even possible, but we built something people genuinely loved, with thousands of developers using it worldwide.
How did the Apple acquisition actually come about, and was it a hard decision?
We went from inception to acquisition in almost exactly three years. Apple was one of a handful of companies that noticed us and asked if we'd be interested in being acquired. It was absolutely a hard decision — there's this meme graphic of what people think success looks like, a clean line from point A to B, versus what it actually is, a bunch of squiggly lines: real misery followed by incredible moments of happiness. I'd worked at places like Microsoft and Amazon before, so I understood the pros and cons of a big company, and we thought seriously about that. During the acquisition process, we got the entire team in a room — after several of us had flown to meet the Apple folks in Vancouver — and did a literal thumbs-up, thumbs-down vote. I said if a single person, from the office manager to the CTO, put a thumbs down, we wouldn't do the deal. Everyone put their thumbs up. It wasn't a decision I made alone, or even one the founders made alone — it was team-wide.
What happened to Buddybuild after the acquisition?
Buddybuild lives on as Xcode Cloud, the integrated CI environment built into Xcode now — the vision certainly carried through — but Buddybuild.com itself was shut down, which is still sad for me at times.
Why do you think Apple specifically wanted to acquire you?
We had a lot of experience building secure, cloud-based applications at reasonably high scale, which the team we joined at Apple didn't have much of, and we knew a lot about how people build third-party iOS and Android apps. But I think what we obsessed over most — developer experience — is something we tried to influence at Apple too: treating developers as real people, not fungible assets who promote the ecosystem, where breaking an API actually matters. One of my favorite pieces of early feedback was someone writing in to say the product gave them back a meaningful chunk of time they now spent with their family. We got fan art from users. That's the bar we were trying to hit, and it's the same thing we're chasing again with Unblocked.
What do you think made that level of developer love possible?
Having worked at Microsoft and Amazon before Buddybuild helped me see what parts of a culture resonate and what the trade-offs are between working at a small company versus a big one. Amazon's hyper-focus on the customer stuck with me — their leadership principles weren't platitudes, people genuinely referenced them day to day. That bias for action and customer obsession is something we still care a lot about at Unblocked. For most of Buddybuild, and I still do this today, I personally handled the majority of technical support — up at 4:30 or 5am answering questions from people in Europe overnight, really understanding what worked and what didn't and what to prioritize. Users would be shocked they were talking to the CEO, but it didn't feel like it mattered who was answering — I just wanted to feel the pain myself to actually solve it for people.
Buddybuild's onboarding reportedly worked so well people didn't believe it. What happened there?
I didn't want to subject our users to changing anything about their project unless it accrued real value to them, so onboarding was just pointing Buddybuild at a repo — no config file, no describing your branches or dependencies. We got green builds in the high 90th percentile just from that. But the first version of that flow was so smooth people thought it was fake — they didn't believe there was actually a green build, because it felt too magical. So we had to build a streaming log service so people could watch the actual build output coming out in something close to real time, and download the binary afterward. If you build something that magical, developers are inherently skeptical, so you have to open the curtains a little and show them how it actually works.
Does that same philosophy carry over to how Unblocked handles messy, years-old codebases?
Almost every team we talk to describes their own codebase as an absolute spaghetti dumpster fire and feels embarrassed onboarding it — everyone thinks they're a uniquely bad snowflake, but plenty of people feel that way, including members of our own team about our own code. We don't want anyone to have to refactor their repo or reorganize their Notion docs to use Unblocked — you should just work the way you already work, and the product uses it as-is to provide a compelling experience. There should be zero work required on the user's end for something that should feel magical.
How do you actually go about deciding what to build next, to keep that magical feeling?
I learned a framework early in my career called BXT — business, experience, technology. First, is there a real business behind what you're building; if not, it's not long-term viable. Then the team — design, engineering, myself — really sits down and asks what would feel like a kickass, compelling experience, removing the constraints of the technology as it currently exists. A lot of teams start from 'here's the technology I have, how do I make it do something cool' — we try to start from 'what would be genuinely amazing,' and then go make the technology happen to deliver that.
Is there an upper limit on how long you'll work toward one of those ideal experiences before shipping something smaller?
There are usually stepping stones toward the full vision, and we try to make each one as meaningful as possible — if we ratchet the ambition back to something buildable right now, we ask whether that's still compelling on its own. If it's not, there's not much point releasing it, so we generally wait until we think it's genuinely good with no real issues before shipping.
How do you find your ideal customer for something as broadly applicable as 'ask questions about your codebase'?
You look at the extremes. A team of four who go into the office every day and have a codebase that's six months or a year old probably don't need much help — it's all paged into their heads already. Some of our customers have codebases that are ten, twelve, fifteen years old with thousands of repositories and thousands of people, where no single person could ever page in the entire history of every part of the code. So the ideal customer is somewhere in the Goldilocks zone between those extremes — a company like Apple, given its scale and how it organizes and shares information, isn't actually a great fit for this today, even though I worked there. There aren't many companies that large in the world, so you look for the sweet spot in between.
How do you actually go about finding those early customers?
It's a flywheel — I know that's a tired analogy, but it really is painfully hard to get moving at first. Early on it's a lot of begging and pleading friends to just try the thing and tell you what they think. Once you've built something people genuinely find valuable, they start telling their friends, and it starts to move on its own. I recently spoke to a CEO whose company is eight or nine years in, doing tens of millions in revenue, who said his favorite part of building a company is all the rejection and no's — which I think is an easy thing to say once you're making tens of millions. When you're getting constantly rejected in the moment, it feels quite different.
What are you doing differently this time around compared to Buddybuild?
I think of building a company the first time as walking into a dark room littered with furniture — you're going to smash your toe on things, and hopefully you just get bruises, not breaks. The second time, you at least know roughly where the furniture is, even though things still move, since the ecosystem isn't static. One specific thing I don't think people talk about enough: the first zero-to-three years wasn't 35-40 hour weeks, it was 60-70 hour weeks for three straight years, barely taking vacations. I went through a real depressed period after the acquisition, where I'd lost a big part of my identity and purpose because I'd been so completely merged with Buddybuild. A lot of the team building Unblocked are the original Buddybuild team, and I've explicitly asked them: I'm an obsessive person, don't let me get to a place where it affects my mental health. So I've set specific boundaries this time — not working Saturdays, going for walks, getting a dog, things that force actual separation.
Do you feel proud of what you built with Buddybuild, looking back?
Yes and no. It's a great accomplishment to say we built something people loved, memorialized by an acquisition from one of the best companies in the world — that's humbling. But when I think about the actual highlights, it wasn't the acquisition, it was the fan art, it was people saying thank you for giving me back time with my family. To the degree you can take a problem most people find uninteresting and build something people genuinely love, that might be the real accomplishment — and maybe that's part of why I'm doing this a second time.
What would you tell a founder currently going through their first developer tool experience?
One thing specific to developer tools: the way you personally work is not the way everyone works, so you need strong opinions about how something should work, held flexibly enough to accommodate other people — developers especially love telling you exactly how you should organize your project or manage dependencies. The other lesson is more broadly applicable to any company: make sure the people you work with are people you genuinely respect and admire, who are better than you in some way. I still think of myself as working for the team, even as CEO. If you build a product that people love, with genuinely great people, the rest — go-to-market, growth — really does take care of itself to a surprising degree.