How to Keep Track of the Services Your Software Depends On

A business application may rely on several outside services even when customers see one product. Hosting, email, payments, storage, maps, and AI features can each have a separate account, bill, and failure mode. A short inventory helps the owner know who controls these services, what work they support, and what would happen if one changed or stopped.

Record the essentials for each service

List the provider, purpose, account owner, billing contact, renewal or pricing basis, support route, and where the contract or terms can be found. Identify which customer or staff task depends on it. Do not store passwords in the inventory; use the business's approved credential arrangement and note who can recover access. Keep the list short enough to update whenever a service is added or replaced.

The GOV.UK guidance on choosing technology recommends making and maintaining a map of the technology landscape. For an SME, a one-page dependency record may be more proportionate than a complex management platform. The value is knowing what the business owns and what it must ask a provider to maintain.

Mark the business consequence of failure

If messaging fails, staff may still serve customers but need to send confirmations later. If payments fail, orders may need to remain pending. If storage fails, staff may be unable to read documents required for a job. Note the safe temporary action and the person who monitors recovery. A list of suppliers without the task they support is less useful during an outage.

Ask which service holds important data and whether the business can export it. A provider may store only temporary delivery logs, or it may hold the only copy of customer files. Record the difference. The GOV.UK guidance on managing technical lock-in advises reassessing reliance and switching costs as a service develops. An inventory makes that review possible without rediscovering each dependency from scratch.

Review costs and access periodically

Compare bills with usage and look for changes in the supplier's terms. Confirm that former employees and providers no longer have unnecessary account access. Check whether the person named as owner still works with the business and can receive important notices. These checks can be brief, but they should recur after staff changes, new features, or a surprising invoice.

Decide which dependencies deserve a tested fallback. A critical payment connection may need a clear pending state and reconciliation process. A rarely used optional map feature may only need an honest error message. The GOV.UK guidance on APIs notes that external failures can affect service availability and calls for proportionate alternatives and communication.

Make changes to the inventory part of normal project work. When a developer adds a new supplier, record its purpose, account ownership, cost basis, and data it receives before the feature goes live. When a supplier is removed, check that billing ends and access is closed. A list reviewed only during a crisis will be incomplete just when the business needs it most.

For critical services, ask whether notices reach a shared business address or one person's inbox. A provider may warn about a failed payment or required update, but the alert is useless if the recipient has left the company. Keeping the communication path current is a small task with a clear continuity benefit.

Check the list after each significant product change, even if no new supplier was added.

Holism can help a business owner keep this map understandable while a developer uses AI and reusable foundations to maintain the underlying connections. The owner decides which services justify their cost and risk. An up-to-date dependency record turns a hidden web of suppliers into a set of manageable business choices.