Five Things Tech Companies Don't Realise They Need to Know About Rail

A tech company with a strong track record in another sector looks at rail and sees an obvious fit. They've delivered at scale. They know they can do the work. So they approach the industry expecting their existing credentials to open doors.

They don't.

Rail buyers are polite. They take the meeting. But nothing moves. The tech company assumes the problem is awareness, so they sponsor an event, take a stand at a trade show, maybe join an industry body. Still nothing moves.

At that point they either give up and write rail off as impenetrable, or they start asking what they're actually getting wrong.

1. The Evidence Doesn't Travel

The answer is almost always the same. The capability is real. The evidence that rail buyers need to see doesn't exist.

Not because the company hasn't done good work. The proof points from their existing projects are locked inside contracts and case studies written for a completely different audience. A rail operator doesn't care that you reduced processing times for a government department by 40%. They care whether you can reduce dwell time, improve right-time performance, or cut the cost of a specific back-office function they're about to have to absorb under public ownership.

The metrics need translating. The language needs translating. The buyer logic needs translating.

I've sat in rooms where companies show me materials they've been taking into rail conversations. The case studies describe what they did for a government department, or a local authority, or an airport operator. The metrics are framed around the client's world: processing volumes, cost per transaction, system uptime.

Those are all real numbers, defensible in their original setting. They mean nothing to a train operating company trying to work out how to absorb a back-office function under public ownership.

The moment of realisation usually comes when I ask them a simple question: which rail buyer would read this case study and see their own problem in it?

The room goes quiet.

2. The Safety Case Nobody Saw Coming

The thing that hits hardest when tech companies finally get into a real procurement conversation is the safety case. Most tech companies have never encountered anything like it. Even the ones that come from other regulated sectors.

They'll tell you they've worked in defence, or healthcare, or aviation, and they assume that experience translates. It doesn't. Rail has its own safety regime, its own standards body in RSSB, its own assurance processes, and its own expectations about what evidence you need to produce before your technology goes anywhere near the operational railway.

A safety case is a structured argument, supported by evidence, that demonstrates your system is safe to operate in a specific context. People expect a form to fill in. What they find is something much heavier. The burden of proof sits with you, the supplier.

You have to show that your product works, and then go a good deal further. That it works safely in the particular environment it's going into, that the failure modes are understood, and that the mitigations are adequate.

For a tech company used to shipping product on a quarterly cycle, the documentation alone can take longer than their entire development timeline.

3. Standards Compliance: Beyond the Checkbox

The other piece that catches people is standards compliance, and specifically interoperability. Rail systems don't exist in isolation. A new piece of technology has to interface with signalling, telecoms, operational data systems, and asset management platforms, many of which were designed decades ago.

You can't just build to an API spec and call it done. You need to demonstrate that your system behaves correctly within a network of dependencies that you didn't design and may not fully understand when you start the work. The interoperability requirements go deep, spanning everything from data formats to failure modes to how your system responds when something three layers removed from it stops working.

This is where tech companies from other sectors get caught out. They're used to modern integration patterns: RESTful APIs, clear documentation, version control. Rail infrastructure includes systems that predate those concepts entirely. You might be integrating with a signalling system from the 1980s, an asset management platform that's been customised beyond recognition, and a reporting framework that was built for a different operator entirely and inherited through franchise changes.

What this means commercially is that the cost of entering rail is much higher than most tech companies have priced in. I've seen companies budget six months for what turned out to be a two-year approval process. Their commercial model assumed they'd be generating revenue within the first year. By the time they got through assurance and interoperability testing, the funding round that was supposed to carry them had run out.

4. When Reality Hits

The realisation usually arrives in stages. The first stage is denial. The company has already committed to a rail strategy, often publicly, sometimes to investors. They've built a roadmap, hired a business development lead, maybe issued a press release about their ambitions.

When the regulatory timeline becomes clear, the instinct is to assume it's negotiable. They'll ask whether there's a faster route, whether the right introduction could shortcut the process, whether their existing accreditations from other sectors can be ported across.

The answer to all of those is no. But it takes a few conversations before that lands.

The second stage is bargaining. They start looking for smaller entry points. A pilot somewhere the safety case is less heavy. A partnership with an established supplier who already has the assurance in place. Some of those are sensible pivots and they work. Others are still magical thinking.

