How can you validate new tech integration in your app?

Partway through building a travel product with us, a client decided that the third-party aggregator they had chosen was adding too much cost to make the financial model work. So they switched suppliers. The new supplier used a fundamentally different API approach, which meant we had to go back to the drawing board and re-engineer significant portions of the integration layer. Then, later in the build, the client added a third external service to handle specific bookings, which required yet another round of integration work. Each change needed careful review, rewriting of integration code, and a full check on robustness and security.

Treating integration as an implementation detail rather than a strategic decision is where projects unravel.

That project is a clear illustration of what happens when integration decisions are treated as implementation details rather than strategic ones. The question of which supplier to use, which API approach to adopt, and whether the integration is even technically feasible given the existing codebase, these are questions to answer before the build starts.

Validating a new tech integration before committing to a full build is one of the most reliable ways to protect both budget and timeline. This article sets out what that validation process looks like in practice, when to do it, and what the real costs are of leaving it too late.

What does validating a tech integration actually mean?

Validation, in this context, means confirming that a planned technical integration is actually achievable before you spend meaningful budget building around it. That covers several things: whether the third-party service offers the API access you need, whether your existing codebase can support the integration cleanly, whether the security model is manageable without introducing unacceptable risk, and whether the overall approach will hold up at the scale you are planning for.

Developers often distinguish between API development (building an API from scratch) and API integration (connecting to one that already exists). These are very different scopes of work, and conflating them can cause a project budget to be significantly underestimated. Validation surfaces that distinction early, before contracts are signed and timelines are set.

What validation is not is a full QA process. You are not testing a finished product. You are running enough of a technical investigation to make an informed decision about whether to proceed with the planned approach, and if so, what the realistic constraints are. A proof of concept, a small spike, a prototype, or a careful review of the supplier's API documentation can all count as validation, depending on what the risk is and how much uncertainty exists.

Why integration validation is a strategic decision, not a QA step

QA happens at the end of a build. Validation happens before it. The difference matters because decisions made at the start of a project shape everything that follows: the architecture, the supplier relationships, the timeline, the budget reserves, and the team's ability to iterate later. Treating validation as something the development team handles internally, without involving product owners or business stakeholders, means those downstream effects stay invisible until they become problems.

The travel product we worked on is a good example of this. The switch from one aggregator to another was a business decision, driven by cost. But the technical consequences of that decision, specifically the need to re-engineer the integration layer, fell entirely on the build. If the financial implications of the original aggregator had been validated earlier alongside the technical ones, the switch might have happened before development started rather than midway through it.

Integration validation is also where you discover architectural constraints that the initial brief did not account for. Those constraints can change the approach entirely, and finding them early is far less costly than finding them late.

When to validate: the cost of leaving it too late

The right time to validate an integration is during discovery, before the main build begins. The wrong time is partway through development, when significant work has already been done on the assumption that the planned approach will hold.

On a dating app project we worked on, the client chose to skip discovery for the messaging component and focus purely on onboarding. The result was a generic messaging feature that contradicted the core product premise: it allowed automated and fake messages, undermining all the verification work done during onboarding. The mismatch required a full rewrite of the messaging section, which cost approximately £15,000 in additional budget and two months of extra work.

That figure is worth holding on to. The rewrite was not caused by poor engineering. It was caused by a decision made at the brief stage to bypass the investigation that would have caught the conflict early.

Skipping discovery on a single feature cost £15,000 and two months, not because of poor engineering but because of a decision made at the brief stage.

The same pattern applies to integrations. If you discover that a supplier's API does not support a key function you have been building toward, the cost of that discovery rises sharply the later it arrives. Software products can cost significantly more to fix after launch than during development, which is why front-loading the investigative work is the more rational use of budget, not the more cautious one.

Run a short technical spike on any integration that is central to the product's core function. A day or two of investigation at brief stage is far cheaper than a rewrite six weeks into a build.

How switching suppliers mid-build compounds the problem

On the travel product, the original aggregator was chosen early and built around. When the client decided its cost structure made the product unviable, the switch to a different supplier was the right business call. But because the new supplier used a fundamentally different API approach, the integration work already completed was largely unusable. We had to re-engineer significant portions of the integration layer from scratch.

Then a third external service was added to handle specific bookings. Each new supplier brought its own API structure, its own authentication requirements, and its own edge cases to account for. Each addition required a careful review, rewriting of integration code, and verification that the updated system was still robust and secure.

The compounding effect here is real. Switching once is disruptive. Switching twice, or adding a third service on top of a system not designed to accommodate it, creates a layered complexity that is genuinely hard to manage. The architecture starts to reflect the history of decisions rather than a coherent design.

The lesson from that project is that supplier validation needs to include a financial assessment alongside the technical one. If the supplier's cost model makes the product unviable, that is just as disqualifying as a missing API endpoint, and it is much better to discover it before the build starts.

What happens when an existing codebase blocks your planned approach

On a buying and selling platform for bottles of alcohol, we had already started building the mobile product when we discovered we could not implement the planned API layer. The client's existing web application had been built by another developer in a way that made it too complex to expose cleanly via an API. We ended up having to embed web elements from the existing site directly into the mobile product instead.

The final solution worked, but it was not as scalable or robust as a clean API integration would have been. That was a constraint we were limited to, and the client needed to understand what it meant for future development: any significant expansion of the mobile product would be working against the architecture rather than with it.

