How do I integrate my mobile app with existing business systems?

Building a mobile app is rarely just a build. The moment you start mapping what the app needs to do, you find it cannot do most of it alone. It needs to talk to your stock system, your booking engine, your payment processor, your customer database, or some combination of all four. And the moment you start asking how those connections will work, you discover that the systems on the other side have their own opinions about that.

The connections between systems cause more project delays than the features themselves.

Integration is where the majority of mobile projects run into trouble, and it happens so predictably that we have come to treat it as a structural part of the challenge rather than a variable. The complexity is not always technical. Sometimes it is organisational: the team managing the third-party system does not prioritise your requests. Sometimes it is contractual: you need API access you were never going to be granted. Sometimes it is architectural: the existing system was built in a way that makes clean integration genuinely impossible.

What follows is drawn from direct experience across a range of products, from drinks trading platforms to film industry management tools to toll payment apps. The patterns repeat, and the lessons are transferable. If you are planning a mobile product that needs to connect to anything outside itself, this is what you need to know before you start.

What business systems does your app actually need to connect to?

The first question to answer, clearly and completely, is which systems your app genuinely needs to connect to in order to function. Not every data source that would be nice to have, but the ones without which the core experience falls apart.

For a wellness brand, that might be a fulfilment system for orders and a loyalty database for personalisation. For a hospitality product, it could be a property management system, a booking engine, and a payment gateway. For a food and drink platform, it might include an inventory system, a supplier catalogue, and an age verification service. The list looks different in every case, but the underlying logic is the same: map the data flows before you map the features.

Start with what moves data, not what looks good

A useful exercise is to walk through every action a user takes in the app and ask where the data for that action comes from, and where it goes when the action is complete. Signing in pulls from an authentication service. Browsing products pulls from a catalogue. Placing an order writes to an order management system and triggers a payment. Each of those connections is an integration, and each one carries its own complexity, timeline, and dependency on a third party.

Separate the essential from the desirable

Once you have listed every integration, separate the ones that block the core experience from the ones that would add value but are not required for launch. That distinction shapes your build plan significantly, and we will return to it later.

Why integration planning belongs at the start, not the end

Integration is frequently treated as a late-stage concern, something to sort out once the features are designed and the build is underway. That order of operations creates serious risk. By the time you discover that a system cannot be connected the way you planned, you have already built around an assumption that no longer holds.

The right time to investigate your integrations is before the first line of code is written. That means reaching out to the teams managing the external systems, requesting API documentation, and, where possible, getting access to a test environment. It also means asking hard questions: does an API exist? Is it documented? Is it actively maintained? Who owns access, and how long will it take to get credentials?

These questions feel administrative, but the answers are architectural. If the system you planned to connect to does not have a usable API, the whole approach changes. If access requires a commercial agreement with a third party, that affects your timeline. If the API exists but is poorly documented, that affects your budget, because your developers will spend time reverse-engineering behaviour that should have been specified up front.

According to Salesforce's Connectivity Report 2023, 80% of IT leaders say integration challenges are slowing their digital transformation efforts, causing data silos and disconnected departments. That figure reflects what happens when integration is an afterthought.

What can go wrong when you assume access you do not have

The most common and most costly mistake in integration planning is treating access as a given. A system exists, the data is in it, and the assumption is that connecting to it will be a matter of writing the right code. In practice, access is a negotiation, and the negotiation does not always go your way.

We encountered this directly on a production management product for the motion picture industry. The plan was to integrate with the platforms already used by productions to store documents, and to ingest data via email integrations. When we finally gained access to those systems, we found they were far more locked down than anticipated. The access we needed simply was not available.

Assumed API access is one of the most common reasons a build has to change course mid-project.

We had to pivot. Rather than a direct API integration, we built an alternative approach: ingesting emails tied to specific roles within a production to process data indirectly. The core function was preserved, but the route to it was entirely different from the one we had planned. The biggest challenge throughout was making sure that alternative approach did not feel like an extra step to users. The value of the integration was supposed to be seamless data pulling, so we had to find a solution that felt largely invisible, even without a direct API connection.

This is not an edge case. Security restrictions, commercial agreements that limit data sharing, and legacy systems with no API layer at all are routine obstacles. The time to discover them is during scoping, not during build.

Before scoping your build, request API documentation and test credentials from every external system you plan to connect to. If neither is available within two weeks of asking, treat the integration as at risk and start planning an alternative.

When the third-party system itself is the problem

Sometimes the barrier is not access but architecture. The system you need to connect to exists, is accessible in principle, and the team managing it is willing to help. But the way it was built makes clean integration genuinely difficult or impossible.

