How Railway Picked Which Signups to Target for Sales

How a Service With 10,000 Daily Signups Chose Whom to Target

I recently built a financial-products analysis site as a side project, and that’s how I first used Railway, the cloud deployment platform. Before that, I’d assumed Vercel and Supabase were enough, and I was still debating whether I really needed an error-tracking tool like Sentry. Cost considerations pushed me toward Railway, and using it taught me more than just technical lessons—it also gave me a useful reference point for how a company acquires and supports customers. It happened that I read a post Railway published on May 6, 2026, titled Kill your onboarding. The piece describes how the company changed the one-size-fits-all sales emails it sent to new signups.

At the time, Railway said it was seeing more than 10,000 new signups a day, with roughly 2,900,000 cumulative signups before April 2026. The sales team had identified about 21,000 accounts matching its ICP¹—its ideal customer profile—but had contacted fewer than 1% of them. Even among users who belonged to companies, the support they needed differed depending on whether they were running a personal project or building out their team’s actual production environment—yet everyone was getting the same onboarding email. This piece isn’t a report diagnosing weak revenue or proving that revenue improved; it’s an early case study of how the company changed the way it found and reached out to prospects.

Making Usage Data Useful for the Sales Team

In PLG² models, where customer acquisition happens through product usage experience, keeping the signup process simple is essential. But if you never ask about company or team size, the sales team has to figure out how customers are actually using the product through other means.

Some users, like me, are building personal projects; others belong to teams using it for company work. Railway lets people sign up with a GitHub account or email and deploy right away, and I’ve heard they deliberately left out any survey asking for company name or engineer headcount. Get people to try the product first — but that means the process of identifying enterprise customers has to be handled separately.

At the time, the sales team consisted of 1 AE (account executive) and 2 SEs (solutions engineers). This small team needed a system to help them figure out which of the 21,000 potential enterprise accounts to reach out to first.

Founder Cooper pointed out that they weren’t making full use of the leads and usage data they’d already gathered for sales purposes.

Railway had been collecting product usage events through PostHog for a long time. Its internal system, backboard, also logged each project’s service configuration, instance size, database connections, and deployment outcomes. The data needed for analysis existed — what was missing was the process of using that data to identify which accounts the sales team should contact.

McKinsey’s research on PLG also describes an approach that looks at both product usage experience and company information together, bringing in the sales team at the right moment. Customers whose likelihood of purchasing is assessed based on usage behavior are called PQLs³. Beyond just growing the signup count, the real work is figuring out which users need what kind of support.

Behaviors That Show Up More Often on Enterprise Accounts

Des Conlon, a solutions engineer at Railway, compared which behaviors showed up more frequently on enterprise accounts versus individual hobbyist accounts. He built an analysis environment with Hex and dbt and calculated the frequency of each behavior. He used Hex’s LLM feature to write repetitive queries, but the final score was calculated using behaviors and weights he chose himself.

Conlon deliberately excluded the signal that looked like the strongest predictor on the surface.

For instance, SSO usage showed up strongly on enterprise accounts, but it was a feature that only customers who’d already talked to the sales team could activate. It wasn’t useful for the goal of finding enterprise customers the company hadn’t yet met. Conlon was wary of this kind of label leakage⁴ — where information that only exists after you already know the answer bleeds into your inputs.

The criterion Conlon settled on was behaviors that individual developers could also perform, but that showed up far more often on enterprise accounts. He combined the following five:

• Downloading security documents: Downloading security and compliance reports like SOC 2. Railway said that when the sales team reached out to these users, the response rate was around 50%. It was the strongest single signal, but on its own it wasn’t enough to confirm an account as enterprise.
• Seat count and growth trend: How many team members an account had and whether that number was growing. Eliminating seat-based pricing in 2025 helped reduce the effect of teams delaying invites to avoid extra charges.
• Credential resets: Conlon guessed this might reflect an organization’s security policy, though it could also just be friction in the authentication process — a signal that needed further verification.
• Connecting external or managed databases: Connecting real data showed up more often on enterprise accounts.
• Specific deployment failure patterns: He looked for patterns closer to the problems teams encounter while building actual production environments, rather than one-off failures.

He used how much more frequently each behavior appeared on enterprise accounts as its weight, then calculated a score per account. The ratios used here reflect the behavioral difference between enterprise and individual accounts — they are not a measurement of how much revenue increases when an email gets sent.

There were two reasons Conlon chose a simple weighted sum. First, for a new signup, the behavior data available for judgment is usually only a day’s worth, which limits how useful a more complex model would be. This doesn’t mean the company only retains a day’s worth of historical events. Second, the person handling outreach needs to be able to read why a score is what it is. Knowing that “this account downloaded security documents, has 8 team members, and connected a database” makes it much easier to decide who to contact and why.

Sending Emails When Help-Seeking Behavior Appears

Mid-scoring accounts received automated emails through Customer.io, while high-scoring accounts were routed directly to sales reps and solutions engineers for personal outreach.

