Putting a stalled booking journey into production

Starting point

A distributor wanted to offer transport bookings within its own customer journey. Initial software had been started around a third-party booking platform but had never reached production.

Most code sat in one main file, with little separation between the interface, API calls and business rules. Every fix could break something else. The project looked visually close to completion, but it was neither maintainable nor reliably deployable.

Clarification

The transport platform was a service integrated into the project. It was not our client. The contracting organisation remains anonymous.

Risks identified

• API calls that were hard to isolate and test;
• insufficient error handling for a booking journey;
• tightly coupled code;
• no repeatable deployment procedure;
• uncertain behaviour when the supplier was unavailable;
• poor visibility into what was actually complete.

Our method

Audit before changes

We reviewed the full journey, inventoried external calls and separated production blockers from improvements that could wait.

Targeted refactoring

Code was separated by responsibility: supplier access, booking rules, presentation and error handling. The aim was not an ideal rewrite, but verifiable change.

Securing the journey

Incomplete responses, timeouts and third-party errors were handled explicitly. Diagnostic data was logged without exposing sensitive information.

Production preparation

Configuration, secrets and deployment steps were removed from the developer’s workstation. We defined release and verification procedures, then monitored the run after deployment.

Outcome

The client recovered a structured codebase, a deployable booking journey and a way to investigate integration errors. The project moved from unfinished development into production and maintenance.

We do not publish booking volumes, conversion rates or contractual availability because those details were not approved.

Lesson

A project blocked a few weeks before launch is not necessarily “almost finished”. External calls, failure handling and deployment are part of the product.

Our project recovery service starts by identifying what can be kept. An IT assessment then supports the decision between correction, targeted refactoring and replacement.