We ran into this on a buying and selling platform for bottles of alcohol, similar to a wine trading exchange. We had already started building the mobile product when we discovered that the client's existing web application had been built by a third-party developer in a way that made it too complex to expose cleanly via an API. The coupling was too tight. Getting the data out in a structured, reliable form was not feasible within the project's constraints.

The solution we landed on was to embed web elements from the existing site directly into the mobile product. It worked, and the client could launch, but it was not the solution we would have chosen. The result was a product that was less scalable and less robust than it should have been, because the underlying architecture of the web application forced our hand. That constraint added approximately 20% uplift in work across the entire length of the project. Because the client wanted to maintain the original budget, features had to be dropped towards the end of the build to compensate.

When you inherit a system built by someone else, it is worth getting a technical review of its architecture before you commit to an integration approach. What looks like a straightforward connection from the outside can conceal significant structural problems on the inside.

If a third-party system was built by an external developer, ask for an architectural overview before you agree to integrate with it. A brief technical review at the start is far cheaper than discovering a structural problem halfway through the build.

Changing suppliers mid-build and what it costs you

Integration plans that seem settled at the start of a project can change, and when they do, the cost is rarely small. On a travel product, we integrated with a third-party aggregator at the client's request. Midway through development, the client concluded that the fees the aggregator added made the product's financial model unworkable. They switched to a different supplier.

The new supplier used a fundamentally different API approach. That meant going back to the drawing board and re-engineering significant portions of the integration layer. Then, later in the same project, the client added a third external service to handle a specific category of bookings, which required yet another round of integration work. Each change meant careful review, rewriting of integration code, and re-testing for robustness and security.

The lesson is not that supplier changes are always avoidable. Commercial decisions change, and sometimes a switch is the right call. But the cost of making that switch mid-build needs to be understood before the decision is made. Re-engineering an integration layer is not a small task. It can affect timeline, budget, and the stability of everything built around it.

If you are evaluating suppliers during a build, treat the API approach each one uses as a first-order consideration alongside pricing. A cheaper aggregator that uses a radically different data model might cost you more in engineering than the fee difference saves. That trade-off needs to be visible when the commercial decision is made.

Working around integrations that are not technically feasible

Not every integration problem has a clean technical solution. Sometimes the honest answer is that a direct connection is not possible, and the product needs to find another way to achieve the same outcome.

On a toll management platform, we discovered during development that there was no coherent or consistent API across toll providers. Each provider operated differently: some accepted cash, some card, fees varied by vehicle axle count or flat rate. Direct integration was not viable. The workaround we built was to set up corporate accounts with each toll provider, register customer vehicle plates to those accounts, and have customers preload credit onto the platform. Tolls were deducted after the fact from those preloaded balances, rather than processed in real time through each provider's system.

This eliminated the need for real-time integration entirely. The product could launch without depending on cooperation from individual toll operators, and the user experience was clean enough that the underlying complexity was invisible. We also made the case to the client that a brand-new, unproven product would struggle to negotiate API access with established incumbents, and that the smarter approach was to launch using the preloaded model first and pursue formal API relationships later, once the platform had built credibility. The client accepted that staged approach.

A workaround that serves the user well and allows the product to launch is often preferable to blocking the build on an integration that may never be available.

How to write the specification when the other party will not

One of the more frustrating integration challenges is organisational. You need to connect to a system managed by another team or another company, and getting clear information about how that system works takes longer than building the feature itself.

On the alcohol trading platform, we inherited a tightly coupled web product built by a third-party developer, with no API layer exposed. When we needed to connect different parts of the system, getting timely responses from that developer about how to access data became a significant blocker. The project was stalling not because the engineering was hard but because the other party was not moving.

Rather than continuing to wait, we took the lead. We wrote the API specification ourselves, based on what we knew the app needed, and worked to that spec. The third-party developer then implemented it. Taking ownership of the specification broke the deadlock and allowed the project to move forward.

This approach works because it shifts the burden from the other party defining what is possible to you defining what you need. A well-written spec gives a reluctant or slow-moving team something concrete to respond to, rather than an open-ended request that is easy to defer. It also gives you a document to hold them to, which matters if timelines start slipping.

If an external team is slow to provide API documentation, write the specification yourself based on what your app needs and share it with them. A concrete document is harder to ignore than an ongoing conversation, and it gives you something to track progress against.

When skipping real-time integration is the right call

Real-time integration is the goal in most cases, but it is not always necessary, and sometimes it is the wrong approach entirely. The question to ask is whether the user experience actually requires data to be live at the moment of request, or whether a slightly different model would serve them just as well with considerably less complexity.

On the performance coaching survey app, 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 record, whilst keeping the build lean and appropriate for a proof of concept.

