When the person who built your software is gone

You can keep your software running after the person who built it is gone. Someone else can take it over. You do not need the original builder. What you need to start is the code, the logins, and time with the people who use the system every day. This guide covers what to secure first, who owns the code, and how to make changes without breaking what works.

The person may have quit, retired, or stopped answering. An agency may have walked away. The system is often still running, which makes it easy to wait. Waiting is how a renewal, a password reset, or a bill goes to an email nobody else can open. Start with access. Hiring can come after the company can still log in.

What should we do first when our developer is gone?

Secure the accounts the system runs on before you look for a new developer.

Find every account the system depends on, and put the ones you can reach into the company’s control. Many owners in this spot cannot say where the programs even run. Write that down as you find it. A short list on paper is enough to start.

Look for these:

For each account, write who can log in today, which email receives the password reset, and which card pays the bill. Prefer a company email and a company card. If the only login is a personal address, start the provider’s process for moving the account to the company. Do that for every account you find, because each provider moves at its own pace.

Change shared passwords the missing person still knows. Keep the new ones where at least two people at the company can reach them. A shared password list the company controls is safer than one browser on one laptop.

Make a backup, then open the backup and confirm it holds current records. A file nobody has opened is only a hope. If you are not sure how to open it, write that down as a question for the next person who looks. Do not turn the live system off to feel safer. Leave it running while you copy what you can.

Password resets, renewal notices, and warnings often still go to the person who left. Ask your lawyer before you close that mailbox, and point new notices at an address someone at the company reads.

Who owns the code, and how do we get it?

Paying for the software does not always mean you own the code. Your contract is what usually decides it.

If the person was your employee and wrote the software as part of the job, the company is often the owner. If the person or firm was outside the company, paying the invoice may not transfer ownership. Story LLP, writing about U.S. copyright for software an outside agency builds, says, “Payment changes that only if your contract says so in the right way.” That page is a starting point for the legal idea. It is not advice about your contract. Talk to a lawyer about what your agreement actually says before you rely on it.

While that conversation happens, look for a copy you may already have. The code usually sits in one of these places:

• An online code host the company can log in to.
• The server the live system runs on.
• A laptop that belonged to the developer.
• Inside a vendor’s platform, where you can use the system but cannot take the code with you.

Ask the old developer, politely and in writing, for a copy of the code, the logins, and a short note on how a change gets from their computer onto the live system. Say what you need and the date you need it. Keep a copy of that request even if they have gone quiet. If the contract says the company owns the code and they refuse to hand it over, that refusal is a question for your lawyer.

If you cannot reach them at all, start with the accounts you do control. The code may already be on your server or in a code host. Take your own copy and put it somewhere the company controls. Confirm the copy is the whole project, not a folder of loose files that will not run.

Do we need the person who built it?

You do not need the person who built it for a new team to start.

The running system, the code, and the people who use it hold the answers. Staff know which screen they trust, which report they redo in a spreadsheet, and which rule the software enforces even when nobody wrote that rule down. Sit with the two or three people who use it most. Have them show a normal day, including the steps they work around. Those workarounds are part of how the business actually runs.

For example, someone in the office may know that a finished job has to stay on a weekly list for a month, because accounting checks it before paying a supplier. That example is illustrative. It is not a result from a client project. A new team learns a rule like that by watching the work, then looks for the same rule in the code or in the way the screen behaves.

Read the code for one job the business cares about, such as an order, a job record, or an invoice. Follow that job from the screen to the place the record is saved, and to any outside service it calls. One path teaches more than trying to understand every file in the first week. Write down what you learn while it is still fresh. If the notes stay in one new person’s head, the company is depending on a single person again.

None of this is a complaint about the person who built the system. They kept it running. The work now is to put what the system does where the company can keep it.

Why can’t anyone tell us what it will cost?

Nobody can name a fair price for changes to a system they have not seen, so the first honest answer is often that someone has to look.

A number given before anyone has logged in is a guess. That is why new developers sometimes refuse the work, or suggest starting over. They are being asked to promise a result they cannot see yet. You can still get a useful next step without pretending the whole future has a price tag.

Before you pay for that first look, ask for these:

A useful written answer says what the system does, where it runs, what would be risky to change, and what a first small change could be. It should be plain enough that someone who was not in the room can read it. You can take that write-up to a second firm if the first one is not a fit.

You do not need a finished plan before that conversation. Bring the accounts you can log in to, any copy of the code you have, and the names of the people who use the system most. If you are worried that a sales follow-up will ask questions you cannot answer, say that at the start. A fit conversation can stay on what the system does today.

How do we change things without breaking them?

Change a copy first, keep a backup you have opened, and change one small thing at a time.

Leaving the system untouched feels safer when nobody can explain it. The risk is that a renewal, a security update, or a connected service will change anyway, on a date you did not choose. A careful change is smaller than that surprise. Work on a copy of the system, not the live one, until the people who use that part have tried the change. Keep the previous backup until the new behavior has been used in real work. Write down what the system does as you learn it, in the same notes the company keeps.

On our page about software a business already relies on, we describe how to make changes in small pieces your team can check. The first job there is learning what the team depends on the system for.

Should we just rebuild it?

A rebuild should not be the default, because it can drop rules nobody remembers to write down.

The current system has been enforcing those rules for years. Some live only in the code. Some live in the way staff use a screen. A new build that starts from a short wish list will miss them, and the miss shows up after people are already depending on the new system. Learn what the current system does before you decide to replace it.

At Oasis Pavers & Pools, owner Brian Godden had worked with three developers on earlier versions of the office system. One rewrite had been quoted at four weeks and took a year and a half. That rewrite was earlier work, before Byte Bot’s project with Oasis. It is one published example of a rewrite taking much longer than the quote. The case study follows what the office did next. A short quote for a rewrite can be a poor guide until someone has learned the system that is already running.

If you are choosing whether to keep a tool, buy another, or own one, read When is custom software worth owning?. If the records themselves have to move, read Why read the old code before a legacy data migration?. A move can copy every row and still be wrong, because the meaning of those rows lives in the old code.

What if we are selling the business?

A buyer will ask who owns the code, and whether the business can run when one person is gone.

You can prepare that answer before a buyer is in the room. Have these ready:

That packet is also useful if you are buying a company and the seller is slow to share the code. You can ask for the same four items. They show whether the company can keep the software running after any one person leaves.

What if we are switching to a new developer?

Get the code and the logins before anyone quotes a rewrite.

Move the accounts into the company’s name. Take a copy of the code the company controls. Then ask the new team to explain the system back to you. They should be able to say what it does, what it connects to, and which parts the staff depend on. A price for a full rebuild, given before that explanation, is a guess about a system they have not learned.

If the old developer or agency is slow to hand work over, your written request and your contract still matter. Start with whatever you can already reach. A new team can begin from a partial copy, the live system, and the people who use it. They should tell you what is still missing instead of pretending the picture is complete.

What if the builder is still here?

Write the system down now, while the person who knows it can still answer, and put the accounts in the company’s name.

One person holding the passwords, the code, and the explanations is a risk even while that person is on the team. They may leave on short notice, retire, or simply be out when something breaks. Hiring one replacement later can put the company back in the same spot, with everything again depending on a single person. A public guide on this problem makes that point for owners.

Ask the person who knows the system to walk a coworker through one real week. Save the notes in a place the company owns. Add the second person to the accounts. Have both people make one small change on a copy, so the steps are real and not only a document. That is ordinary work. It is also what keeps a later handoff from starting at zero.