Overview

Before Synedrus, I led the technical delivery of a payment integration project facing a hard external deadline. A major bank had announced it would deprecate ABA over SFTP—a legacy file transfer process still in use by the business. We had six weeks to deliver a replacement system: collecting transaction data, forwarding it to a third-party payments partner and handling asynchronous status updates as transactions progressed through the payment pipeline.

The initial architecture was provided by a solutions architect. As a technical lead, I was responsible for steering delivery, adapting the design to infrastructure realities and course-correcting technical decisions that would have blocked deployment or introduced long-term pain.

Challenge

• Non-negotiable six-week deadline imposed by the bank sunsetting support for the ABA SFTP protocol.
• The original design proposed modifying a large, legacy API with manual release windows long outside office hours and no safe path for soft releases or rapid testing.
• CI/CD principles were compromised by the legacy approach, threatening long-term maintainability and testability.
• Testing occurred under extreme pressure, often using production-like data hours before go-live due to environment constraints.

Solution

Architectural course-correction

Built a dedicated miniservice to pull eligible transactions instead of modifying the legacy API. This allowed for:

• Independent deployment via continuous integration and delivery
• Continuous delivery and soft rollout
• Lower blast radius and better observability

Redesigned feedback loop with a third party transaction processor

Replaced the original callback model (waiting for the third-party service to POST status updates) with a polling model where we periodically retrieved statuses ourselves.

• This gave us better control, retry logic and scheduling certainty
• Reduced reliance on perfect third-party timing
• Integrated the polling logic into one of the newly-created services to meet the tight deadline.

Pre-Go-Live Firefighting

Hours before go-live, we uncovered a critical data issue that would have stopped the release. I worked with the team to apply a rapid, low-risk fix that allowed us to proceed with only a minor delay, thus keeping the deployment on track for the hard deadline.

Post-Go-Live Triage

Certain concurrency issues were detected. The conditions were identified and after analysing the sequence of operations and confirming that concurrency windows were small and safely staggered in production, I greenlit the decision to disable parallelism.

Results

• Met external hard deadline. Integration completed before the bank deprecated the ABA process.
• Avoided go-live disaster. Identified showstopper errors hours before launch and shipped corrective code under pressure.
• Maintained CI/CD integrity. Avoided regression into manual release windows by isolating risky changes into a service that could be deployed independently.
• Shipped in stages. Deployment was broken down into components, released iteratively, reducing blast radius and enabling quicker triage.
• Kept the business operational. At no point did client transactions fail at scale. Delays and retries were handled without incident escalation.

Positioning Takeaway

When the integration deadline is fixed, the upstream system is brittle and your downstream partner has tight expectations, you can’t afford delays or theory. I step in to isolate architectural risks, keep the release pipeline unblocked and ship real outcomes.

Details in this case study are based on my experience as a full-time employee at a previous role. All technical and business context is anonymised and does not represent any official statement from the parties involved. All views and technical decisions described are my own and do not necessarily reflect the official position of my employer at the time.