Sites, apps & software

Taking back a system nobody answers for: what can be recovered, what has to be rebuilt

Your site runs, your software runs, and whoever built them has stopped replying. A great deal of the answer is public and free.

Published on 28 July 2026 — Algeria Agency

The article beside this one ends on ownership: what must remain yours when a project is delivered. It is the right advice and it addresses somebody who has not yet signed.

This one addresses the other half of the readership. The system exists, it runs, it runs the business — and the person who built it has stopped answering. They emigrated, the firm closed, the relationship ended badly, or it was an employee whose access nobody took back when they left.

The usual panic comes from a belief: that everything depends on the cooperation of somebody unreachable. That is false for most of the file. One hour of public checks, which need nobody’s permission, tells you who holds what and what you actually still have to obtain.

This article gives the six pieces to recover in order, what can be read with no cooperation, what an invoice recovers, what has to be rebuilt — and why you should set a rebuild date before you have any answer.

The day nobody answers any more

It almost never begins with a conflict. It begins with an unanswered message, then a second, then a call that rings out. Two months later the site still works, nobody has changed anything, and you notice you have no idea how it would work if it had to be touched.

The four causes we meet are ordinary and none of them is malice. An independent developer who moves abroad and changes their life. A small agency that closes. A relationship that ended over a disputed invoice. An employee who built the internal tool and whose access nobody took over on the day they left.

What those four have in common is that there was never a moment of handover. It is not that somebody refused to give: it is that the question was never asked while it was easy, and the knowledge sat in one head.

The second thing they have in common is timing. Nobody deals with this on the day it appears, because nothing breaks that day. It gets dealt with on the day a price has to change, a page has to be added, a certificate has to be renewed or a customer has to be answered — and by then it is urgent, when it was never difficult.

The good news is the one thing this article really wants to land: your situation is already determined by facts that exist, most of it is readable today, and you need nobody’s agreement to read it.

The six pieces to recover, in this order

An online system rests on six things, and they are not equivalent. Handling them out of order is what loses weeks, because the first one conditions all the others.

The domain name comes first. It is the address your customers know and the only piece that cannot be rebuilt: everything else can be made again, and your domain cannot be re-manufactured if it falls into other hands.

The domain’s technical zone comes next — what decides where the site and the email addresses point. Then the hosting, the machine that serves the pages. Then the code. Then the database, which holds your work. Then accounts at third parties: payment, advertising, messaging, app store.

That order is not a preference, it follows from risk. A domain expiry is irreversible in practice and can happen within a fortnight. An unrecovered database is serious but does not vanish by itself while the hosting is paid. Lost code is a cost, not a lost address.

Write those six lines on a sheet and fill them in as the next sections go. By the end of the day you will know which are already yours, which need a process, and which have to be remade.

The domain name is the only piece that cannot be rebuilt

Everything else on that list can be remade with time and money. A site can be rewritten, a database re-entered in the worst case, hosting reopened in ten minutes. Your address is unique and occupied by you only while somebody is paying.

So the first thing to check, before even knowing who holds what, is the expiry date. It is public. If it is close, everything else waits: a domain expiring while you look for the developer becomes a different kind of problem, and it can be bought by whoever noticed it coming free.

The second thing to check is whose name it is registered in, and that is where most of the bad surprises live. A domain registered in the supplier’s name, with their address and phone number, is not legally yours even if you have paid for it for eight years.

That situation is not hopeless and it is common, because it is what happens when a supplier does everything "to keep it simple". A contract, invoices naming the domain and correspondence are often enough to establish the economic reality with the registrar. What is usually missing is not the right, it is the file.

Two rules to carry forward in every case: the only acceptable end to this story is a domain registered in your company’s name with a contact address you actually read; and that address must never be on the same domain, or you lose the spare key at the same time as the door.

What you can learn in an hour, with no cooperation

This is the most useful section of the article, and it asks nobody’s permission. A good deal of your system’s structure is public by construction, because the internet works by announcing who hosts what.

A public lookup on your domain gives you the registrar, the creation date, the expiry date and often the administrative contact’s name. That tells you who to write to and how long you have, two facts most businesses in this situation have never had.

Your domain’s name servers tell you who controls the technical zone. They are not always at the same supplier as the registration, and that fact is worth several days: sometimes the domain sits with a host you are already paying while the zone is elsewhere, or the reverse.

Hosting can usually be inferred from a simple address resolution showing which operator the machine sits with. That does not give you a password, but it gives you the counterparty — and a host has procedures for a customer who has lost access to an account invoiced in their name.

Finally, the site’s technology is readable in its own pages: the nature of the tool, often its version, sometimes an administration interface at a standard address. That is not for getting into anything — it is for knowing what would have to be taken on, and for not paying for a quote drawn up blind.

What an invoice recovers, and what needs a process

Once the map is drawn, the pieces sort into two piles, and the difference is who has an interest in answering you.