The automated emails weren’t triggered by fixed dates like day 1, day 3, or day 7 after signup. Instead, they went out immediately after a business account showed a specific usage behavior.

The sending conditions were strict, too — both had to be met at once:

• The event had to correlate with the likelihood of being a business account
• The event had to occur at a moment when the user seemed slightly stuck, or was making an important decision

And the email itself wasn’t a meeting request. It didn’t pitch the enterprise tier either. It was sent under the name of an actual sales rep, with content along the lines of: “It looks like you’re working on this — is there anything I can help with?”

On the first day, about 300–400 emails went out, with per-event open rates in the first 24 hours running around 50–70%. Only 2 actual replies came back. The previous generic emails had an open rate of about 27%, but it’s hard to treat these two figures as a clean before-and-after measure of the experiment’s impact.

Railway itself acknowledged that Apple Mail’s privacy features can inflate open rates, and that they’d selected recipients who were already more likely to be worth contacting. The sample was small, too. They hadn’t yet run an A/B test comparing this against sending no email, or sending the generic email, to accounts under the same conditions.

What I want to take away here is the sending condition itself. Rather than blasting every user connected to the database, they looked at two things together: whether an account was likely to be a business customer, and whether it was at a moment when it needed help. It’s an approach that resists declaring victory just because open rates went up, and instead tries to track whether it actually leads to replies, conversations, and contracts.

Oswarld’s Lens

This case laid bare a failure pattern I’ve seen again and again while building GTM strategies.

When a company’s growth slows, the instinct is often to tinker with the visible stuff first—email copy, landing page design. But in cases I’ve worked on, the bigger problem was often upstream: deciding who to pitch in the first place. Even great copy only works if it reaches the right person. Railway’s case is a reminder to check whether you’re finding enough of the right customers before you start polishing the message.

What also stood out to me was the contrast between what Conlon faced at Looker and at Railway. At Looker, there were questions the customers wanted answered, but often no event tracking or data storage and organization to answer them with. At Railway, the data existed, but it never turned into analysis the sales team could act on. The first problem had to be solved by fixing data collection and organization; the second, by fixing the criteria for picking customers.

The role built to handle exactly this is the GTM engineer—someone who doesn’t just lean on sales team hunches, but compares behavioral data, filters out false signals, and turns the results into scores reps can actually understand and act on. AI can help write queries and run analysis, but someone still has to decide which customers you’re actually looking for, and verify whether the results hold up.

I don’t think GTM-related roles get much attention in Korea yet. I keep writing about this space because I believe the need for it will only grow. Building a good product isn’t enough—someone also has to find the customers who’ll use it and turn that into revenue.

Closing

When applying the Railway example to our own work, it’s worth checking the following.

• Confirm whether the sales team can identify who to contact based on recorded post-signup behavior.
• If you’re using a scoring system, check whether the people responsible understand the reasoning behind it and can correct it when it gets things wrong.
• Track email performance beyond open rates — track replies, consultations, and closed deals. You need a control group to isolate the actual effect of sending the email.

Before you rewrite the copy in an onboarding email, check whether that email is even reaching the right customer at the right moment.

What behavior does your organization track after signup to decide who the sales team reaches out to? If you’ve found a criterion that actually worked, I’d love to hear about it in the comments.

Looking at the fragment, I compared it carefully against the Korean source. It appears accurate, with correct glossary terms (Oswarld, Kwangseob Ahn), all numbers preserved, matching headings, links, footnotes, and image. No Hangul remains.

References & Further Reading

Primary sources

• Des Conlon, “Kill your onboarding: selling to 10,000+ new users a day”, Railway Engineering Blog, May 6, 2026. : This lays out the entire journey from PLG to sales conversion from a practitioner’s point of view.

Background

• McKinsey, “From product-led growth to product-led sales: Beyond the PLG hype”, August 8, 2023. A study on designing product usage experience and sales activity together.
• Apollo, “GTM Engineer: The Revenue Strategist Building Modern Go-to-Market Systems”, February 25, 2026. Explains the role of the GTM engineer, who connects sales strategy with data and automation work.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

Footnotes

1. ICP (Ideal Customer Profile): A set of criteria defining “what kind of organization would get the most value from our product?” It’s built by combining factors like company size, industry, region, and funding stage. ↩

2. PLG (Product-Led Growth): A growth strategy centered on the product’s own usage experience to acquire and convert customers. Sales team support can be layered on top. Slack, Notion, and Figma are well-known examples. ↩

3. PQL (Product Qualified Lead): A lead evaluated for purchase likelihood based on actual product usage behavior, as distinct from an MQL, which is evaluated mainly on marketing touchpoints. Conversion rates vary depending on the product, the customer, and the evaluation criteria used. ↩

4. Label Leakage: A phenomenon where the answer you’re trying to predict ends up mixed into the input data. Performance may look strong during validation, but if that information isn’t actually available at prediction time, you can’t expect the same performance in practice. ↩