How to Avoid Building a Business Around a Fragile Integration

An integration can become a hidden foundation of a product. If an outside service supplies payments, messages, inventory, or customer records, its interruption can stop work even while your own application is running. You do not need to avoid every dependency. You need to know which ones matter, how failures are noticed, and what your business can do while a provider is unavailable.

Map the dependency to a customer promise

List each outside connection and the task it supports. Does it confirm a booking, take payment, deliver a message, or provide a record that staff need before acting? Rate the consequence of a delay in business terms. A missed promotional email and a failed payment confirmation are not equivalent. This helps a small team spend its limited resilience budget where it protects real commitments.

The GOV.UK guide to application programming interfaces notes that relying on a third-party interface can tie service availability to that party and recommends planning alternatives, delayed action, or clear user communication where appropriate. The specific response depends on the task. A business may safely queue a message; it may need to pause an order until payment is confirmed.

Ask what happens when the connection fails

Can the system detect an unavailable service and show a clear status? Does it retry safely, or could repeated requests create duplicate work? Can staff see which transactions need attention? A silent failure is often worse than a visible interruption because customers and staff may act on an assumption that the task completed. Test a short outage and a delayed reply before the integration becomes central to daily work.

Consider changes as well as outages. A provider may alter prices, supported fields, account permissions, or terms. Name who monitors notices and who can authorize a response. Keep a record of the account owner, contract, technical contact, and data that would be needed to move. The GOV.UK guidance on managing technical lock-in suggests reassessing switching cost over time. That is useful even when staying with the supplier remains the best choice.

Define a workable fallback

For each critical connection, decide what staff may do manually, what must wait, and how customers are informed. A fallback should not encourage staff to guess a payment status or send an order twice. Keep it short enough to use during a busy day. Practice it with an ordinary case and one awkward case, then record how temporary work will be reconciled when the connection returns.

Avoid buying elaborate duplicate systems for every risk. A modest firm can make proportionate choices: clear status, a named owner for exceptions, recoverable records, and a realistic manual procedure. The design should reflect the frequency and consequence of failure. Ask a developer to explain the tradeoff between the cost of protection and the cost of an interruption.

Check whether the business can still access its own records if the provider stops responding or the integration account is suspended. An export may be available only through the provider's account, and it may take time to obtain. Ask what information is copied into your system, what remains only with the supplier, and how long the business could operate without it. This is especially important for a connection that supports current orders or customer contact.

Review the dependency after a meaningful change in supplier terms or product use. A connection that was convenient at low volume may become central as customers rely on it. Updating the fallback is ordinary maintenance, not evidence that the original choice was wrong.

Holism can help the owner define which customer promises depend on outside services while a developer uses AI and reusable foundations to make failure handling visible and maintainable. The owner determines what can pause and what must continue. An integration is less fragile when people understand its role, can detect a failure, and have a safe next step.