List every outside service your software depends on

Most custom software for a service business is a small amount of code sitting on top of a lot of other people's services. The booking screen is yours. The text messages go out through a messaging provider. Payments run through a processor. The phone number lives with a telecom carrier. The voice agent calls a model provider. Email goes through one company, the domain is registered with another, and the database is hosted by a third.

Each of those is fine on its own. The trouble is that nobody in the office could name all of them, and the developer who set them up may not remember either. When one of them stops working, the first hour goes to figuring out which one it is and who has the login.

When we take over or build software for a service business, one of the first things we write is a plain list of every outside service the system depends on. This post covers why that list matters, what goes on it, and how to keep it current without turning it into a project.

The outages that are not bugs

A lot of the "the system is down" calls we get are not code problems at all. Nothing changed in the software. Something outside it quietly expired or got switched off. The common ones look like this:

A card on file expired. The hosting bill, the texting provider, or the phone carrier tried to charge a card that was replaced months ago. A few reminder emails went to an inbox nobody reads, and then the service paused. Texts stop going out, or the site goes dark, and the code is perfectly fine.

A domain or certificate lapsed. Domain renewals are often set up once, on someone's personal card, by someone who has since left. When the domain lapses, email bounces and the website stops loading. Customers assume the business closed.

An API key was rotated or revoked. Someone cleaning up an account deletes a key that looked unused. It was the one the booking flow used to check the calendar.

A free tier ran out. A tool that was free during setup starts charging past a usage limit, or caps requests once the business grows. The first sign is a feature that works in the morning and fails by afternoon.

A vendor changed their terms or their API. Providers retire old versions of their APIs on a schedule, and they usually announce it by email to the account owner. If the account owner is a former contractor, nobody sees the notice.

None of these show up in a code review. They show up as a confused call from the office. The fix is usually five minutes once you know where to look. Finding where to look is the slow part.

What goes on the list

The list does not need to be fancy. A shared document or a spreadsheet works. For each outside service, we write down:

• What it does for the business, in plain words. "Sends appointment reminder texts" is better than the vendor's product name.
• What breaks if it stops. This tells you how fast you need to act. If reminders stop, that is a bad day. If payments stop, that is an emergency.
• Which account owns it. The login email, and whether that email belongs to the business or to a person. Accounts tied to a personal email are the first thing to move.
• How it is paid for. Which card or bank account, and when it renews. Monthly, yearly, or usage based.
• Who has access. Names, not "the team." If only one person can log in, that is a risk worth writing down.
• Where its keys live. Not the keys themselves. Just where they are stored, so nobody has to dig through old messages to find them.
• How to reach the vendor. The support page or status page, and whether you are on a plan that includes phone support.

For a typical small service business system, this list runs somewhere between ten and twenty rows. That is short enough to read in one sitting and long enough that nobody holds it all in their head.

Move ownership to the business

Writing the list usually turns up a few accounts that belong to the wrong person. A freelancer opened the hosting account under their own email. The owner's spouse registered the domain years ago. A former office manager set up the texting service on a personal card.

We fix those before anything else. The business should own every account its software depends on, with a shared admin email the business controls and at least two people who can log in. Contractors and developers get their own access as invited users, so their access can be removed on their last day without touching the account itself.

The same goes for billing. Put recurring charges for the system on a business card, and route billing emails to an address someone actually reads. Many services let you add a separate billing contact. Use it. Most lapses we see would have been caught by someone reading one email.

Put the dates where someone will see them

A list nobody looks at only helps after something breaks. A few small habits make it useful before:

Calendar the renewals that matter. Domains, certificates that are not renewed automatically, and annual plans get a reminder a month ahead on a shared calendar. Thirty days is enough time to fix a card or move an account without rushing.

Check card expiry dates once a quarter. When the business replaces a card, the list tells you every service that needs the new one. Without it, you find out one outage at a time.

Subscribe to status pages. Most vendors publish a status page with email or text alerts. Subscribing the shared admin email means you hear about a provider outage from the provider, not from a customer.

Note usage limits. If a service has a cap, write down what it is and roughly where the business sits today. Revisit it when call or job volume grows.

Review it when people change

The list goes stale in predictable moments: when someone leaves, when a developer hands off the project, when a new tool gets added, and when the business switches banks or cards. Each of those is a trigger to open the list and update it.

We make it part of the handoff whenever we finish a build or add a feature. If the change added a new outside service, it goes on the list before the work is called done. If it removed one, the row comes off and the account gets closed, so nobody pays for a tool the system no longer uses.

Start with one afternoon

You do not need to audit everything at once. Sit down with whoever built or maintains your software and ask them to name every outside service the system calls. Then check three things for each one: who owns the login, what card pays for it, and when it renews.

Most businesses find at least one account tied to a personal email and at least one renewal nobody was tracking. Fixing those two things takes an afternoon and removes a whole category of outages that have nothing to do with the code.