The application still works. That is exactly why nobody has looked at this.
Whoever built it is no longer around. A contractor who stopped replying, an employee who left, an agency that closed. Nothing has broken, so nothing is urgent, so nothing gets done. Then a disk fails, a certificate expires, or the business needs one change it cannot wait for, and a quiet situation becomes an expensive one in an afternoon.
This is written for a company of five to fifty people with one application the operation runs on: an ERP, an intranet, a bespoke web application, a desktop program talking to a central database. It is not a technical audit and it does not need a developer. It is an inventory, and it takes four afternoons.
Do it while nothing is broken. Every item below is cheap this month and expensive the week something fails.
The rule: you have what you can prove
Ask around and the answers come back as sentences like “the code should be with the agency” or “I think the backups run overnight”. Those are beliefs. In an inventory a belief counts as a no.
One rule makes the whole month work. Write down an answer only when you have seen it yourself. Not what someone told you, not what a document from 2019 says. What you have opened, downloaded, logged into or watched happen.
It feels pedantic for about a day. Then it starts finding things.
Week one: the source code
Source code is the only item on this list that cannot be reconstructed. Everything else can be rebuilt with time and money. Start here.
You are looking for one specific proof: a copy of the code on a machine your company controls, that you put there. Not a link. Not an assurance. A folder you can open.
Where it turns up, roughly in order of how often:
- A code hosting account — GitHub, GitLab, Bitbucket, Azure DevOps. Look for the billing email rather than the account name; whoever receives the invoice is the way in.
- The production server itself. A great many small applications were deployed by copying files, and the working copy is the only copy.
- Old invoices and emails. Handover packages get sent as attachments and then forgotten in an inbox.
- A laptop in a cupboard. It is worth an hour of somebody’s time.
If it is there, copy it somewhere of your own today, and check the copy opens. If the company has no code hosting account, this is also the moment to create one in the company’s name and put the code in it. That is a small administrative job now and a project later.
If the code genuinely does not exist, stop looking after a week and say so plainly, because it changes what the application is. You now have an appliance, not an application. It can be run, configured, backed up, moved to another server and queried in the database. It cannot be changed. Everything the business wants to do differently from here is a rebuild with its own budget, and knowing that today is much better than discovering it during a rushed change in March.
Week two: follow the money
The fastest way to inventory the services an application depends on is not technical. It is the company card statement and the supplier ledger, twelve months of it, read line by line.
Every recurring charge is an account. Every account has an owner, a login and a recovery email. Write down the three for each one.
Two things fall out of this that nothing else finds.
Charges nobody can explain. A hosting line, a monitoring tool, a mail delivery service, a domain renewal to a registrar nobody has heard of. Those are parts of your system.
Services that cost nothing. These are the dangerous ones, because they never appear on any statement: a free tier, an API key, a mailbox, a DNS account, a scheduled task on someone’s machine. You find these by looking at what the application actually sends and receives — invoices by email, text messages, card payments, files going to a customer — and asking what each one goes through.
Then there is the one that outranks everything: the domain name. Find out who it is registered to and which email address controls it. Whoever controls the domain controls the email, and whoever controls the email can reset almost everything else. A domain registered to a person who no longer works with you is the single item on this list worth interrupting other work for.
One warning, because it is the classic way to turn this month into an incident. Do not start changing passwords yet. Credentials in a running system are used by things nobody remembers, and a rotation done before the inventory is finished takes down your own application on a Tuesday afternoon. Inventory first. Then change them deliberately, one at a time, in a window where someone is watching.
Week three: a restore you have watched
Ask whether there are backups and the answer is usually yes. It is almost always true and almost never sufficient.
The proof is narrow and it is not negotiable: a copy restored somewhere that is not production, opened, containing a record you recognise, on a date you can name. Until that has happened, what the company owns is a scheduled task, not a backup.
While you are there, three questions that decide whether the restore is worth anything:
- How far back does it go? A backup that keeps the last two days survives a disk failure. It does not survive a problem discovered three weeks later, which is the more common event.
- Does it include the files? Databases get backed up because they are obvious. Uploaded documents, scanned delivery notes, signed PDFs and photographs often live on the server’s disk and often are not in the backup at all.
- Is a copy anywhere other than the same machine or the same account? A backup in the same place as the system it protects covers a smaller set of disasters than people assume.
Add the expiry dates to the same page while the information is in front of you: the domain, the certificates, any licence that has to be renewed. Put them in the company calendar with a person’s name attached. Expiry dates are the only outage in this article that arrives with a date printed on it and is still missed every year.
Week four: what is in someone’s head
This is the part usually called documentation, which is why it never gets done. Nobody writes forty pages and nobody reads them.
Three things are worth having written down, and they are all short.
How it gets deployed. What has to happen for a change to reach the running system. If the honest answer is that a specific person used to do something on their laptop, write that sentence down. It is a true and useful answer, and it tells the next supplier what they are walking into.
What goes wrong routinely, and what somebody does about it. Every application of this age has two or three of these: the service that has to be restarted, the report that fails at month end, the integration that stops after a holiday. That knowledge lives with whoever restarts it and disappears when they do.
Who else has ever touched it. A second name and phone number, even a distant one. The person who covered a holiday, the supplier who did the integration, the accountant’s IT contact who set up the server. On the bad day, one of those numbers is worth more than any documentation.
Then the part that is not technical at all: give the application an owner inside the company, by name. Not a developer. Somebody whose job it is to know where it is, who touches it and who to ring. Without that person, every new supplier starts with archaeology, and archaeology is billed by the hour.
What this produces: one page
At the end of the month the output is not a report. It is one page, and it says:
- where the code is, and where the second copy is;
- the accounts the system depends on, who owns each one and which email controls it;
- when a backup was last restored and by whom;
- what has to happen to deploy a change;
- who to ring, in order.
Keep it where the company keeps its insurance documents and its accounts, not inside the system it describes. Print it. A continuity page that lives only in the application it protects has an obvious flaw.
Review it when something changes: a new supplier, a server move, a person leaving. Twenty minutes, not a project.
What not to do this month
Do not rewrite anything. A rewrite decided while the inventory is still half done is a decision made out of discomfort. Most of these applications do not need replacing; they need to be knowable.
Do not change credentials before the inventory is finished. Already said, and it is the mistake we see most.
Do not send the person who left a message asking for “everything”. It is vague enough to be easy to ignore. Send a numbered list of three specific items — a recent database copy, read access to the code, the list of services and whose name each is in — with a date, and an offer to pay for the hour it takes. Most people answer that. Send it while the relationship is still neutral; the same request during a dispute is a negotiation instead of an administrative task.
The point of doing it now
None of this makes the application better. It makes it survivable, which is a different and cheaper objective.
An application nobody can explain is not a technical problem. It is an asset the company cannot prove it owns. That distinction matters the day you want to change supplier, sell the business, pass an audit, or simply get a change made in a week instead of a quarter.
If you run the inventory and get stuck — the code is nowhere, the backups have never been restored, nobody can say how it is deployed — tell us what you found at nordicbyte.co.uk/get-started. Describe the application, what you have access to and what you do not. We will come back within 48 hours with what can be recovered, in what order, and what we would do first.
And if you work through the four afternoons and everything checks out, that is the better outcome. Knowing costs four afternoons. Finding out on the bad day costs considerably more.