I did not build this site — I took it over
A market research company's website that already existed when they found me. I have been its maintainer since the summer of 2023 — and the foundation under it has been replaced step by step since.
- The situation
- You have a working website, but the person who built it is gone. Faults pile up on a list with nobody to walk through them — while the site remains the company's shop window.
- The approach
- Takeover first, without replacing anything: learning the existing system, then walking the fault list — starting with what blocks the site's job. Replacing the foundation came later, step by step.
- The result
- The registration flow came right, and I have been the person the site belongs to ever since — its footer says so too: “Developer and maintainer”.
The work in numbers
| Year of takeover | summer 2023 |
|---|---|
| The first fault list | 8 items, in one email |
| Scope of fixes | registration, cookie consent, typography |
| Caretaker role | ongoing since 2023 |
| What it runs on | a custom theme |
| Plugins | 2 — the form and cookie consent |
- Project
- market and opinion research
- Role
- Fixing an inherited site, ongoing maintenance
- Arrangement
- Volunteer contribution
- 01 A working site built by someone else the builder unreachable
- 02 Takeover access, backup, learning the system
- 03 The fault list 8 items in one email operation first, looks after
- 04 Caretaker role ongoing since 2023 the footer agrees: “Developer and maintainer”
nothing was replaced at first — the site was fine, just ownerless
What a takeover looks like
The enquiry was not planned: a technician I knew recommended me, because at his company the website's builder was no longer reachable. The site worked — it recruits research participants, with registration and prize draws — but the accumulating faults had nobody to go to.
The first email I received was a list of eight items. A mixture: add cookie consent, the registration should not require typing the email twice, the notice goes to the wrong address, the font is small, a comma is missing from the address. The last item read: “and world peace, of course” — that is how I knew this working relationship would be fine.
The order: what blocks the job comes first
Of the eight items I did not start with the visible ones, but with what stood in the company's way. Here that was the registration — the site exists to collect applicants. The typography could wait; a lost application does not wait.
The most instructive item was the notice: the applicant's confirmation went to the right place, while the company's internal copy went to an old address. Applications were piling up in a mailbox nobody watched. The fix is a single setting — finding it is the work.
What it runs on
Over the years of the caretaker role the site's foundation was replaced piece by piece. It now runs on a custom theme, with two plugins left on it: one provides the form, the other cookie consent. What fell outside those two — search-engine metadata, visitor measurement, redirects, hardening, image handling — moved into the theme.
On the visitor's side it looks like this: the home page loads ten stylesheets and two scripts, with no jQuery. Nothing changed in the appearance meanwhile — the company sees the same site it is used to, and our correspondence stayed on what matters to them: descriptions, images, contacts.
What this means if your situation is similar
If you have a website whose builder is gone, a takeover does not automatically mean replacing it. It did not here either: the system was fine, it needed an owner, not a replacement.
What a takeover does need is mostly not technical: access, a backup before the first intervention, and an agreement on what may be touched. The fault list can then be walked in a single pass.
If you have a website without its builder — or with one who no longer answers — write a few sentences about what you have and what has piled up on the list. One exchange of emails usually shows how deep the water is.
kristof@kristofkarner.comFrom here on come the details: what decides a notification's recipient, why the double email entry is delicate, and how I touch someone else's code.
The fixes
The notice that went to the wrong address
A registration form typically produces two messages: the confirmation to the applicant, and the internal notice to the company. Their recipients are two separate settings — typically living in two separate places: one in the form plugin, the other somewhere in the template or a general option.
Here the internal notice went to an old address. The trail: find which component sends, what its recipient field holds, and where that value is inherited from. The right address became the company's dedicated applications mailbox — the one that is actually watched.
Typing the email twice, with paste disabled
The request had two sides: the email address must be typed twice, and paste must not work in the confirmation field. For research recruitment this is not pedantry: a mistyped email is a lost participant, because the confirmation never arrives.
Disabling paste on the confirmation field is a short script — and a deliberate compromise: less convenient, but the second field then actually verifies instead of repeating the first field's mistake.
Cookie consent on a site that lives off data
At a market research company the cookie banner is not a formality — the whole business runs on handling personal data, and the website has to match that standard. Consent management went in through a plugin, wired to the policy pages.
What moved into the theme, and what stayed a plugin
The site was originally built on a page builder, with its add-on pack and a parent theme. A set like that carries many decisions at once: the builder, its pro plugin, the template library, the add-ons, and the usual companions alongside them — search-engine metadata, caching, a tag manager, login protection, translation, SVG support, document embedding. Each updates on its own schedule.
What moved into the theme: search-engine metadata and its admin screen, the local and machine-readable structured data, visitor measurement, redirects, closing the WordPress behaviours that are open by default, image handling and head cleanup. Together that is twenty-three PHP files, because they only have to satisfy this one site.
What stayed a plugin is two things not worth writing by hand. One is the form: submission handling, mail delivery, spam filtering and storing what comes in would already be a system of its own. The other is cookie consent — at a market research company that is not a formality, and the consent record is legal evidence.
The appearance did not move meanwhile. That is not something I judged by eye: comparison shots were taken of the old and the new version on the same pages at the same widths — home page, FAQ, registration, prizes and the cookie notice, on desktop and mobile alike.
The parts that are not obvious
Touching someone else's code is a different craft
On my own site I know why everything is the way it is. On an inherited site every oddity may be a deliberate decision whose reason the builder knew and I do not yet. So my interventions here are smaller, my questions more numerous, and a backup precedes every change: its history was not written by me.
The opposite of this is a site whose history was mine throughout: at the clinic's website I designed the editing interface as well, so there the size of an intervention is not a question of risk.
Small faults live in lists
On a site like this, faults do not arrive one by one; they accumulate until someone writes them into a list. A single item takes minutes; the list takes an afternoon. The natural unit of work here is not the project but the list — and at the end of a good list, sometimes, there is world peace too.
The remaining cost sits on a single page
With two plugins left on a site, it is tempting to assume their weight is spread evenly. It is not. The home page has no form, so two scripts run there and no jQuery. The registration page, however, loads the form plugin with its own dependencies: fifteen scripts, jQuery included.
That is the price of the form, and it shows where to look if someone wants to make a site faster. Not across the whole site: on the one page where the heavy component does its work.
Questions about this project
Can you take over a website that someone else built?
You can, and it happens more often than people think — the original builder becomes unreachable, the relationship fades, and the site stays. At this research website the takeover did not start with a replacement: the site worked, it was just ownerless. The work began with getting to know the existing system, continued with the accumulated list of small faults, and settled into a caretaker role. The most important questions in a takeover are not technical but trust questions: access, backups, and agreeing what may be touched.
What should be fixed first on an inherited website?
Whatever costs the visitor money or trust. On this site the registration was the point — the company recruits research participants — so the first fixes went there: the notice went to a wrong address, the email had to be typed twice with paste disabled, and cookie consent was missing. The typographic details — a missing comma in the address, a small font — came after. The order was set not by how visible a fault was, but by whether it stood in the way of the site doing its job.
Why would a registration notice go to the wrong email address?
Because a registration typically sends two messages: one to the applicant and one to the receiving address — and the two are configured separately. On this site the applicant's message was fine, but the internal notice went to an old address, so applications piled up in a mailbox nobody watched. The fix was a single setting; finding it was the work — you have to trace where in the system the recipient is decided.
Is it worth fixing small faults one by one, or waiting for a list?
Small faults arrive as lists by nature — on this site too: cookie banner, email field, notice recipient, font size, a comma in the address. A single item takes minutes or an hour or two, so it is not worth inflating into a separate project; as a list, they can be walked through in one pass, and the site comes right in one step. The last item on this list read: “and world peace, of course” — a sign the working relationship is fine.
What does it mean to maintain a site I did not build?
More careful work than on a site of my own. I inherited someone else's decisions: the page builder, the plugin set, the naming. Before changing anything, the question is why things are the way they are — an odd-looking setting may have a reason the builder knew and I do not yet. In practice this means more questions, smaller steps, and a backup before every intervention.
Does taking over a website mean it has to be rebuilt?
No, and that is usually not where to start. At this site the caretaker role ran for years with the existing system in place: we walked the fault list and the site kept doing its job. Replacing the foundation came later, piece by piece — always where a component was costing more than it gave. None of it was visible to the client: the appearance stayed the same throughout.
What is worth solving with a plugin, and what with your own code?
The useful question is how big a system it would become if written by hand. At this site the search-engine metadata, visitor measurement, redirects, image handling and hardening moved into the theme: each is a few hundred lines when it only has to satisfy this one site. The form and cookie consent stayed plugins — the first would already be a system of its own with submission handling, mail delivery and spam filtering, and for the second the consent record is legal evidence.
Summary
I took over a market and opinion research company's website in the summer of 2023 — the site was built by someone else, and we did not start by replacing it. The work began with an eight-item fault list: the registration notice went to a wrong address, the email had to be typed twice with paste disabled, cookie consent was missing, and several typographic details waited for a fix. The order came from the site's job: registration first — the company recruits research participants — cosmetics after. I have belonged to the site as its caretaker since, as a volunteer contribution; the footer's “Developer and maintainer” line points here. The foundation under it has been replaced step by step over those years: it now runs on a custom theme with two plugins — one for the form, one for cookie consent — while the search-engine metadata, visitor measurement, redirects, hardening and image handling moved into the theme. The appearance did not move meanwhile, and none of it was visible to the client. An inherited site asks for more care than one of my own: I inherited someone else's decisions, so smaller steps, more questions, and a backup before every intervention.