In transport and travel tech you almost never start with a blank page. You already run a platform that sells tickets, plans routes or ties reservations together, and that platform is what brings in the money. The challenge, then, is not writing an app from scratch but transport application development that keeps running around the clock while still gaining new features every quarter. If you are a CTO, head of platform or IT director, you know the tension: the business wants things faster, while technical debt and the risk of outages pull the other way.
In our experience the hardest part is preserving continuity - adding value without toppling what already works. For an aviation and travel technology provider we do exactly that: we develop new features of its existing applications, maintain the systems and run cloud-to-cloud migrations on Java, microservices and GCP. Below we break it down.
Why are transport app development and maintenance one and the same?
Because in a product that lives for years you cannot split them without losing something. A team that only “fights fires” never grasps where the architecture is heading. A team that only ships new features and ignores what already stands leaves you, a year later, with a platform nobody wants to touch.
So we treat it as a single stream of work: new feature development and system maintenance run through the same team that knows the code, the dependencies and the history behind past decisions. Every new feature then plugs into the existing architecture deliberately rather than as a bolt-on, and small maintenance fixes turn into chances to pay down technical debt. In transport, where integrations with external systems are everywhere, that continuity is especially valuable.
How do we build new features into existing transport systems?
We don’t rewrite the product - we grow it incrementally. We step into working code, read its logic and add features so the rest of the platform keeps running.
- we read the existing architecture and dependencies before we change anything,
- we design each new feature as part of a larger whole, not an island,
- we shield the change with tests so regressions don’t kill what already stands,
- we roll out in small steps, with the option to revert.
This approach fits products that handle real passenger or booking traffic and cannot be taken down for a week “because of a rebuild”.
How do we build the backend in transport: Java, Spring and microservices?
The heart of most transport platforms is a Java backend. We build it on Spring and split it into microservices, because in this industry different parts of the system evolve at different speeds: the connection-search engine changes on a different rhythm than the payments module or a supplier integration.
That split gives us independent deployments per service, clear boundaries of responsibility and the ability to scale only what is actually under load. On top of that sits the data layer: we design and maintain the ETL/ELT processes that feed reporting, analytics and integrations. In transport, data about routes, prices and availability is a product in itself, so we treat its flow as seriously as the application logic.
What does a transport frontend look like in React and Angular?
On the user side we work mainly in React and Angular. The choice depends on what the existing product is written in - we adapt to the client’s stack rather than imposing our own.
We develop interfaces that have to carry real complexity: connection searches, availability calendars, booking panels and operational views. We make sure the frontend doesn’t fall apart under a growing pile of features - we keep components tidy, watch rendering performance and hold consistency with the rest of the ecosystem. One team handles both frontend and backend here, so a new feature comes together from API to screen without responsibility being thrown between vendors.
When do we reach for C++ components in transport?
When raw performance is what counts. Some transport systems have sections where milliseconds and memory use make the difference - processing large data volumes, computationally heavy algorithms, components close to hardware or infrastructure. That is where we reach for C++, in the C++17 standard.
It is not our default for a whole application, but a tool for specific, performance-critical elements that we then wire into the rest of the Java-and-microservices platform. The product gains performance exactly where it needs it, without complicating everything else.
How do we run transport app migration to the cloud (GCP, cloud-to-cloud)?
We treat a cloud migration as surgery on a living organism, not a one-off “move the files”. For the aviation and travel technology provider we run cloud-to-cloud migrations to GCP, shifting live systems between cloud environments so the business doesn’t feel it.
- we containerise applications (Docker) and orchestrate them in Kubernetes,
- we describe infrastructure as code in Terraform, so environments are repeatable,
- we automate deployments with CI/CD on Jenkins,
- we migrate in stages, in control of what gets switched over and when.
That infrastructure later delivers what you migrate for: faster, safer deployments, predictable environments and scaling to real traffic.
How do we assure quality: QA and test automation?
In a system that keeps changing, manual testing can’t keep up. So we automate whatever we can. We build end-to-end UI tests in Selenium and API tests in REST Assured, and we wire them into the CI/CD pipeline so every change is checked before it moves on.
As a result, developing new features no longer means a constant regression risk - the team can add value faster because the test net catches bugs early. That is one of the conditions for running development and maintenance in parallel rather than taking turns.
Which skills do we provide for a transport project?
We shape the team around the specific system and the stage it is at, not from a fixed template. Usually we combine several roles:
- backend developers (Java/Spring) developing microservices and domain logic,
- frontend developers (React/Angular) owning the interfaces,
- C++ engineers where performance matters,
- DevOps / cloud engineers running containerisation, Kubernetes, Terraform and CI/CD,
- QA engineers building test automation,
- data specialists maintaining the ETL/ELT processes.
We don’t staff all of these just in case - we bring in the roles the project actually needs.
How do we do it at RITS?
We do it as a nearshore partner from Poland, with real experience in transport and travel tech. For an aviation and travel technology provider we develop, maintain and cloud-migrate its applications: we add new features to existing systems, keep them running and run cloud-to-cloud migrations to GCP.
Underneath runs a coherent stack: Java, Spring and microservices on the backend, React and Angular on the frontend, C++17 in performance-critical components, plus Docker, Kubernetes, Terraform and Jenkins in the cloud layer and Selenium and REST Assured in test automation. A team like that treats development and maintenance as one job, so the platform grows instead of crumbling.
Where to start with transport app development and migration?
Start with an honest map of what you have: which systems bring value, where technical debt sits and what blocks you from adding new features. Only that tells you whether development, maintenance or a cloud migration is the more urgent move - and which skills you need. We covered the differences between engagement models in our article on IT engagement models.
Building, maintaining or cloud-migrating transport applications? Let’s talk - we’ll match a team and a stack to your system.