Applying a new interaction or design layer on top of existing code is possible, but it requires very careful management. When a detailed design is handed to developers working with a functional existing codebase, the gap between what the design assumes and what the code can support can create significant rework. We experienced a version of this on a wellness genetics product, where the handoff went through an intermediary designer, adding further distance between the original intent and the implementation.

Before designing for a new mobile experience that connects to an existing platform, audit the existing codebase first. Understanding what API access is genuinely available changes both the design scope and the budget estimate.

How to validate an integration before committing to a full build

The most direct approach is a technical spike: a short, time-boxed investigation where a developer connects to the supplier's API, tests the key endpoints you will depend on, and confirms that the data you need is actually accessible in the format you need it. This is targeted work, scoped precisely enough to answer the specific questions that carry the most risk.

Beyond the spike itself, validation should cover a small set of consistent questions.

1. Does the supplier's API expose the functionality the product requires, or only a subset of it?
2. Is the API well-documented, actively maintained, and versioned in a way that reduces future breakage risk?
3. What are the authentication requirements, and do they fit the security model you are planning?
4. Are there rate limits or usage costs that would affect the product's financial model at scale?
5. Does the existing codebase (if there is one) support a clean integration, or will workarounds be needed?

These questions are answerable before a line of production code is written. Getting answers to them is what validation means in practice. It does not require a prototype or a working demo. It requires enough technical investigation to make an informed decision rather than an optimistic assumption.

Testing integrations without complete infrastructure in place

Sometimes validation needs to happen before the full infrastructure exists. On a baby monitor project, we needed to test the software integration without access to real production hardware. To do this, we built a prototype that ran a web server from the device. This allowed us to connect to it, inspect its internals, verify that settings being applied were correctly reflected, and simultaneously control the device through the app, effectively simulating the full communication loop between the app and the hardware.

That approach gave us confidence in the integration before the hardware was finalised, which meant development could continue without waiting on a dependency outside our control.

A similar principle applied on the performance coaching survey app, where we used Firebase's real-time database as the backend for the MVP rather than building a traditional API. Each survey created by the presenter generated a record in Firebase, and audience members accessed their own unique response record via keys embedded in the QR code URL. This allowed real-time response logging with tight security, restricting users to reading and writing only their own response record, while keeping the build lean and appropriate for a proof of concept.

Both approaches reflect the same underlying principle: testing what you can test, with what you have, at the stage you are at. Waiting for perfect conditions before validating is itself a risk.

If production infrastructure is not ready, simulate what you need. A web server running from the device, a sandbox API, or a stub service can answer the questions that matter before the real environment exists.

Security and architectural trade-offs that surface during validation

Validation does not just tell you whether an integration is technically feasible. It also surfaces the trade-offs you will need to manage if you proceed. Security is one of the most consistent areas where these trade-offs appear.

On the performance coaching survey app, the biggest technical challenge was locking down Firebase security rules without a dedicated API layer. By making a deliberate early decision to skip a traditional API for the MVP, we had to scrutinise every security rule very carefully to ensure that neither the app nor the web response page could be exploited. With no API acting as a controlled intermediary between the client and the database, the security model had to be built into the database rules themselves, which required a different kind of rigour.

That was a known trade-off, made consciously in the context of an MVP. The risk is when trade-offs like this are not made consciously, because the validation work that would have surfaced them was skipped. According to a survey of 2,000 developers reported by Dark Reading (Veracode), only 52% of developers said they always consider security when evaluating a new third-party library, compared with 67% who said the same about functionality. Functionality tends to be tested first because it is more visible. Security gaps are often discovered later, and later is more expensive.

Architectural trade-offs follow a similar pattern. The decision to embed web elements in the alcohol trading platform rather than use a clean API was a constraint, but it was a documented one. Undocumented constraints discovered during a production build are far harder to manage.

Who should be involved in the validation decision?

Integration validation sits at the boundary between technical and commercial decisions, which means it needs input from both sides. A developer can confirm whether an API is technically accessible. Only someone with visibility of the product's financial model can confirm whether the supplier's cost structure is workable. Those two questions need to be answered together, not sequentially.

The travel project illustrated this clearly. The technical integration with the original aggregator was feasible. The commercial model was not. Those two pieces of information were held separately for too long, and the project paid for it.

Validation also needs a named owner. If nobody is accountable for completing it before the build starts, it tends to get absorbed into early development work and treated as something to figure out as you go. That is the pattern that produces mid-build rewrites and supplier switches.

Getting the right people in the room for a short validation review at the start of a project is one of the more straightforward ways to protect the budget that follows. It is a deliberate process.

Conclusion

The projects that run into the most expensive problems are rarely ones where the engineering was poor. They are ones where key questions were left unanswered too long. Which supplier, which API approach, whether the existing codebase supports the plan, whether the security model is manageable without an API layer, these are all questions with answers. The answers just need to be sought before the build commits to a direction.

On the travel product, the aggregator switch mid-build forced a re-engineering of the integration layer. On the dating app, skipping discovery on the messaging component cost £15,000 and two months. On the alcohol trading platform, a codebase that couldn't support a clean API meant the mobile product was built on a foundation that limited its future. These are real costs, attached to real decisions, and in each case the decision point came before the expensive consequence, not after it.

Validation does not require a long process or a large team. It requires the right questions, asked early enough that the answers can still change the approach. A short technical spike, a financial review of the supplier model, a codebase audit if there is an existing platform, these are bounded pieces of work that pay back quickly.

If you are planning a new integration and want to think through the approach before committing to a build, let's talk about your project.

Frequently Asked Questions