A site its owner can run without me

Simisola Adedeji is a global health professional whose work spans peer-reviewed research, field programmes, monitoring and evaluation, and a steady stream of writing. All of it lived on other people's platforms: journals, conference programmes, social feeds, and the occasional PDF. There was no single owned surface where the whole picture held together.

The brief was a personal site. The actual deliverable turned out to be a publishing operation: a place she could keep current herself, in four languages, without needing a developer on standby.

Four audiences arrive at a site like this wanting different things, and a single scrolling homepage serves none of them well. Worse, the subject area is not English-only. When the internationalisation work was scoped, roughly 95% of the site's copy was hardcoded English, so reaching a francophone reader was never going to be a matter of bolting on a translate widget. It meant rebuilding the content layer.

• A solo build with a single ownerOne person designing, writing, and shipping, with one non-technical owner as the sole decision-maker. That is fast, and it is fragile: with nobody to argue with, scope drifts quietly unless decisions are written down.
• The owner has to run it afterwardsThis is the constraint that drives almost everything below. A site the owner cannot update is a site that is accurate for about a month. Every content decision was tested against whether she could make that change herself.
• Four languages, one editorial voiceTranslation multiplies every structural mistake by four, and a machine translation that mangles domain terminology is worse than no translation at all in a technical field.
• Credibility is the productFor a research audience, a chart that overstates its own certainty does more damage than a plain table. Data presentation had to be defensible before it was attractive.

One owner, one builder. The risk in that arrangement is not disagreement, it is drift: a verbal "yes, that sounds good" six weeks ago quietly becoming a different thing today. The counter-measure was to write decisions down where they could be pointed at. Each phase opened with an approved spec carrying an explicit "decisions locked with owner" block and a numbered list of non-goals.

The non-goals did more work than the goals. On the internationalisation phase they stated plainly that the admin panel would stay in English, that Portuguese was out of scope, that right-to-left support was not being attempted, and that gallery captions were deferred. None of those were oversights, and writing them down meant none of them had to be re-litigated mid-build.

Rather than opening a blank canvas and drawing screens, the work ran through a repeatable design sequence, with each stage producing an artefact the next stage was held against.

The typography went through a full revision partway in, moving from Playfair Display and Inter to Lora and Raleway. Worth naming because it is evidence the visual direction was interrogated rather than picked once and defended afterwards.

Two rules carried most of the creative weight.

• One route, one purposeThe homepage renders the hero and a set of teasers, and nothing else. Every substantial section lives on its own dedicated route rather than being stacked into one endless scroll. This is written down as a page-to-section map, so the rule survives the next person who wants to add "just one more block" to the homepage.
• Data credibility outranks visual complexityStated as the rule that shapes everything on the data side, and enforced as a checklist rather than a sentiment. It costs visual polish on purpose.

1. option 01Markdown files versus a database and admin panelMarkdown in the repository is faster to build and free to host, and it makes the owner dependent on a developer for every correction. A database with a rich-text admin panel cost weeks of extra work and is the only option that satisfies the handover constraint. Chosen for that reason alone.
2. option 02Browser language detection versus locale in the URLAutomatic detection feels considerate and is genuinely hostile to debugging, to sharing a link, and to crawlers, which do not announce a language preference. The URL became the only thing that decides what language renders.
3. option 03Agency translation versus a machine pipeline with human overrideA translation agency gives the best single result and the worst update loop: every content edit becomes a purchase order. The pipeline keeps the update loop instant and keeps a human override for anything that matters.
4. option 04An interactive globe versus a flat mapThe globe is the better first impression and depends on hardware acceleration that not every visitor has. Both were built, with the flat map as a real fallback rather than an error state.

