Eight questions you should be able to answer about the software your business runs on

If your business depends on software someone else built, you should be able to answer eight questions about it without calling them: who has access, where the code and data live, whether there's a staging environment, how a change gets deployed, how it's backed up, what's out of date, what's tested, and who you call when it breaks. If you can't answer three or more, the software is running on one person's memory, and that person may not always pick up.

You don't need to be technical to answer these. You need to know who to ask and what a good answer sounds like. This is the check we run at the start of every Owner's Manual, and you can run it yourself this afternoon.

1. Who has access, and to what?

List every account that touches the software: the code repository, the hosting provider, the database, the domain registrar, email sending, payment processing, and any third-party services. For each, who has the login, and is it in the business's name or the developer's?

Most owner-held software has at least one account in the developer's personal name. That's the first thing to fix, before anything else, because everything below depends on it.

2. Where does the code live, and is it all there?

The code should be in a repository the business controls, and the version in the repository should be the version that's actually running. Ask when it was last pushed. Compare it to when the software last changed. If those dates don't match, some of the running software exists only on a server or a laptop.

3. Is there a staging environment?

A staging environment is a copy of the software where changes can be tested before customers see them. Without one, every change is tested in production, by your customers. If the answer is "we just test it live," you've found the reason changes feel risky.

4. How does a change get deployed?

Ask for the exact steps from "the code is written" to "customers can use it." A good answer is a pipeline: push the code, tests run, it lands on staging, someone approves, it goes to production. A bad answer is a person running commands from memory. The second kind works until that person is unavailable.

5. How is it backed up, and has a restore ever been tested?

A backup that has never been restored is a hope, not a backup. Ask when the last backup ran, where it's stored, and whether anyone has ever restored from it. If the restore has never been tested, schedule one.

6. What's out of date?

Every piece of software depends on other software: frameworks, libraries, language versions. Each one has updates, and some updates fix security problems. Ask how far behind the dependencies are. Two years behind is common and usually fixable. Five years behind means the next update is a project.

7. What's tested?

Automated tests are the software checking itself. Ask what percentage of the code has tests and which parts don't. The untested parts are where a small change can break something unrelated. You don't need full coverage. You need to know where the gaps are before you ask for changes.

8. Who do you call when it breaks, and how fast do they answer?

If the answer is a person's name and a cell number, you have an arrangement — not a system. Ask what happens if they're on vacation. Ask what a response time in writing would look like. If nobody has ever put one in writing, that's the conversation to have next.

What to do with the answers

Score yourself honestly. Five or more solid answers, and you're in better shape than most. You may only need a plan for the gaps.

Three or fewer, and the software is fragile in a way that has nothing to do with code quality. That isn't a you problem. Nobody handed you these answers when the build was done. The fix is not a rewrite. It's documentation, access in the right names, a staging environment, a deployment pipeline, and a response time somebody has committed to.

That's what an Owner's Manual produces in a week, written for you and signed off by an engineer, and what Operate keeps true afterward. Or start with the eight questions above, on your own. Either way, the goal is the same: software your business can count on, that doesn't depend on one person remembering how it works.