The approach suited the use case precisely because of its constraints, not despite them. We had also recommended against requiring audience members to download a native app for what was a simple touchpoint. A QR code approach, where scanning took users to a fully branded and mobile-responsive web page, removed the friction of an app store download and produced significantly higher completion rates.

The toll management platform used a similar logic: rather than real-time payment processing through each toll operator's system, funds were deducted after the fact from preloaded balances. The user saw a clean, immediate experience. The complexity happened in the background, on a delay that the product could manage.

Choosing the right third-party service before you commit to it

The choice of which third-party service to build your integration around is not always obvious, and the obvious choice is not always the right one. API quality, user experience implications, commercial terms, and the downstream opportunities a service creates all factor in.

On a proof-of-concept project for a product built around sharing memories with audio attached, we initially looked at integrating with Spotify for short audio clips. The problem was that Spotify lacked a robust API for clips, and users would have needed a Spotify account, which added friction to an experience that needed to feel immediate. We switched to Deezer. Its API was robust, it supported clips natively, and it did not require users to be logged in.

The switch opened up more than we expected. Users could search a catalogue larger than Spotify's and attach clips within the app. And when a user wanted to hear a full track, there was a natural path to a Deezer subscription, which created affiliate referral revenue as a secondary income stream alongside the product. A service that initially looked like a second choice turned out to deliver more commercial value than the first.

The practical checklist before committing to a third-party service is worth being explicit about. Ask whether the API is documented and actively maintained, whether access requires users to hold accounts with the service, what the commercial terms look like at scale, and whether the service creates any downstream opportunities the alternative does not.

How integration constraints affect features, budget, and scope

Integration constraints do not stay in the integration layer. They ripple outward into features, timelines, and budgets in ways that are difficult to predict unless you have been through it before.

The alcohol trading platform is the clearest example. Embedding web elements from the existing site instead of building a clean API layer added approximately 20% uplift in work across the entire project. The client wanted to hold the original budget, which meant features were dropped towards the end of the build to compensate. The integration problem became a product problem: users got a smaller product than was planned because of an architectural constraint that was only discovered mid-build.

The same dynamic appears in less obvious ways. On the baby monitor product, where the client was building both physical hardware and a companion app, the integration between the two was far more complex than the original Bluetooth approach had suggested. We ended up defining a formal software-hardware contract that specified exactly how the app would communicate with the device, covering turning things on and off, retrieving sensor data, and accessing camera feeds, all in a format the app could consume. That specification work was not in the original scope, but it was necessary before any reliable build could happen.

The table below shows how different integration scenarios typically affect the three main project variables.

Staging your integrations: what to launch with and what to defer

Not every integration needs to be live on day one. Deciding which connections are required for the core experience and which can follow in a later release is one of the most practical ways to manage integration risk without compromising the product.

The toll management project illustrated this well. Rather than blocking launch on API agreements with individual toll operators, which would have required a level of commercial credibility the product did not yet have, we launched with the preloaded credit model and planned for formal API integrations to follow once the platform had established itself. The staged approach let the product reach users and begin building the track record it needed to negotiate from a stronger position.

A practical way to stage integrations is to sort them against two dimensions: how central is this to the core user journey, and how complex is it to build. Integrations that are central and relatively straightforward go in version one. Integrations that are central but complex need either a workaround for launch or they push the launch date, and that decision needs to be made explicitly. Integrations that add value but are not core can be deferred.

1. List every integration the app requires to function at a basic level.
2. Identify which of those has a viable workaround if the ideal connection is not available at launch.
3. Assess the complexity and third-party dependency of each remaining integration.
4. Assign each one to a release: launch, first update, or future roadmap.
5. Build the launch list first and treat the rest as planned scope, not future maybes.

This is about being honest about what the product needs on day one versus what it needs to grow, and not letting the second category delay the first.

Conclusion

Integration is a structural question that shapes what the product can be, what it will cost to build, and when it will be ready to launch. Every project we have described here was affected by integration decisions made too late, access assumed rather than confirmed, or a third-party system that turned out to behave differently from what was expected.

The through-line across all of it is the same: the earlier you investigate your integrations, the more options you have. Discover a system is locked down before you build around it and you can plan an alternative. Discover it after and you are paying to undo work that should not have been done. Choose a third-party service before you understand its API and you may find yourself switching mid-build, re-engineering work that was already complete.

There are also cases where the right answer is to avoid a direct integration entirely, at least for now. The toll platform launched successfully without real-time API connections to a single toll operator. The performance coaching app served its users well without a traditional backend. Both products reached their users on time, and both left room to build more sophisticated integrations once the platform had the credibility to negotiate them.

If you are planning a mobile product and have not yet mapped your integration dependencies, that is the conversation to start now, before the build begins and while there is still room to make choices rather than just manage consequences. Let's talk about your app and what it needs to connect to.

Frequently Asked Questions