Jake Cooper from Railway | Remote work/team culture, minority report sales and building data centers
Railway founder Jake Cooper explains how a 25-person remote company uses autonomy and software leverage to simplify infrastructure — all the way from proactive support to operating its own data centers.
Jake Cooper is the founder of Railway, an infrastructure platform designed to give developers substantial power without forcing them through the conventional DevOps learning curve.
We talk about remote teams and flat organizations, building systems before adding headcount, Railway's 'precog' approach to sales, designing complexity as depth, running physical infrastructure, and why audacious technical problems can be less risky than they appear.
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 a remote company gain — and give up?
Remote work is a forcing function for autonomy and process: people in distant time zones must be able to drive work without waiting for the founder. It also loses the ambient benefits of being together and makes junior mentorship difficult when overlap is tiny. Railway brings everyone together twice a year, but remote is a deliberate trade-off rather than a universal answer.
How does a flat team of roughly 25 people communicate?
Everyone reported to me at the time, with one-on-ones every two weeks and open office hours. Most company work happens publicly in Discord so information can flow, while direct messages remain available for genuinely personal matters. The structure depends on hiring people able to act independently rather than waiting for instructions.
What does it mean to hire “torpedoes”?
Speed can compensate for imperfect initial direction. A person who takes several shots, learns and recalibrates quickly will converge on the target. At Railway that describes people who take ownership of difficult systems — such as replacing the edge proxy — and keep moving through short feedback loops.
How do you scale with leverage instead of headcount?
Rather than respond to growth by adding a large number of sales, marketing, engineering or support roles, build systems that make a small team more effective. Multifaceted people can go deep in one area while still writing code and improving the machinery around it. The goal is compounding capability, not simply matching every new problem with another employee.
What is Railway’s “Minority Report” approach to sales?
Contact is valuable when a customer actually needs help, not when a generic outbound sequence happens to fire. Railway looks for signals that somebody is approaching a problem and tries to be present at that moment. The promise fails if support then takes a day to respond, so fast resolution and proactive outreach have to be one system.
Why describe support as a catch block?
Users first try the product, documentation, deployments and community; a ticket is the exception thrown when everything before it fails. That makes support broader than closing tickets. The team should improve docs, statically analyze failed applications, fix build providers and help the community answer questions so fewer users reach the failure state at all.
How can infrastructure stay simple without losing power?
Expose complexity incrementally as depth. The first view should map to what the user needs now, while advanced capabilities remain discoverable when the next problem appears. Railway's canvas lets people focus on the visible services and relationships in front of them rather than confronting every possible infrastructure decision at setup.
Why is removing choices often harder — and better — than adding settings?
Asking a user to choose a Dockerfile, buildpack or operating system is easy for the platform to implement but transfers uncertainty to the customer. Static analysis can infer the likely answer and let the deployment proceed. Each unnecessary choice is a place for somebody to leave the funnel, so Railway does more engineering to make the default feel automatic.
Why build your own data centers?
Owning more of the stack unlocks experiences difficult to deliver on rented generic infrastructure: fast image movement, data proximity and copy-on-write environments that safely mirror production data. Railway had two facilities online, more planned, and a small group turning old-fashioned rack diagrams and procurement processes into repeatable software-driven operations.
Why do you tell founders to do harder things?
Hard, audacious problems attract excellent people and often contain neglected low-hanging fruit because everyone assumes they are impossible. Reduce the idea to its essential 80/20, get the first hundred users into a community and find the first dollar quickly. The technical ambition can be large while the first validation loop remains small and fast.
Links & references
- Railway ↗
- Jake Cooper on X ↗
- Angelo from Railway on X ↗
- Tsunami warning reported by the San Francisco Chronicle ↗
This episode is brought to you by WorkOS.