--- title: The Moment a Client Switched Suppliers Mid-Build and We Had to Rewrite the Travel Integration description: What happens when a supplier switch mid-build forces a travel integration rewrite, and how to audit aggregator assumptions before development starts. image: https://weareaffective.com/hubfs/learning-centre-images/the-moment-a-client-switched-suppliers-mid-build-and-we-had-to-rewrite-the-travel-integration.webp --- [Skip to content](https://weareaffective.com/learning-centre/the-moment-a-client-switched-suppliers-mid-build-and-we-had-to-rewrite-the-trave#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # The Moment a Client Switched Suppliers Mid-Build and We Had to Rewrite the Travel Integration Table of Contents Partway through building an OTA travel product, the client told us they were switching suppliers. Not before development started. Not at the planning stage. Midway through, when significant portions of the integration layer were already written and tested against the first aggregator's API. The decision made commercial sense on their side, the aggregator's added costs were making the financial model unworkable, but it landed on us as a full re-engineering job, and there was no way around it. > Each supplier switch meant re-engineering the integration layer from scratch, not just swapping one connection for another. The new supplier used a fundamentally different API approach. The patterns we had built against, the data structures we had mapped, the flows we had designed around, all of it had to go back to the drawing board. Then, later in the same build, the client added a third external service to handle a specific category of bookings, which opened another round of integration work on top of the rebuild we had just completed. What this project taught us, and what we want to be honest about, is that some of the pain was avoidable. Not the supplier switch itself; that was a commercial decision the client had every right to make. But the assumptions that made the switch so costly, the things nobody had tested before build began, those were findable earlier. This article is an account of what happened, what it cost, and what we now look for before a line of integration code gets written. ## What the Travel Product Was Built to Do The product was an [online travel agency platform covering](https://weareaffective.com/app-development) a fairly broad scope: accommodation, flights, transfers, and extras, all within a single booking journey. Users needed to move through a checkout that touched multiple third-party providers, entering traveller details, passport numbers, room preferences, and payment information across what was genuinely one of the more complex booking flows we had worked on. One of the design problems we were solving was [drop-off. We found users were entering](https://weareaffective.com/learning-centre/what-a-travel-ota-learned-by-distributing-the-booking-form-across-the-whole-grou) information partway through and abandoning the process. To address this, we redesigned the progress indicator to be interactive rather than decorative, users could jump between sections, see an estimated time per section, and view an overall time estimate for the whole booking. That gave a much more navigable view of the journey and reduced the sense that completion was somewhere unknowably far ahead. The product also had to handle group bookings, which added another layer. [Distributing data entry across individual travellers](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) in a group works well for friendship groups and colleagues, where the burden can be shared voluntarily. For family bookings, where a parent is responsible for their children's details, that model does not apply in the same way. So the design kept manual entry available as the default, with collaborative entry as an opt-in for groups where it made sense. Across all of this, the product depended heavily on third-party data. Which is where the supplier question became central. ## Why the Client Chose the First Aggregator The client came in with the first aggregator already identified. From their perspective, it was the obvious choice, an established travel data provider with broad inventory coverage, a documented API, and enough market presence that the decision felt low-risk. The commercial terms had been discussed in outline. The relationship felt settled. What had not been worked through in detail was the cost model. Aggregators in travel do not simply provide data access. They add fees on top of underlying inventory prices, and those fees are not always visible until you run the numbers across a realistic transaction volume. The client had assessed the aggregator's capability. They had not fully stress-tested what it would cost per booking at the scale they were targeting. So build started. We integrated against the first aggregator's API, mapping their data structures into our flows, writing the code that connected their inventory to the product's checkout. That work was real and it was completed. The decision to switch came after it was done. The lesson is not that aggregators are the wrong choice. For many travel products they are exactly right. The lesson is that the [cost model needs to be fully tested](https://weareaffective.com/learning-centre/how-to-structure-a-pre-build-budget-that-accounts-for-the-cost-of-being-wrong) against projected transaction volume before integration work begins, not discovered once the build is already committed to a particular provider's architecture. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Assumptions Nobody Had Tested Every integration project carries assumptions. The question is when they get tested. On this project, several went into build untested and each one cost time when it eventually surfaced. The first was the cost assumption: that the aggregator's commercial model was workable at the client's target volume. As described above, that assumption was wrong, and discovering it mid-build triggered the supplier switch. The second was architectural: that switching from one aggregator to another would be a contained piece of work. It was not. Different suppliers structure their APIs differently. The data shapes are different, the authentication approaches differ, the way errors are returned and handled differs. Rebuilding against a new API is a re-engineering job. The third was scope: that two providers would be enough. A third was added later for a specific booking category, and that meant another integration round on top of the first rebuild. This pattern appears elsewhere in our work. On a [production management product for the motion picture industry](https://weareaffective.com/learning-centre/what-film-industry-document-portal-users-taught-us-about-designing-for-people-wh), we expected to integrate directly with the platforms used to store production documents. When we finally gained access to those systems, we found them far more locked down than anticipated. We had to pivot to ingesting emails tied to specific roles within a production, processing data indirectly rather than through the direct API integration we had planned for. > Assumptions about API access and cost models need to be tested before integration work begins, not after it is done. The common thread is assumptions about third-party systems treated as facts. They look like facts because they came from a supplier's documentation or a preliminary conversation. But documentation describes capability, not necessarily what you will actually be granted access to, or at what cost, or under what conditions. ## When the Supplier Switch Happened Mid-Build When the client concluded the first aggregator's costs made the product's financial model unworkable, they moved to a different supplier. That decision was the right one for the product's commercial viability. But it arrived as a mid-build instruction, and it meant re-engineering significant portions of the integration layer we had already built. The new supplier used a fundamentally different API approach. Where the first aggregator had structured its data one way, the new one structured it differently. The flows we had built to handle search, availability, pricing, and booking confirmation all had to be revisited. The code was not salvageable in any meaningful sense, it had been written for a specific integration and the specific integration had changed. What this costs in practice is not just time on the re-engineering itself. It costs the time spent on review, on identifying exactly which parts of the existing code are affected, on rewriting those parts, on re-testing, and on ensuring that the security and robustness of the new integration meets the same standard as the original. Each of those steps takes time that had not been budgeted for, because the switch had not been anticipated when the project was scoped. Before committing to a supplier in any integration project, run the full cost model against realistic transaction volume and get a clear picture of API architecture from the provider directly, not just from documentation. We have seen a version of this on other projects too. On an alcohol buying and selling platform, being forced to embed web elements instead of building a proper API layer added approximately 20% uplift in work across the entire length of that project. Because the client wanted to keep the budget the same, features had to be dropped towards the end to compensate. A supplier constraint discovered late does not just add work. It usually removes something else. ## What Rebuilding the Integration Layer Actually Involved Rebuilding an integration layer is not glamorous work, and it is worth being specific about what it actually involves so the scope is clear. The first step is a thorough audit of everything already built against the old API: every endpoint being called, every data structure being mapped, every flow that depends on a particular response format. That audit produces a list of things that need to change, and the list is usually longer than expected because integrations tend to touch more of a product than is immediately obvious. Then the new API needs to be understood properly, which means reading documentation carefully but also building test calls and examining actual responses rather than documented ones. Documentation describes what a supplier intends. Real API responses reveal what they deliver, and there is often a gap. Once the new integration is written, it needs to be tested against the same scenarios the original was tested against, plus any new ones that the new supplier's behaviour introduces. Error handling needs particular attention, the way the new supplier signals problems, rate limits, and edge cases will differ from the old one, and those differences need to be caught and handled explicitly rather than left to surface in production. Throughout all of this, security needs to hold. Authentication, data handling, how credentials are stored and rotated, all of it needs review when a new external system is introduced, because the new system has its own security model and assumptions about how it will be called. When auditing a new supplier's API, test real responses rather than relying on documentation alone. Documented behaviour and actual behaviour often differ, particularly around error states and edge cases. ## The Third Provider and What It Cost to Add One More After the first rebuild was complete, the client identified a specific category of bookings that the second aggregator could not handle. The solution was a third external service, integrated alongside the existing two. That meant another round of the same process: audit, understand, write, test, security review. By this point in the project, the integration layer was supporting three different external services, each with its own API approach, its own authentication model, its own error handling, and its own data shapes. Keeping those three integrations coherent, ensuring that a booking that spans more than one of them behaves consistently for the user, that errors from any one of them are handled gracefully, that the overall system is maintainable, is significantly more complex than supporting one. The table below sets out roughly what each integration round involved and where the costs landed. | Integration round | Trigger | Primary cost | Secondary cost | | --- | --- | --- | --- | | First aggregator | Original build plan | Planned development time | None (expected work) | | Second aggregator | Supplier switch mid-build | Full re-engineering of integration layer | Re-testing, security review, flow redesign | | Third provider | Gap in second aggregator's coverage | Additional integration build | Ongoing complexity of three-provider maintenance | The third provider added less disruption than the supplier switch because it was additive rather than replacing something already built. But it still added work, and the cumulative effect of three integrations on a product that had originally been scoped around one was significant. ## The Same Problem on Other Projects The pattern of discovering a third-party constraint after build has started is not unique to this travel product. We have seen it across different types of projects and different categories of constraint. On a proof-of-concept project for a company building an app to share memories with audio attached, we initially looked at integrating with Spotify for short audio clips. Spotify lacked a robust API for clips, and users would have needed a Spotify account, which made the experience unnecessarily heavy. We switched to Deezer, which had a robust API, supported clips, and did not require users to be logged in. The switch was made early enough that it did not cost a rebuild, but the lesson held: the API capability assumption about Spotify was wrong, and testing it earlier than we did would have been better. On a [toll management platform project, we discovered](https://weareaffective.com/learning-centre/what-the-toll-management-project-taught-us-about-betting-a-product-on-an-api-tha) during development that there was no coherent or consistent API across toll providers. Each operator worked differently, different payment methods, different fee structures, different vehicle classifications. Direct integration was not viable. We set up corporate accounts with each toll provider, registered customer vehicle plates to those accounts, and had customers preload credit onto the platform. This eliminated the need for real-time integration entirely, but it was a significant architectural pivot that arrived during development rather than before it. On the same toll project, we had to make the case to the client that a brand-new, unproven product would struggle to negotiate API access with established operators, and that launching on the preloaded credit model and pursuing formal API integrations later, once the platform had credibility, was the smarter approach. The client accepted the staged approach. But the conversation about what API access would actually require had not happened until we were already in development. ## What Earlier Validation Would Have Caught Looking back at the travel product, three things would have changed the shape of the project if they had been established before integration work started. First, a full cost model stress-test against the first aggregator at realistic transaction volume. The commercial problem that triggered the supplier switch was discoverable at the planning stage. Running projected bookings through the aggregator's fee structure, at the scale the client was targeting, would have made the financial model problem visible before any code was written against that provider's API. Second, a [structured comparison of the shortlisted suppliers](https://weareaffective.com/learning-centre/how-to-structure-a-behavioural-risk-register-before-you-write-a-single-user-stor)' API architectures. Not documentation review, actual sandbox testing against both options. Understanding how each supplier structures their data, handles errors, and manages authentication before committing to one of them means that if a switch becomes necessary later, the team already understands what the alternative involves. Third, an honest conversation about whether a third provider was likely. If the client's booking categories were broad enough that one aggregator might not cover them, that possibility was worth naming at the outset. Designing the integration layer with the possibility of multiple providers in mind from the start is a different architectural decision than designing for one and then adding more under pressure. According to [arXiv, 2007](https://arxiv.org/abs/2007.01761), 78% of requirements-related rework traced back to avoidable gaps in shared understanding between stakeholders and development teams. The supplier assumptions on this project fit that category exactly, they were shared understandings that turned out to be wrong, and the cost of correcting them landed in the build phase rather than the planning phase. ## How to Audit Supplier Assumptions Before Build Begins Based on this project and others like it, we now treat supplier validation as a distinct piece of work before integration build starts. It does not need to be long, but it needs to cover specific ground. #### What to test before committing to a provider 1. Run the full cost model at realistic transaction volume, not just the headline rate. Aggregator fees often compound in ways that are not visible from the top-level commercial terms. 2. Test the API in sandbox against real use cases, search, availability, booking, error states, and compare actual responses to documented ones. Gaps between the two are common and worth finding early. 3. Assess what happens if this provider needs to be replaced. How different is the next best option's API architecture? If the answer is "very different", that is a risk worth naming explicitly. 4. Identify whether the product's booking scope is fully covered by this provider, or whether edge cases exist that a different service would need to handle. Name those cases before build, not during it. 5. Confirm access levels directly, not through documentation. What the API says it supports and what you will actually be granted access to are sometimes different things, as we found on the motion picture production management project when systems turned out to be far more locked down than anticipated. #### How to structure the conversation with a client The supplier validation conversation is sometimes uncomfortable because clients arrive with a provider already chosen and a relationship already forming. But the discomfort of that conversation is small compared to the cost of a mid-build switch. Being clear that the chosen provider needs to be tested against the product's actual requirements, and that the testing needs to happen before integration code is written, is part of the work. Treat supplier selection as a design decision, not a procurement one. The API architecture a supplier uses shapes the product's integration layer in ways that are genuinely difficult to reverse once build has started. ## Conclusion The travel product we built eventually reached a solid integration layer. The three providers were connected, the flows were robust, and the booking journey worked as intended. But the path to getting there was longer and more expensive than it needed to be, and the reason was assumptions about third-party suppliers that were treated as settled before they were actually tested. The supplier switch mid-build was a commercial decision, and the client was right to make it. The cost of continuing with an aggregator that made the financial model unworkable would have been higher than the cost of re-engineering. What we carry from this project is not a caution against supplier switches, but a clearer picture of what needs to be established before a supplier is committed to in the first place. Cost models tested at realistic volume. API architectures understood through sandbox testing, not just documentation. A clear view of whether edge cases exist that the primary provider cannot handle. An honest assessment of what a switch would actually involve. These are not complex things to establish. They require time and rigour at the planning stage, but they are findable, and finding them early is substantially cheaper than finding them in the middle of a build. If you are building a travel product, or any platform that depends on third-party data providers, and you want to work through supplier assumptions before integration begins, [let's talk about your integration planning](https://weareaffective.com/get-started). ## Frequently Asked Questions What caused the supplier switch mid-build, and was it avoidable? The client switched suppliers because the original aggregator's costs were making their financial model unworkable, which was a legitimate commercial decision. The switch itself was not avoidable, but some of the assumptions baked into the early build were never properly tested, and those could have been caught before development began. Why was switching suppliers so costly once development was already underway? The new supplier used a fundamentally different API approach, meaning the data structures, integration patterns, and flows already built had to be completely redone rather than simply updated. Each supplier change required a full re-engineering of the integration layer, not a straightforward swap of one connection for another. What kind of travel product was being built, and how complex was the booking flow? The product was an online travel agency platform covering accommodation, flights, transfers, and extras, all within a single booking journey. Users were required to enter traveller details, passport numbers, room preferences, and payment information across what was one of the more complex checkout flows the team had worked on. How did the team tackle the problem of users abandoning the booking process partway through? The team redesigned the progress indicator to be interactive rather than decorative, allowing users to jump between sections and see estimated completion times per section as well as for the overall booking. This gave users a clearer sense of where they were in the journey and reduced the feeling that the end was impossibly far away. How were group bookings handled differently from individual bookings? The product kept manual data entry as the default, with collaborative entry available as an opt-in for groups where sharing the burden made sense. For family bookings, where a parent is responsible for entering children's details, the collaborative model did not apply in the same way, so the design accounted for both scenarios. What assumptions made the supplier switch more damaging than it needed to be? Certain things about the original aggregator's API and data structures were assumed to be stable without being thoroughly tested before build began. Had the team examined these assumptions earlier, the cost of switching could have been reduced, even if the switch itself was always going to create significant rework. What does the team now look for before writing any integration code? The experience led the team to identify specific things worth investigating before a single line of integration code is written, particularly around supplier API stability and how tightly the early architecture is bound to one provider's approach. The article was written partly to be honest about what was missed and what the team now treats as non-negotiable to check upfront. What happened after the main supplier switch was completed? Later in the same build, the client added a third external service to handle a specific category of bookings, which opened another round of integration work on top of the rebuild already completed. This compounded the engineering effort and extended the complexity of an already disrupted project. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.