Glossary · The rescue vocabulary

The words, defined.

Rescue, rebuild, harden, adopt, scope. This industry uses these terms loosely and then bills against them. Here is what each one means at NeuroLabs—written plainly enough to quote back at us, and short enough to actually read.

01 / TermsSixteen definitions

T-01

Website rescue

A structured takeover of a website that is failing, outdated, abandoned, or built by someone who is no longer available. The site is diagnosed first, then either repaired or rebuilt, and someone becomes responsible for keeping it working afterward. A rescue is distinguished from ordinary web development by what is unknown at the start: the code, the accounts and the hosting all arrive as somebody else’s decisions. At NeuroLabs every rescue begins with a paid, time-boxed diagnosis and a written findings document, and a firm flat quote follows before any code is written.

T-02

Website rebuild

Replacing an existing website with a newly built one, rather than repairing what is there. A rebuild deliberately carries across whatever still has value—content, page addresses, search rankings, accumulated trust—and discards the underlying build. It is the right call when the existing code would cost more to understand than to replace, which is more often than most owners expect.

T-03

Abandoned build / orphaned build

A website or application that was started and never finished, usually because the developer stopped responding, the agency folded, or the budget ran out mid-project. What remains is partial code, half-configured hosting, and accounts registered in the name of someone who has moved on. Adopting one starts with establishing what actually exists versus what was promised—those are rarely the same list. An orphaned build is the same thing named from the code’s point of view: it is finished enough to run, and has nobody responsible for it.

T-04

AI-built site (vibe-coded site)

A website or application generated largely by an AI coding tool from prompts, rather than written deliberately by someone who understood each decision. These builds often look finished on the surface while carrying duplicated logic, undocumented choices, dependencies nobody selected, and security assumptions nobody checked. “Vibe-coded” is the informal name for the same thing: the output was accepted because it looked right, not because it was understood. The problem is rarely that the code is bad—it is that no human can say why it is the way it is.

T-05

AI build rescue

A website rescue applied specifically to an AI-generated build. It typically covers auditing what the generated code actually does, removing unused and duplicated code, replacing insecure or fabricated patterns, hardening dependencies and headers, finishing features that were only sketched, and moving the thing onto real hosting with a real deployment process. The goal is a build a human can maintain—and then actually maintaining it, so it does not rot again.

T-06

Harden and ship

Taking an existing, roughly working build and making it safe and durable enough for production instead of starting over. Hardening covers the things that fail quietly: dependencies, security headers, access control, input handling, error states, and backups. Shipping means it genuinely goes live—hosting, domain, SSL and monitoring in place—rather than being handed over as a folder of code. It is the cheaper half of the repair-or-rebuild decision, and it is only honest when the diagnosis says the foundation is sound.

T-07

Adopt and run

Taking ownership of a codebase somebody else wrote and being responsible for it from then on. Adoption is the takeover—reading the code, claiming the accounts, learning what breaks. Running is the part most shops decline: updates, monitoring, changes, and answering the phone when something goes wrong at an inconvenient hour. It is the difference between buying a one-time fix and having someone who knows your site.

T-08

Time-boxed diagnosis

A paid, deliberately bounded investigation of an existing site or codebase, carried out before anyone quotes the work. Time-boxing means the investigation cannot quietly expand into the project itself, and paying for it means it is treated as real engineering rather than a sales exercise. It ends in writing: what the build does, what is salvageable, what is unsafe, and whether repair or rebuild is the honest recommendation. The findings belong to the client, including the freedom to take them somewhere else.

T-09

Flat quote

A single fixed price for a defined scope, agreed in writing before work begins. It is the opposite of an hourly arrangement: the risk of the work taking longer than expected sits with the studio, not with the client, and asking a question never increases the bill. A flat quote is only honest when the scope is genuinely understood, which is why inherited code is quoted after a diagnosis and never before.

T-10

Plugin graveyard

A website—very often WordPress—carrying a pile of plugins installed over years, many unmaintained, several overlapping, and nobody left who knows what each one was for. Every plugin is an update to run, a dependency to trust, and a possible way in for an attacker. Clearing a graveyard is slow work because you have to establish what each plugin actually does on the live site before you can safely remove it.

T-11

Legacy website

A site still running on technology, a platform, or a set of assumptions that are no longer supported or no longer match how people use the web. Legacy is not really about age: a site can be a few years old and legacy if nobody can safely change it. The practical test is whether a small change can be made without fear. If the answer is no, it is legacy regardless of what year it says in the footer.

T-12

Static-first rebuild

Rebuilding a site as plain, pre-built HTML, CSS and images wherever a page does not genuinely need a database or a server doing work at request time. Static pages load faster, cost less to host, are far harder to attack, and do not break when a plugin or framework goes unmaintained. Dynamic pieces are then added deliberately where they earn their place—forms, search, an application—instead of being the default for everything.

T-13

Technical SEO

The part of search visibility that lives in the build rather than in the writing: crawlable structure, sensible URLs, correct redirects, canonical tags, page speed, mobile rendering, structured data and sitemaps. It does not decide what you deserve to rank for—it decides whether a search engine can read, trust and index what is already there. It is also the part that quietly breaks during a redesign, which is why rescues almost always find it missing, half-done, or actively working against the site.

T-14

Credential handover

Transferring every account a website depends on into the client’s own name and control: domain registrar, DNS, hosting, code repository, analytics, forms and mail. It is done in writing, at launch, whether or not the working relationship continues afterward. Being locked out of your own website is how a large share of rescues begin, so the handover is treated as part of the job rather than a favour granted on exit.

T-15

Maintenance (ongoing care)

The work that keeps a live site working after launch: hosting, updates, backups, monitoring, security patches, and the small changes a real business keeps needing. Launch is the start of operations, not the finish line. A site left without maintenance does not stay as it was—it decays, quietly, until the day it matters. Ongoing care is quoted flat like everything else, and it is the reason a rescue is worth doing at all.

T-16

Scope

The written definition of what a project includes and, just as importantly, what it excludes. A clear scope is what makes a flat quote possible, and what keeps “one more small thing” from turning into an argument nobody enjoys. Anything outside it is named as outside before work starts, and priced separately if you decide you want it. A project without a written scope is not cheaper; it is just unbounded.

Where the words get used

These aren’t just definitions.

Every term on this page maps to something in the actual process: the diagnosis that comes before a quote, the findings document you keep, the handover of every credential at launch. Read the sequence and you will see where each word does its work.

Not sure which word applies?

Describe the site in your own words and we’ll tell you which of these it is—and what we’d honestly recommend. A direct reply within one business day.