Suppliers — registrar, host, payment operator — have procedures for this, because the case is common and they have no interest in losing a paying customer. What they ask for is administrative: proof the company exists, invoices for the service, sometimes a request on headed paper. The file is tedious to assemble and it gets there.

What no procedure covers is what only a person holds: source code that exists on their computer alone, documentation that does not exist, explanations, the password to an interface that lives at no supplier. There is no administrative recourse there, only a letter and a deadline — section 8.

There is an intermediate case worth knowing: the supplier did take an account with a provider, but in their own name, reselling the service. The provider does not know you and can do nothing for you whatever your invoices, because their customer is the supplier. It is the only case where the administrative route is genuinely closed, and it is better discovered in an hour than after three weeks of chasing.

So the sort is done with one question applied to each line: is there a company, other than the supplier, that invoices me for this service or once did? If yes, the line will get there. If no, it depends on a person, and it should be treated as a line to rebuild.

The database: the only part that holds your work

Of the six pieces, only one holds something nobody can remake: your customers, your orders, your products, your entries, the record of what your business has done. The rest is machinery.

The good news is that this part is almost always the most reachable, because it lives on the hosting, and hosting is generally in the administrative pile. A host who gives you back access gives you the database with it, without anybody needing to understand the code.

What to do on the very day you get that access is take a copy out and open it. Not check that a backup exists: download a file, open it, and see your data in it. Until that is done you have not recovered your work, you have recovered a promise.

The commonest trap is where the files live. The data is in the database, but images, documents, attachments and generated invoices are often files sitting beside it. A recovery that takes the database and forgets that folder gives back a catalogue with no photographs and accounts with no supporting documents.

And an observation that has saved several of these cases: even when everything else is lost, a recovered database lets you build a different system without starting again commercially. You lose the tool and keep the business. It is the other way round that is fatal.

The code: what it is worth, and when it is worth nothing

Code is what people demand first, by reflex, and it is almost never the most important piece. It deserves saying plainly because it changes what you spend your energy on.

Code has value in two cases. When the system contains business rules written over years — discount calculations, special cases, a way of invoicing peculiar to your trade — because those rules are a memory of your business as much as a program. And when the system is large enough that replacing it would be counted in months.

It has none in two other, very common cases. When it is a site built on a standard tool, where the value is in the content and the database and the code is a configuration anybody can redo. And when it is old enough that nobody will take it on: code no supplier will agree to maintain is not an asset, it is a constraint.

A useful distinction that is usually missed: you can hold a right over that code without holding a copy, and a copy without a clear right. The two questions are independent. Plenty of businesses fight for a file when what they mainly need is a written assignment, and the reverse happens too.

The cheapest way to settle it is to ask an independent supplier to look at what is visible from outside and answer one precise question: does taking it on cost more or less than rebuilding. Half a day of examination often avoids three months spent recovering code the new supplier would have thrown away anyway.

Third-party accounts, one at a time

The sixth group is discovered last and produces the most visible interruptions, because each of these accounts is a separate relationship with a separate company.

Online payment leads and is the most rigid: it hangs off a commercial contract and a bank account, so the paperwork is almost certainly in your name. That is good news, but getting it back involves the bank and the service provider rather than the developer.

Advertising accounts pose the opposite problem. They are often created by the supplier inside their own workspace, with your card paying. You are then funding something you do not hold — the subject of the "what you must not rent" section in the article beside this one, and this is where the bill arrives.

App store accounts are their own case and the most expensive when they go wrong. A developer account is tied to an identity and a company; an app published under the supplier’s account does not simply move, and depending on the case it needs a transfer only the holder can begin, or a republication that loses your history and your reviews.

Make the list of services you pay for by reading your bank statements rather than your memory. It is the most reliable way to discover a subscription you did not know existed, and a statement always tells the truth about who pays for what.

Writing to silence: the letter that works better than a message

After three weeks of unanswered messages, a fourth recovers nothing further. What sometimes changes the situation is a change of channel and tone, and it costs an hour.

A letter — on headed paper, sent with tracking, to the address on their invoices or their registration — gets a response rate unrelated to that of a message. It is not a threat: it is an object that exists, arrives at somebody’s home, and makes visible that the request is formal.

Its content is five lines. What you are asking for, precisely and piece by piece: transfer of the domain, access to the hosting, a copy of the database, assignment of the code. The date you need it by. A note that you are willing to pay for the hours the handover takes, which removes the commonest reason for refusing. And nothing else.

What not to put in it matters as much: no reproach, no questions about the past, no mention of a dispute while it is not necessary. Somebody who let it drift out of embarrassment — the commonest case by far — answers a simple request and does not answer an accusation.

And above all, the letter states a date on which you will start rebuilding without a reply. That is not pressure, it is your schedule: from then on your project no longer depends on somebody else’s decision, and it is the only thing in this whole article entirely within your power.

Rebuilding: what it costs, and why it is sometimes cheaper

Rebuilding is experienced as the defeat of the whole business. It is often the best outcome, and it is worth knowing before spending three months avoiding an expense you would have incurred anyway.

