Building an In-House Journey Planner for a Rail-Ticketing App
DBB Software is engineering the intelligence layer behind a UK rail-ticketing product: an in-house journey planner that computes routes, fares, and split-ticket savings directly from the rail industry's official data feeds. The work takes the product from reselling a third-party retail API to owning the engine that finds and prices every journey.
Industry
Travel & Hospitality
Service
Product Discovery
Team
2 Senior BE Developers, 1 Senior Mobile Developer, 1 Senior Web Developer, 1 QA Engineer, 1 Designer
Project State
February 2026 - Ongoing
Country
United Kingdom
About the Client
Our client is a promising startup that wants to offer consumers a convenient way to book and buy train tickets. Their solution aims to provide users with an alternative to outdated rail-ticketing platforms through an optimized user flow and user-focused UI.
The Client's Initial Request
The client engaged DBB Software to move the journey-planning and pricing intelligence in-house because growth was hitting the ceiling of what a third-party retail API allows.
Lift the Pricing Ceiling
Own the fares and discount logic so the product can apply multiple railcards, surface better split-ticket savings, and price journeys the third-party integration could not.
01
Unblock the Roadmap
Free features like richer ticket detail and control over how results rank and display from an abstraction layer that kept them out of reach.
02
Build on Official Industry Data
Base the engine on the same authoritative feeds the railway itself runs on, so journeys, prices, and routes reflect the real network rather than a reseller's subset.
03
De-Risk Before Committing
Prove the in-house engine is viable, and on what data, so the full build becomes a funded decision rather than a leap of faith.
04
Solutions We Delivered
DBB Software is delivering the journey planner as a governed progression from research to running code, with the same embedded senior team that built the original product.
Feasibility and Standards Research
The team validated the entire public specification corpus of the UK rail retail industry: 24 primary specification documents, roughly 27,000 lines, read end to end, with 74 industry documents mapped. Every prior assumption was fact-checked against live official sources under a deliberately adversarial method, with official feeds treated as the only ground truth and independent blind reviews run to remove confirmation bias.
The Alternatives, Eliminated on Evidence
The industry's own journey-planning web service is contractually barred from use alongside ticket retailing, which removes the obvious option for any retailer.
Commercial engines were assessed and priced at enterprise terms, and no complete open-source journey planner exists for the GB network.
Building also keeps the split-ticketing algorithm, the client's own differentiator, under the client's control. No industry specification governs it.
Solution Architecture and System Design
A provisional System Design Document covers the data platform, journey planning and fares, reservations and payments, real-time data, fulfillment and after-sales. It reconstructs behavior the industry's public documentation leaves to accredited systems, through a provenance-tagged architecture so no data format is ever assumed rather than sourced.
A Migration Scoped to the Service Layer
Replacing the engine beneath a live product is designed to be invisible to the people using it.
The existing platform's domain separation means the work lands entirely in the service layer. Controllers, the client-facing API contract, the mobile app and the web app are unchanged.
No app-store release is needed to swap the engine, which takes a release dependency and a review cycle out of the critical path.
An adapter layer normalizes more than five source formats, from fixed-width timetable records and flat-file fares through XML, JSON, REST and streaming, into one set of internal domain models.
Data Engineering on the Official Feeds
The team designed the ingestion layer for the industry's raw feeds: the national timetable in CIF format, the fares dataset, the National Routeing Guide, and reference data for stations and operators.
Scheduled jobs pull, validate and load the feeds, with daily incremental updates and a full refresh on a longer cycle.
The design handles the formats' well-known traps: fixed-width layouts, sequence rollovers, full-refresh surprises, and records that are never deleted and must be expired by the consumer.
The Journey Planner Engine
A working proof-of-concept, built as a module inside the existing platform, computes station-to-station journeys from raw timetable and routeing data, then prices them.
The timetable becomes a graph where stops are nodes and services are edges, queried by location code and time window, covering interchanges and joined or split trains.
The fares engine resolves route codes and ticket types, then applies railcard discounts, minimum fares and validity rules.
On top sits the client's own split-ticketing algorithm, which finds cheaper combinations of tickets for the same seats on the same trains.
A Real-Time Overlay on Darwin
Live running information comes from Darwin, the rail industry's real-time feed, over a streaming message channel rather than request polling. The integration is aligned to the industry's own migration of that feed onto its new data marketplace, so the engine follows the network's upgrade cycle.
The Phased Plan and the Accreditation Track
The build is scoped as three phases across 24 to 40 calendar weeks with two senior backend developers, sequenced so the longest dependency starts first.
Phase one is the engine itself: feeds, timetable, fares, routeing, connections and split-ticketing.
Later phases cover reservations, payment, settlement and ticket issuing, each gated on industry licensing.
Retail licensing and accreditation run in parallel from week one, because calendar time on that track, not engineering time, sets the earliest possible launch.
Results Achieved
Autonomous fare computation
The product now computes its own fares and discounts independently.
Native journey routing
The proof-of-concept routes journeys between GB stations, natively handling interchanges and split trains.
Built on official industry data
Every system design decision traces directly to an official industry specification or live data feed.
Seamless backend swaps
The underlying engine can be swapped completely without requiring a new app-store release.
An unblocked product roadmap
Product features previously restricted by the old integration are now entirely under the team's control.
Upfront pricing via proof-of-concept
Early research and a working proof-of-concept secured a firm price for the full build upfront.
Own the Intelligence Behind Your Product
DBB Software builds the engines that decide what your product shows and what it charges, on data you control.
Contact Us
"Most of our work starts with a 30-minute call where someone describes a product they're trying to ship and one part of the engineering picture they can't get around.
If that's where you are, let's set one up; I'll tell you straight whether we're the right fit.”
Mina Morkos
Business Development Manager
Want a similar outcome for your team?
Ask our AI assistant — it can pull related case studies, talk through the approach, and put you in touch with the team if you want a deeper conversation.
