--- title: Can My App Integrate With My Existing Business Systems? description: Learn how business app integration with existing systems works, what can go wrong, and the key questions to ask before development begins. image: https://weareaffective.com/hubfs/learning-centre-images/can-my-app-integrate-with-my-existing-business-systems.webp --- [Skip to content](https://weareaffective.com/learning-centre/can-my-app-integrate-with-my-existing-business-systems#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 # Can My App Integrate With My Existing Business Systems? Table of Contents The question sounds simple. You have an existing business, a set of tools you already rely on, and an idea for an app. You want to know if the app can talk to those tools. The honest answer is: sometimes yes, sometimes no, and the difference between those two outcomes is almost always decided before a single line of code is written. > Integration decisions made late in a project do not stay contained, they reshape the whole product. We have worked on projects where integration with a third-party platform looked straightforward on paper and turned out to be blocked entirely once we gained access to the actual systems. We have worked on others where the original integration partner had to be swapped out mid-project because their API simply could not do what the brief required. And we have worked on projects where the client's existing product had been built by another developer in a way that made clean integration practically impossible, forcing a compromise that cost 20% more work across the entire build. Each of those situations was recoverable, but each one was also avoidable. The way to avoid them is to understand what integration actually involves, where it breaks down, and what your options are when it does. That is what this article covers. ## What 'Integration' Actually Means for a Business App When a client asks whether their app can integrate with their existing systems, they usually mean: can the app read data from, or write data to, a system they already use? That system might be a CRM, a booking platform, a payment processor, an inventory tool, or any number of other things. The mechanism that typically makes this possible is an API, which stands for Application Programming Interface. Think of it as a set of agreed rules for how two separate software systems can exchange information. Most established platforms expose an API specifically so that other products can connect to them. According to [Salesforce's Connectivity Report 2023](https://www.salesforce.com/news/stories/connectivity-report-2023/), 99% of organisations now report using APIs to integrate their applications and data. The infrastructure exists, and developers know how to use it. REST, the most widely used API format, is used by 93% of developers, according to [Postman's 2025 State of the API Report](https://www.postman.com/state-of-api/2025/). The complication is that not every system has an API, not every API is open to external developers, and not every API can actually do the specific thing your project needs. Integration is a spectrum of access, capability, and constraint that needs to be mapped before development begins. #### API integration vs. API development These are different things, and confusing them is one of the most common causes of budget shock. Integration means connecting to an API that already exists. Development means building one from scratch. The costs, timescales, and complexity are not remotely comparable, and treating them as interchangeable can cause a project estimate to be wrong by a factor of three to five, according to [Planeks](https://www.planeks.net/api-cost-calculator/). ## The Most Common Systems Apps Need to Connect With The systems a new app typically needs to connect with fall into a small number of categories, and knowing which category applies to your project shapes everything that follows. - CRM and customer data platforms, such as Salesforce, HubSpot, or a bespoke internal database - Payment processors and financial platforms, such as Stripe, PayPal, or a banking system - Booking and scheduling tools, such as calendar systems or property management platforms - Communication tools, such as email platforms, SMS gateways, or messaging services - Document and file storage platforms, such as cloud drives or industry-specific content repositories - Media and content services, such as streaming platforms, audio catalogues, or video libraries - Legacy or bespoke internal systems built before modern API standards existed Legacy systems are the category that causes the most difficulty. A platform built in the early 2000s may have no API at all, or one that is so old it uses standards modern developers rarely work with. Bespoke systems built by other developers are the next most common problem, particularly when those developers are no longer available or are unresponsive, and when the [codebase was never designed to be extended](https://weareaffective.com/learning-centre/how-do-you-protect-your-app-idea-when-working-with-remote-developers). The sector matters too. Film and television production, legal, and healthcare all carry unusually strict security and access controls around the platforms they use, which means integration access that would be straightforward in retail or hospitality can be entirely blocked in those environments. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Why Integration Must Be Decided Before Development Starts Discovering an integration problem halfway through a project is a structural setback. The [architecture of a mobile or web app](https://weareaffective.com/app-architecture-design-we-are-affective) is built around the data it expects to receive and the format it expects to receive it in. If the planned source of that data turns out to be inaccessible or structured differently, the work already done may need to be partially or fully redone. We have seen this play out in a concrete way on a buying and selling platform we built for the drinks industry, specifically for bottles of alcohol traded in a way similar to wine. 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 a previous 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. The final solution worked, but it was not as scalable as we would have liked, and the forced workaround added approximately 20% more work across the entire length of the project. Because the client wanted to hold the budget, features were dropped at the end to compensate. > Finding an integration blocker mid-build does not just slow things down, it changes the product you end up with. That 20% figure represents real features that users never got. Early integration planning does not just protect the budget. It protects the product. Before any design or development work begins, ask your technical team to confirm in writing whether each planned integration point has an accessible, documented API. If the answer is uncertain, that uncertainty needs to be resolved first, not later. ## What Happens When You Discover an API Does Not Exist Sometimes the system you want to connect with simply has no API. This is more common than people expect, particularly with legacy enterprise software, industry-specific platforms built before open-API standards became the norm, and internal tools built cheaply and quickly with no intention of ever being extended. When we worked on a [proof-of-concept project for a company](https://weareaffective.com/learning-centre/how-to-run-a-concept-test-that-doesnt-just-confirm-what-the-team-already-believe) building an app to share memories with audio attached, the original plan was to integrate with Spotify for short audio clips. The problem was that Spotify lacked a robust API for clips, and the integration would also have required users to have a Spotify account, which cut against the experience we were trying to build. We switched to Deezer, which had a robust API, supported clips natively, and crucially did not require users to be logged in. That meant users could search a catalogue larger than Spotify's and attach clips directly within the app. A further benefit was an affiliate revenue stream: when users wanted to hear a full track, there was a natural upsell to a Deezer subscription. The lesson from that project is that when an API does not exist, the question to ask is whether a different integration partner can serve the same purpose. The platform you originally planned for may not be the only one that solves the underlying problem. If your first-choice platform has no usable API for the feature you need, map the underlying requirement rather than the specific platform. A different service provider may meet the same user need while being technically straightforward to connect to. ## When the API Exists But You Cannot Access It A subtler and often more frustrating problem is discovering that an API exists but that you cannot actually use it for your project. This can happen for several reasons: the API requires a commercial agreement that takes months to negotiate, the platform operator restricts access to approved developers or approved use cases, or the security model of the platform makes the access you need simply unavailable. We ran into exactly this situation on a production management product we built for the motion picture industry. We initially expected to integrate directly with the platforms already used to store production documents, and to pull data in via email integrations. When we finally gained access to those systems, we found they were far more locked down than we had anticipated. The access we needed was not available. We had to pivot to a different approach, ingesting emails tied to specific roles within a production and processing [data that way, without a direct API](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) connection into the third-party platforms. The hardest part of that pivot was not the technical work. It was making sure the alternative approach did not feel like an unnecessary extra step to the people using it. The entire value of the integration was that data would arrive in the tool without users having to do anything differently. We had to find a solution that felt [largely invisible, even though the underlying](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) mechanism was completely different from what we had planned. ## Choosing a Different Integration Partner When your first-choice integration partner is either inaccessible or technically incapable, switching to a different one is sometimes the cleanest path. The memory app project illustrates this well: moving from Spotify to Deezer was not a compromise. Once we made the switch, the technical route actually became simpler. Working with Spotify without a proper API would have required significant workarounds and custom-built compliance solutions. Using Deezer's official API in the way Deezer intended meant we were fully compliant from the start, without any of those workarounds. The architecture was cleaner and the compliance burden was lower. That kind of switch is only possible, though, if the underlying need is genuinely platform-agnostic. Sometimes it is not. If your business operates in an industry where a specific platform is the de facto standard and your users expect the integration to be with that exact system, switching is not really an option. In those cases, the question becomes whether you can work around the access restrictions legally and in a way that still delivers the experience you need. #### What to evaluate when switching partners | Criterion | Original partner | Alternative partner | | --- | --- | --- | | API availability | Limited or restricted | Open and documented | | User account requirement | Required | Optional or none | | Compliance burden | High (workarounds needed) | Low (standard usage) | | Commercial agreement | Lengthy or blocked | Standard developer terms | ## The Hidden Cost of Late Integration Decisions The 20% work uplift we absorbed on the drinks platform project was a measurable cost. But there are less visible costs that are just as real. When integration architecture changes mid-project, the design already produced for one data structure may need to be reworked for a different one. Screens built assuming a clean API response may need to be rebuilt around embedded web views. Test plans written against one integration model become invalid against another. There is also the [cost of decisions made under pressure](https://weareaffective.com/learning-centre/how-to-structure-a-pre-build-budget-that-accounts-for-the-cost-of-being-wrong). When an integration problem surfaces late, the team is usually already running against a deadline and a budget. The options available at that point are narrower than the options that would have been available at the start. On the drinks platform, the right answer would have been to audit the existing web product's architecture before beginning mobile development, so the embedding workaround could have been scoped into the original build rather than discovered mid-stream and absorbed through feature cuts. Late integration decisions also affect the quality of what gets built. A workaround designed under time pressure is rarely as well thought-through as a solution designed from the start. Technical debt introduced at this stage has a way of accumulating, deferred problems rarely shrink on their own, and a product that launches with a fragile integration layer will eventually need a larger intervention than an incremental fix could have provided. ## Integration Without a Traditional API Not every integration requires an API in the conventional sense. There are situations where the data flow between systems can be achieved through other means, and understanding those alternatives opens up options that might otherwise seem closed. Email ingestion is one. On the motion picture production management tool, we processed data by reading emails sent to specific roles within a production, rather than connecting directly to the underlying platform. This worked because the data we needed was consistently structured within those emails, and the process could be made largely transparent to users. On a performance coaching survey app, we built an approach that controlled access and prevented fraudulent responses without any traditional API at all. Only authenticated coach accounts could create surveys. Each QR code contained a unique key granting read access to only that specific survey. When a respondent accessed the URL, we used a cookie and device fingerprinting to restrict write access to one submission per device per survey. This prevented duplicate responses while ensuring respondents could not read other participants' answers. The whole system was secure and functionally complete without a conventional API layer. If a direct API connection is blocked, map out what data you actually need and where it appears, even indirectly. Email content, QR codes, file exports, and webhook events can all carry usable data without requiring a formal API agreement. ## Who Owns the Integration Specification? When an app needs to connect to a system built by another developer, the question of who defines the integration specification matters more than most clients expect. On a trading platform we worked on for the drinks industry, we inherited a tightly coupled web product built by a third-party developer with no API layer exposed. Connecting different parts of the system required that developer to define how their data could be accessed. Getting timely responses from them became a significant blocker. The project stalled. Rather than continuing to wait, we took a different approach. We wrote the API specification ourselves, built our work towards that spec, and then had the third-party developer implement it on their side. Taking ownership of the spec broke the deadlock and allowed the project to move forward. The developer had been slow to engage partly because defining the spec felt like additional work for them with no clear benefit. Once we handed them a clear, detailed specification to implement rather than a vague request to "provide an API", the conversation changed. #### Who should write the spec The team with the clearest view of [what the integration needs to do from the user's perspective](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) is usually best placed to write the spec, even if the other developer will ultimately implement it. Waiting for a third party to define something on your behalf is a dependency you do not control, and dependencies you cannot control are the ones that delay projects. ## Questions to Ask Before You Commit to Any Integration Before any integration is planned into a project, the following questions need real answers rather than optimistic assumptions. The time to ask them is before the brief is signed off, not after development has started. 1. Does the system we want to connect with have a documented, publicly available API? 2. Is that API accessible to external developers, or does it require a commercial agreement or approval process? 3. Can the API actually perform the specific operation we need, such as reading a particular data field, writing to a particular record, or returning data in real time? 4. Who built the existing system, and are they available and willing to support the integration work? 5. If the API does not exist or is not accessible, what are the alternative routes to the same data? 6. What happens to the product's [core function if this integration fails](https://weareaffective.com/learning-centre/why-most-business-apps-fail-and-how-your-digital-business-can-avoid-the-same-fat) or is delayed? These are not rhetorical questions. Each one deserves a specific, documented answer from someone with technical access to the systems involved. An integration that looks straightforward from the outside can be technically blocked once you are inside the platform, and the only way to know is to check before committing the budget to work that depends on it. ## Conclusion The answer to "can my app integrate with my existing systems?" is almost never a simple yes or no. It depends on what those systems expose, who controls that access, and whether the alternative routes available are sufficient to meet the actual need. The projects we have described here, the motion picture production tool, the drinks trading platform, the alcohol buying and selling app, the memory-sharing proof of concept, each faced a different version of this problem, and each resolved it differently. What they have in common is that the resolution was better when it happened early. The 20% work uplift on the drinks platform happened because an architecture question was not answered before building began. The pivot to Deezer worked cleanly because it happened at the proof-of-concept stage, before significant investment had been made in a Spotify-dependent architecture. The spec ownership approach on the trading platform worked because we stopped waiting and took control of something we could define ourselves. Integration is a foundational design decision that shapes what is technically possible, what the product will cost, and what users will actually experience. Getting it resolved early is simply good practice. If you are planning an app and need to work out what integration is realistic for your situation, [let's talk through your project](https://weareaffective.com/get-started). ## Frequently Asked Questions What does 'integration' actually mean when it comes to a business app? Integration means your app can read data from, or write data to, a system you already use, such as a CRM, payment processor, or booking tool. This is typically made possible through an API, which is a set of agreed rules for how two separate software systems exchange information. Most established platforms offer an API precisely so that other products can connect to them. What is the difference between API integration and API development? API integration means connecting to an API that already exists, whereas API development means building one from scratch. These are not interchangeable, and confusing the two is one of the most common causes of budget shock. Treating them as the same thing can cause a project estimate to be wrong by a factor of three to five. Can every business system be integrated with a new app? Not necessarily. Not every system has an API, not every API is open to external developers, and not every API can perform the specific task your project requires. Integration is a spectrum of access, capability, and constraint, and this needs to be mapped out before development begins. When should integration decisions be made during a project? Integration decisions should be made before a single line of code is written, not later in the process. Decisions made late in a project do not stay contained, they reshape the whole product and can significantly increase costs and timescales. Early discovery work is the most reliable way to avoid this. What are the most common types of systems a new app might need to connect with? The most common categories include CRM and customer data platforms, payment processors and financial systems, booking and scheduling tools, and communication tools such as email or SMS gateways. Knowing which category applies to your project shapes much of what follows in the development process. What can go wrong if integration issues are not identified early? A third-party platform that looks straightforward on paper can turn out to be blocked once you gain access to the actual systems. An integration partner may need to be swapped out mid-project, or an existing product may have been built in a way that makes clean integration practically impossible. These situations are recoverable, but they cost time and money that could have been saved with earlier investigation. How widely used are APIs across businesses today? According to Salesforce's Connectivity Report 2023, 99% of organisations now report using APIs to integrate their applications and data. REST, the most widely used API format, is used by 93% of developers, according to Postman's 2025 State of the API Report. The infrastructure is well established, and experienced developers know how to work with it. What should I do if the system I want to integrate with does not have a suitable API? If a system lacks a suitable API, you will need to explore alternative options, which might include middleware tools, workarounds, or reconsidering the integration partner entirely. In some cases, custom API development may be required, which is significantly more complex and costly than standard integration. Understanding this possibility early gives you the best chance of planning and budgeting appropriately. ## 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.