The honest calculation compares two things: the cost and time of taking on the existing code — access, understanding, repair, plus the risk of discovering along the way that it is unmaintainable — against the cost and time of rebuilding on the recovered database.

What that calculation almost always forgets, and what tips it towards rebuilding, is that you are not rebuilding what you had. You are rebuilding what you use. Most five-year-old systems contain a half of their functions nobody opens any more, and that half is not paid for twice.

What it forgets in the other direction, and which belongs on the scale, is your own people’s time. A rebuild means re-describing rules, retesting, relearning habits. It is not a line on an invoice and it is real.

The rule of thumb we apply: if the database is recovered and the code is a standard tool, rebuilding wins almost every time. If the system holds business rules written over years and the code is readable, taking it on wins. Between the two it is your own team’s availability that decides, not the technology.

Why we give neither a timescale nor a success rate

The question asked in every one of these cases is the same: what are my chances the developer eventually answers, and how long will it take. We have no figure to give and no honest one exists.

The reason is peculiar and worth understanding, because it also explains why nobody else has that figure. The population it would have to come from is unreachable suppliers — and a supplier who answers your letter was not unreachable. They leave the set at the very moment they would have produced the datum.

In other words, the set erases itself. It can only ever contain unresolved cases, so its response rate is zero by construction, and that zero describes nothing at all. This is not a problem of sampling or of the publisher’s honesty: the definition of the population excludes the measurement.

It is also why the stories you hear mislead in both directions. Those who tell of a successful handover are describing somebody who did eventually answer, and those who tell of failure will never know whether a letter to the right address would have changed anything. Neither story predicts yours.

So we replace the question with a decision, which is the only way out of that reasoning: you set the date on which rebuilding starts, you state it in the letter, and you hold to it. An answer arriving before that date is a gain; one arriving after costs nothing, because your project no longer depends on it.

What we do, and what we refuse to do

We do the hour of public checks and hand you the map: who holds the domain, when it expires, where the zone points, who hosts it, what technology the site runs on, and which services you are paying for according to your own statements. It is short, it is factual, and it needs nobody’s cooperation.

We then assemble the administrative files with the suppliers, draft the letter, and cost both branches — take it on or rebuild — with the switch date written into them.

We refuse to estimate your chances of the supplier answering. The previous section says why: it is not information we are keeping back, it is a quantity that cannot exist, and an invented figure would have you waiting instead of deciding.

We also refuse to try to get into a system by a back route, even when the system is yours and it would seem justified. That is not decorative scruple: it can put you in the wrong in a case where you are in the right, and close the administrative route, which does work.

Finally, we refuse to take on code we judge unmaintainable while letting you believe otherwise. We will say so, even when taking it on would be a longer and more comfortable contract for us than rebuilding. And in the next contract, whoever supplies it, three lines are enough for this article never to concern you again: the domain registered in your company’s name, an administrator login in your name on every service, and a copy of the database and the code deposited with you at every delivery.

Frequently asked questions

What comes first if the supplier has stopped answering?

Checking the domain’s expiry date, which is public and takes two minutes to read. It is the only piece that cannot be rebuilt: if the date is close, everything else waits. Only then the technical zone, the hosting, the code, the database and the third-party accounts.

The domain is registered in the supplier’s name. Is it lost?

No, and it is common — it is what happens when somebody does everything "to keep it simple". A contract, invoices naming the domain and correspondence are often enough with the registrar. What is usually missing is the file rather than the right.

Can the data be recovered without the developer?

Very often yes, because the database lives with the host, and a host has a procedure for a customer whose service is invoiced in their name. On the day you get access, take a copy out and open it — and do not forget the folder of files beside it holding images and attachments.

Is it better to take on the code or start again?

If the database is recovered and the site runs on a standard tool, starting again wins almost every time: you are not rebuilding what you had but what you use, and the unused half is not paid for twice. If the system holds business rules written over years and the code is readable, taking it on wins.

What are my chances they eventually answer?

We give no figure and no honest one exists: the population of unreachable suppliers loses its members at the exact moment they answer, so its response rate is zero by construction and describes nothing. Set a rebuild date instead, state it, and hold to it.

How do we stop this happening again?

Three lines in the next contract: the domain registered in your company’s name with an external contact address, an administrator login in your name on every service, and a copy of the database and the code deposited with you at every delivery. None of them costs anything at the moment you ask.

Where we come in

Your domain’s expiry date and the name it is registered to are public, and check in two minutes. What you read there decides the urgency.

We draw the full map in an hour: domain, hosting, code, accounts.
We build the files with each supplier and draft the letter.
We go only through official procedures, never through a technical detour.

Nobody can assess the chances of a former supplier replying, and a forecast would immobilise you: we will not give one.

See the Software & Web Development page Talk it over on WhatsApp

Let us talk about your project

A free audit, no commitment: we look at your online presence and tell you what is holding it back.

Request the free audit Write to us