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.
- 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 without a rebuild: learning the existing system, then walking the fault list — starting with what blocks the site's job, finishing with the cosmetic items.
- 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 |
- 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”
no rebuild happened — 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 this means if your situation is similar
If you have a website whose builder is gone, a takeover does not automatically mean a rebuild. 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.
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.
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 was not followed by a rebuild: 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.
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 no rebuild was needed. 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. 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.