From mobile app to mobile developer tool with Gabriel Savit from Runway
Gabe Savit's co-founders had all worked together as the first iOS team at Rent the Runway, scattered to different companies, and kept comparing notes on a WhatsApp thread until one of them dropped in a note about release management. It resonated instantly — everyone remembered dreading their turn on the release rotation.
Gabriel Savit is the co-founder and CEO of Runway, a mobile release management and automation platform that connects across a team's whole toolchain — CI/CD, version control, project management, app stores, and stability monitoring.
We get into why Runway chose to launch broad but thin rather than narrowly scoped, how the founding team's shared history as former mobile engineers on the same team shaped the product's conviction, the very manual Slack Connect strategy that kept early customers close, and why release management is a genuinely hard category to explain and get discovered organically.
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 is Runway, and what problem is it actually solving?
Runway is a mobile release management and orchestration platform, and there are two underlying themes. One is automation — there are a lot of moving pieces in a mobile release cycle spread across many tools, and it's more than just your build pipeline. We connect to CI/CD, but also span version control, gate wrangling, project management tools, app stores, and stability monitoring, automating as much of that end-to-end as possible so product engineers aren't diverted into scripting the less fun parts. The other big theme is collaboration — mobile releases involve a lot of interdisciplinary, gated steps because you're shipping a binary, so we create a place where engineering, product, QA, engineering managers, and other stakeholders can all see the state of a release and chip in along the way.
What makes mobile release management specifically harder than, say, shipping a web app?
There's a lot to keep tabs on across any team of scale — many different feature teams contributing code that has to coalesce into one binary. There's a long tail of app versions you have to support once it's shipped, so you need a clear picture of what your actual user base is running. And there's the third-party ecosystem problem: dealing with Apple and Google review processes, where every new version submission needs human eyes on the other side and can get rejected — increasingly true on the Google side too, anecdotally. On top of that, there's a growing number of platforms and form factors to ship for, from watches to TVs to phones.
How did the idea for Runway actually come together?
Our founders were all former mobile engineers, including myself, and we'd worked together years earlier as the first iOS team at Rent the Runway. We scattered to different mobile teams afterward but stayed close friends, comparing notes over time and realizing a lot of the friction, inefficiency, and quality issues we were each running into were common across nearly every team, just manifesting differently. It really crystallized during COVID — we had a group WhatsApp thread and had always talked about working together again, maybe as a small agency building apps. That conversation broadened into what other problems we could solve together, and it moved into a shared Google Doc. One of my co-founders dropped in the idea of release management, and it resonated immediately — I remembered viscerally how differently every team handled this. Without a dedicated release person, the workload gets shared in a round-robin across engineers and PMs, and if your team is large enough, your turn doesn't come around often enough to remember how to do it properly. You're working off a stale spreadsheet checklist, asking people for input as you go, and splitting your attention for a week or two managing progress and looping in the right people — not fun if you're a product-focused engineer who wants to build, not act as a traffic cop.
What did you do before writing any code?
A whole batch of interviews. We had firsthand conviction about the problem, but wanted to validate it before writing a single line — we set up as many calls as we could with former teammates, mobile folks in our network, and friends of friends across different team sizes. Our early hypothesis was that this was for any team with more than roughly two mobile engineers shipping regularly. It wasn't a unanimous hit, though — people on larger teams with an existing rotation, who hadn't run a release in a while, sometimes had less acute memories of the pain. Others weren't close enough to the process to see the friction, especially if they just merged PRs and watched things ship on a train without visibility into regressions or triage further down the line. So it became a mix of personal conviction and these interviews, since releases aren't always top of mind for everyone on a mobile team at any given moment.
Once you had that mixed signal, what was the next step?
We got to a point where we were happy enough with the direction and started building. Our team's background is mostly product-focused mobile engineers — a common trait in mobile, where a lot of engineers love building product and are naturally less drawn to tooling and automation work themselves, though that's shifted some as mobile has matured. We were heads-down building for three or four months, trying to get an MVP out as fast as possible. That was genuinely hard, because Runway's whole value is its breadth — connecting across a team's entire toolchain and catering to many different roles. We didn't have confidence that descoping down to a single integration or one part of the process would get us a real foot in the door, and honestly, it wasn't the vision we were excited about either. So we deliberately shipped broad but thin — enough connective tissue across the whole process to give people a sense of the eventual power, even if each individual piece was still shallow.
What was it actually like convincing that very first team to try something so early?
Because Runway is so broad, it becomes tightly coupled to how a team already works — which is great once you're in and it becomes the new, better normal, but tricky beforehand, since we touch so many different parts of a team's process and could be used by so many different roles. Even offering it for free to that first cohort, there's still a perceived disruption cost for a busy product engineering org that can't easily onboard a new tool mid-flight. The early challenge was building just enough that people wanted to try it — a couple of genuine time-saving nuggets, or a clearly better way of collaborating, that outweighed the small amount of setup effort required.
How did you get that very first customer to actually commit?
A lot of dialogue — we looped them in as a design partner before we'd even handed over a finished product, involving them while we were still building the MVP and making sure we hit the specific things they cared about most. Some of it came down to finding someone who genuinely believed in the larger vision and was willing to accept that the MVP was a shadow of what was coming, because they could see where it was headed and wanted to help shape it. That, plus existing rapport from working together on past teams, made the difference.
How many of those deeply invested early customers did you actually have, and how did you balance their requests against your own roadmap?
We had three teams in that first cohort, roughly matching our current ideal customer profile — medium to large teams shipping mission-critical mobile products — while also going through YC at the same time. Balancing feedback against our own vision worked out better than I might have expected, partly because the vision itself was broad enough that most incoming requests naturally fit somewhere inside it — it became more a matter of reprioritizing what we already knew we wanted to build, rather than being pulled in genuinely new directions. That gets harder once you have paying customers actively offering money for specific things, and you have to balance that against building correctly. But I think it goes back to the fundamental fact that we were building for ourselves, for people just like us — that alignment is what made it keep working.
You've mentioned Slack Connect as a big part of the early customer relationship. How did that work?
It's been a huge, if not infinitely scalable, part of our strategy — now a paid support tier for most customers, but we'll still open it up for teams running trials. The speed and ease of communicating that way, answering questions and reassuring teams in real time, makes us something like a fly on the wall or an extension of these teams, and they know they're often talking directly to founders, or at least to fellow mobile engineers who've actually worked on mobile product themselves. Given how deeply Runway touches a team's process, partnering closely with them through that early period matters a lot — though we're mindful it's not infinitely scalable, and there are tools now built specifically for managing that at scale.
Is there a risk of that closeness turning Runway into more of a services business than a product company?
That's something we stay mindful of — we don't want to cross the line into being a tooling DevOps agency, even though there's sometimes real appetite from customers for that kind of formal, embedded extension of their team. It's another place where balance matters, and so far we've stayed on the right side of that line.
How did you actually land your first paying customers beyond that initial design-partner cohort?
The most concrete answer is coming out of YC. The community there is genuinely useful — a lot of mobile-forward companies in the alumni network who've gone on to do well — and while that's not dramatically warmer than cold outbound, it helped a little. The other factor was inbound: a few coverage spikes around our YC batch got us noticed for the first time and led to our first real wave of inbound interest, along with a lot of demos and feature requests. Because the platform was still early, we could only support one or two tools at each integration point, which is a constant, ongoing challenge — hammering out support for the most commonly used tools across every kind of mobile team takes real, sustained effort. Even demos that didn't convert were valuable data points, feeding directly into roadmap prioritization for the next team we'd inevitably encounter with similar needs.
Is there a network effect you're now trying to lean into?
Yes, and it's something we're focusing on more deliberately this year, though you can't force it. We're effectively creating a category — release management as a defined thing a mobile team should go looking for — and we haven't been as deliberate as we probably should be about defining the language around that category everywhere. As it takes hold, you get a great motion where mobile engineers move between teams — and there's a lot of turnover in mobile — and having had a genuinely better experience with Runway on a previous team, they bring it up when they land somewhere still stuck in the old, painful way of releasing. That's the motion we want to keep building toward, and it gets easier as the category itself becomes better understood, so people bringing us to a new team don't have to explain the whole concept themselves from scratch.
Given how deeply Runway integrates into a team's process, is the go-to-market motion mostly sales-led or self-serve?
Almost every customer ends up on a call with an account executive at some point, but there are really two motions. A fully sales-led one, where people loop in teammates and a demo conversation kicks things off. And a self-serve one we launched more recently, which was important to us, but until relatively recently there wasn't much someone could actually do on their own without buy-in from the rest of their team or sign-off to connect a bunch of integrations — real process-related roadblocks. So we focused on keeping that entry point open: a sandbox, and a 'demo mode' toggle inside the product that fills unconnected sections with representative data, so people can start getting a feel for it even before everything's wired up. Some teams sign up, connect everything themselves, and never talk to us beyond maybe one call to tie up loose ends; others need the full guided path. It's a genuinely complex product for the kinds of teams we sell to, with real buy-in and consensus-building steps that naturally slow the cycle and push it away from pure self-serve — for now, self-serve mostly functions as lead generation and an open, welcoming door rather than the primary path.
Does that multi-touch sales process make growth harder to measure?
Very much so — it's something we think about a lot, and getting attribution right across all those touchpoints matters. Someone might have seen us in a newsletter sponsorship, then at an event, then poked around the product itself before ever talking to sales — a real multi-touch education process rather than a single clean funnel. Our head of growth has put a lot of work into instrumenting that properly so we can actually see, deal by deal, the different people and moments involved.
What's the high-level focus for where Runway goes from here?
Mainly expanding along two axes. One is breadth — we're present at more and more points across the release cycle, and increasingly the broader development lifecycle, like our recent build distribution feature, which makes distributing different build flavors easier not just for release candidates but throughout development, getting builds to QA, designers, and product owners. The other is depth — going deeper into the parts of the process we already touch, automating and surfacing far more than we could in the early days, and taking on more of what's actually happening at each stage where it makes sense for us to own more of the workflow.