• Owner independence over build speedThe admin panel is seven screens and a large share of the total effort, and none of it is visible to a visitor. It is the part that decides whether the site is still accurate in a year.
• Explicit URLs over clever defaultsCarrying the locale in the URL and refusing to auto-detect means a slightly longer address and a language switcher that has to be found. In exchange, every page has one canonical address, which is what makes four languages indexable rather than confusing.
• Domain accuracy over translation fluencyThe translation pipeline runs against a glossary that protects proper nouns, acronyms, and technical terms rather than letting them be helpfully rewritten. Slightly stiffer prose, terminology that a specialist reader still recognises.
• Plain answers over impressive chartsRefusing to interpolate gaps or invent composite scores means some views are emptier than they could be. For a research audience that emptiness reads as honesty, which is the asset being built.

Six phases across roughly four and a half months, each opening with an approved spec and closing before the next one started.

1. 01. FoundationDesign system, tokens, core routes, and the information architecture that every later phase was hung on.
2. 02. EditorialThe writing surface: article rendering, standardised navigation with breadcrumbs, and a nine-essay series pulled out of the general blog and given its own landing page, because a series buried in a reverse-chronological list is not discoverable as a body of work.
3. 03. InternationalisationSplit deliberately into two: routing and message catalogues first, then the translation pipeline. Roughly 1,100 message keys across 23 namespaces, in four languages.
4. 04. Data explorerThe interactive global health view, built under the credibility rules rather than around them.
5. 05. Search and answer enginesA recorded baseline, reproduced causes, deployed fixes, and structured data plus hreflang across all four locales, so the site is quotable by an answer engine and not merely crawlable.
6. 06. ResilienceTreated as design work, not cleanup. Sections isolated so one failure cannot take the page down, and a fallback behind the hero that deliberately depends on nothing.

On the search phase specifically: the starting position was recorded rather than assumed. A coverage export on 13 August 2026 showed 10 soft 404s, 10 pages with redirects, and 2 redirect errors, with all three validation runs failed. Each cause was then reproduced against the live site instead of guessed at. Five routes were shipping no top-level heading at all, because their lead heading had been written for the homepage where a second-level heading was correct. The homepage heading itself was malformed, carrying a typewriter cursor into the served HTML. Language redirects were answering as temporary rather than permanent, which keeps the old address in the crawl queue indefinitely. And the bare domain was resolving in three hops.

Seventeen public routes, each with one job, plus an admin surface the visitor never sees. The layers underneath:

The translation layer is the piece worth explaining. Each translated string is keyed by a hash of its English source, so editing the English automatically invalidates every translation of it rather than leaving four languages quietly disagreeing. An admin override always wins over the machine output, and every failure path returns English. A translation problem is allowed to look untranslated. It is never allowed to break a page.

The site also carries a small on-page assistant that answers questions about her work. It is assembled from live site content at request time rather than from a stale summary, so it cannot drift from what the pages actually say, and it is deliberately constrained: capped history, stripped control characters, and a house style rule that strips em dashes out of anything it produces.

The site is live in four languages. The owner publishes articles, adds gallery collections, and updates her CV through the admin panel without touching code or contacting me, which was the actual objective. Handover is a 30-chapter manual written in her language rather than a developer's, including a field-to-page map so she can see where any edit will surface.

On the search workstream, the remediation is deployed and the outcome is not yet in. Coverage validation runs take up to around 28 days, and the honest position today is that the fixes are live and the re-crawl has not reported back. The baseline was recorded precisely so that when it does, the movement is measurable rather than a matter of opinion.

Scope delivered and handover depth, rather than traffic figures. The search numbers above are a recorded starting point, not a result.

• ›The handover manual is part of the deliverable, not documentation debt. On a solo build for a non-technical owner it is the difference between a site and a dependency, and it should be scoped and estimated like any other phase.
• ›Non-goals protect a solo timeline better than goals do. Writing down what a phase is deliberately not doing is what stopped four languages from becoming five, and stopped the admin panel from acquiring its own translation project.
• ›Graceful degradation is a design decision. Deciding in advance what the page becomes when the hardware cannot render the nice version produces a considered fallback, where discovering it in production produces a blank rectangle.
• ›A fix that is live is not a fix that is confirmed. Search tooling reports on its own schedule, and a case study that claims the win before the re-crawl lands is a case study making things up.