The third stage is the hard conversation internally. The product roadmap was built around an assumed deployment timeline. The commercial forecast assumed revenue within a defined window. Neither of those holds anymore.

Someone has to go back to the board, or to the investors, or to the leadership team, and explain that rail is going to take longer and cost more than they pitched it. That conversation can be career-defining for the person who has to deliver it. I've watched senior business development people lose their jobs over commitments they made about rail before they understood what they were committing to.

5. The Incumbent Advantage Nobody Talks About

The advantage tech companies consistently underestimate is risk absorption. An incumbent supplier has been delivering to that buyer for years, sometimes decades.

They've had outages, missed deadlines, performance issues, contract disputes.

All of that has happened, and the buyer knows exactly what failure looks like with this supplier, how it gets handled, and how quickly things recover.

That history is uncomfortable for the supplier, but it's enormously valuable to the buyer. They've already absorbed the worst case and survived it. A new supplier, however good their technology, represents an unknown risk profile. Nobody knows yet what their failure mode looks like, how they respond under pressure, or whether they'll still be in business in three years.

For the person inside the operator making the decision, that asymmetry matters more than capability comparison.

The incumbent might be slower, more expensive, and less innovative. The buyer knows all of that. They also know they will not be fired for staying with them.

Choosing the new entrant introduces personal career risk that the existing supplier does not.

The second advantage is operational embeddedness. An incumbent has built systems that talk to the operator's existing systems, in ways that are partly documented and partly tribal knowledge inside both organisations. Switching costs are real. Data migrations are expensive. Integration work is expensive. Training staff on a new system is expensive.

Buying the new product is the easy part. The harder part is reorganising the workflow around it, and that cost falls on the operator.

The Mindset Shift That Actually Works

The companies that eventually succeed are the ones that stop selling and start learning.

They invest time in understanding who buys what, through which route, with whose budget, and against which political or regulatory pressure.

None of that homework is glamorous, but it decides whether you get a meeting or a contract.

The first structural change is the financial model. If you've raised investment on an 18-month or 24-month return horizon and you've now accepted that rail is a three to five year journey to meaningful revenue, the company you raised for is not the company that can deliver this.

The companies that handle this well look at the capabilities they have and identify adjacent markets where the same technology can generate revenue on a faster cycle. Local government, highways, aviation, logistics. Markets where the regulatory burden is lighter and the buying cycles are shorter. That work then underwrites the rail strategy.

The second structural change is bringing in sector expertise. Either a senior hire who knows rail from the inside, or a structured advisory relationship with people who do.

This is not a job a generalist business development lead can do. The buying logic, the political context, the regulatory pathway, the language of the briefs that come out for tender. None of that is intuitive from the outside.

The sector expert collapses a learning curve that would otherwise take the company two years to climb. They walk in, look at the strategy, and identify five or six things that need to change immediately. None of those changes are about the technology. They're all about how the technology is being positioned, to whom, and when.

Think Like an Investor, Not a Vendor

The mindset shift is to stop thinking like a vendor selling a product and start thinking like an investor buying a position in a sector.

Everything that makes rail slow and expensive to enter is the same thing that protects you once you're in. The regulatory burden, the relationship depth, the assurance work, the time it takes to build credibility. That moat is real, and right now it's keeping you out. The moment it stops keeping you out, it starts keeping your competitors out.

Tech companies are conditioned to think in product cycles. Ship, iterate, scale. Rail thinks in asset lifecycles. The trains running today will still be running in thirty years. The signalling system being commissioned now will outlast most of the people who designed it.

What you're really after is a place in the industry. Earn that, and it becomes very hard to lose.

The companies that succeed in rail typically do so for a long time. The contracts are large, the relationships are durable, and the work compounds. The companies that fail in rail usually fail quickly, often within the first eighteen months, because they tried to apply a vendor mindset to a sector that doesn't reward it.

If you accept that, the maths starts to work. You're not trying to generate revenue in the first year. You're investing in a market entry that pays back over a decade. You build the evidence properly, you bring in the right people, you commit to the regulatory pathway, and you let the sector come to you on its own timeline.

That requires patience your investors may not have, leadership that understands what it's signing up for, and a commercial model that doesn't depend on rail revenue to keep the lights on.

The companies that get this right become indispensable. They're the ones a decade from now that everyone assumes have been part of the rail industry forever.