When sales and product led growth meet, with Railway's Angelo Saraceno
Angelo Saraceno on why Railway refused to fork its product to chase enterprise revenue, how a webhook on the 'static IP' button quietly tells sales who's really an enterprise customer, and why cold outreach response rates jumped from 0.017% to 3-4% once they got specific.
Angelo Saraceno joined Railway as a support engineer and ended up building out its revenue and compliance functions. He combines a strong business mindset with real technical depth, and writes sharp, technical essays about sales — including the Slack automation system Railway built after burning through support vendors.
We get into how Railway grew upmarket without forking its product or building a traditional SDR pyramid, why most ICP advice is contextless, the difference between selling into a cost center versus a profit center, and the sales automation that turned Railway's cold outreach response rate from a dismal 0.017% into 3-4%.
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.
You moved from being a Railway support engineer into sales. What surprised you most about that transition?
I assumed I'd be going into demos with high-aspirational pitches — deploy in minutes, not days — and closing invoices and LOIs. The actual pain points customers were experiencing were much more pragmatic, sometimes even emotional — will implementing this tool at this company get me promoted? That's a concern I hadn't considered at all going in, and it's a completely different skill set to navigate. A lot of engineers are also bad at indicating what they actually want. We'd get an ask like "give me better infrastructure-as-code," and if you take that at face value, you go build IaC tooling. But peel back the layers — why do they want it, what's the upper-level goal — and often it turns out the infrastructure team just needs to make it possible for a product team to get resources provisioned without learning a whole new YAML-based language. The product engineer doesn't care about IaC at all; they just want their GitHub repo live and someone to handle the internal political process. A bad SDR who isn't technical hears "I need IaC," runs to engineering, and now you've got an internal fight between what sales thinks needs to be built and what the actual product vision is.
Why did Railway refuse to fork the product to chase enterprise deals, when it sounds like that cost real revenue?
Jake was very firm from the start that we would not go off and do engineering side quests to secure revenue — features that moved us upmarket had to be extraordinarily painful to build, because when we shipped them, it needed to be a flood of revenue, not a one-off custom build. There were times I was sitting across from him saying you're blocking eight figures of revenue by saying no to this, and he'd just say we need to wait until we have the right story. The alternative — forking a cloud-hosted enterprise version against a core open-source or community version — is what I call the tent of suffering. You end up with a free distribution model that's fundamentally at odds with how you eventually monetize, and when a company gets a Series C or D and has to change how it charges, it enrages the user base it built on giving things away — you've seen this with the whole Redis situation. Open source also sets the effective labor value of a lot of contribution to zero, which is fine for someone post-exit like Mitchell Hashimoto, but very hard to defend when you're trying to charge five, six, seven figures for something an engineer can point to as free on GitHub.
You mentioned John McMahon, the five-time CRO behind MongoDB's commercialization, as someone worth studying. What did he actually do differently?
Most ICP advice from startup and VC circles isn't wrong out of malice, it's wrong because it's contextless — the same way reading the Google SRE handbook out of context leads you to over-engineer past your organization's actual maturity. MongoDB had a reputation problem — the "MongoDB is web scale" meme existed because their early benchmarks came from writing to dev/null — and yet McMahon built it into a company that IPO'd at a huge market cap. He did it by identifying who was actually on the leading edge of software development at the time, mainly enterprising web developers and video game companies who didn't care much about rigid schemas, and sold to them specifically rather than to developers broadly, who are famously one of the hardest customer segments to sell into. What he's most known for is being precise about separating champions from actual decision makers who control budget — a lot of early startups mistake 50,000 free users for product-market fit, but if those users aren't reaching for a credit card, they're not who you should be building for.
How does that play out for you at Railway — figuring out who your real ICP is?
The way we've applied it is to listen obsessively to every objection on every call, because that's where you learn what someone's actually willing to pay for versus what just makes them browse your product. Railway's pitch is that companies ship faster with us than on any other cloud platform — but the workloads that actually need that velocity tend to be newer, more iterative products, not the core monolith a business depends on that only gets a release cut once a week because of how protective people are of it. We'll get someone in the door excited about shipping speed — that's our champion — but the person we actually have to make happy might be the VP of infra who cares about something completely different. There's also a US tax-code quirk that shapes this: you can write off R&D for software engineers but not for DevOps engineers, so platform engineering teams tend to be chronically understaffed and treated as a cost center rather than a value generator. We're careful never to market ourselves as replacing those people's jobs — nobody's selling painkillers to the person stuck firefighting in a server closet, and our goal is to properly serve them, not antagonize them.
What's actually different about selling into a cost center versus a profit center?
If you're selling something defensive — say a FinOps tool promising budget visibility — your mindset has to be defensive too: you're targeting people who control budget, like a VP of infra or a CFO, and a CFO views the world very differently from a CTO. The decision maker might be the CFO, but the engineer still has to use the thing day to day, so you have to nuance your way down from that top-down sale. Value-generating software, by contrast, is much better sold bottoms-up — which I'd argue is part of why Cursor has done so well. When you're reaching for a tool in that mindset, Cursor is right there; Copilot's entry point is going through VS Code first, a two-door process that keeps it from being top of mind. Selling a cost-cutting product bottoms-up is much harder, because a line engineer isn't clamoring to cut spend on their own — nobody wakes up thinking about cost cutting, they think about doing their job better. The way you make it work is aligning incentives so using the thing makes the engineer look good to their boss, even if they won't get promoted for it directly.
How aware are engineers of what they'd feel comfortable asking their company to spend money on?
There's a real embarrassment threshold — software can embarrass you internally. If you just joined a company, would you feel comfortable asking leadership to approve $10,000 a month in new software? For most people that's a very high bar unless what you're asking for is genuinely transformative, like something that could replace a huge chunk of engineering work. That threshold is exactly why we built Railway's sales automation the way we did — we let anyone build anything on the platform without gating features behind a sales call, but we watch for signals, like pressing the static IP button, which triggers a webhook straight into our CRM saying this looks like a legitimate enterprise use case, we should start talking to them. We're honest that we allow generous usage limits — we call them Canadian limits internally — and only start the email drip once someone crosses thresholds that heuristically look like real production use.
How well did that targeted approach actually perform compared to regular cold outreach?
Regular cold outreach emails were getting us something like a 0.017% response rate, compared to an industry standard around 0.3% — genuinely abysmal. Targeted emails tied to specific in-product signals, without a live dashboard in front of me right now, land somewhere around 3 to 4%, which is very good for pulling real concerns out of customers. Because Railway is consumption-based, success on our side means figuring out every workload someone has, on or off Railway, that would justify a real SLA and SLO. Those conversations take about six months, and one moment of arrogance I'll admit to: early on I thought we could compress that the same way we'd compressed deployment times, down to a month. We were wrong — there are a lot of out-of-product concerns, security review among them, that Railway had to mature into handling before that was realistic.
You've talked about wanting Railway to feel like the Chick-fil-A of infrastructure. What does that actually mean operationally?
Chick-fil-A is obsessive about the whole experience around the sandwich, not just the sandwich — they have operations researchers optimizing queue flow and run a genuinely sophisticated distributed operation behind the scenes per restaurant. I wanted that same obsession with hospitality applied to how we run sales and support. It's part of why we ended up building our own support tooling: we tried a couple of vendors, including one that was pivoting away from being an API-first support system just as we needed exactly that, and we couldn't get the Slack-based support experience we wanted — spinning channels up and down per customer relationship, tied to our own source of truth for who our customers actually were. After churning through two vendors, my colleague Ray and I just built it ourselves. Now when someone opens a support message, they select the specific resource they're having an issue with, and the person on our side has all the context immediately, without a back-and-forth over invoice numbers. That's what lets a support engineering team of four, with only two people on rotation at a time, handle a lot of ticket volume without customers feeling like there are only one or two people behind the screen.
What's the next challenge as Railway keeps growing into bigger accounts?
We're just starting to cross into needing dedicated success resources for our biggest accounts, rather than the floating account coverage that got us through the last five years. Customers with a long-running relationship and a long-running ask want to see the same person, or at least the same small group of people, every time — you can throw all the AI summarization you want at handing off an account between support reps, and it still isn't the same as one person who actually understands it. The standard has to be high enough that it doesn't matter exactly who's in the chair, the same way a well-run sports team's identity doesn't depend on any one player — but getting there without leaning on a handful of superstar reps is its own separate organizational challenge.
Links & references
- Railway ↗
- Railway's blog ↗
- John McMahon's book, The Qualified Sales Leader ↗
- Angelo's Slack automation article ↗
- Angelo's website ↗
- Angelo's LinkedIn ↗
This episode is brought to you by WorkOS.