← Launcher Hiking-Adventure.ch · Internal

Stack Analysis

What the site should be built on, and what each option actually costs. The brief set two requirements that pull against each other: the project must be handed over to any competent developer without ceremony, and the plugin churn that keeps breaking the current site has to stop.

Two constraints were added after the brief and both narrow the field usefully: only free plugins from the official directory — no licences, no subscriptions — and this stack is meant to be reused. It gets piloted here and then becomes the studio default, so it has to stay universal and portable rather than tuned to one client.

What we are judging against

Handover safety Could another developer take this over without us, and how large is the pool of people who can? Critical
Editing comfort How pleasant it is to add a tour, fix a date, swap a photograph — on the day, not in theory. Critical
Maintenance surface How many moving parts can break or need a security patch, and how loudly they fail. Critical
Longevity Will this still work in five years without a rebuild, and who has to keep it alive? High
Performance & SEO Speed on a phone, and full control over markup, structured data and hreflang. High
Running cost Hosting, licences and subscriptions — a real line in a one-person business. Medium

The options

WordPress + custom lightweight theme

Same WordPress the client already knows, but the page builder is gone. The layout is written as a purpose-built theme; content is edited through structured fields rather than free-form blocks.

Recommended
Arguments for
  • The largest pool of developers on earth — handover is a non-event, which is exactly what the client asked for
  • Familiar admin; no relearning where anything lives
  • Structured fields make wrong input hard: the stale-2025-dates problem stops being possible rather than being fixed by hand
  • Full control of the markup, so hreflang, structured data and Core Web Vitals are ours to get right
  • Runs on the existing hosting; no migration forced on day one
  • Content stays in a database the client owns outright, exportable at any time
  • No licences and no subscriptions — everything used is free and from the official WordPress plugin directory
Arguments against
  • Still WordPress: core and plugins need patching on a schedule, forever
  • The admin is functional rather than delightful — competent, never a pleasure to write in
  • Getting to near-zero plugins means writing in the theme what others install — more of our code to author up front
  • Popularity cuts both ways: the most-attacked platform on the web, so hardening is mandatory not optional
  • Needs real PHP hosting with backups — more to look after than a static host
Verdict. The least exciting option and the one that best survives contact with reality. It scores highest on the requirement the client named first — that anyone can take it over — and the plugin problem is solved by removing plugins, not by leaving WordPress. Editing comfort is its weak spot, and that is worth improving rather than escaping. See the plugin list below for exactly what stays installed.

Hosted headless CMS + static front-end

Content in a modern hosted CMS with a genuinely good editor and real content modelling; the site generated as static pages.

Viable
Arguments for
  • Editing experience far ahead of the WordPress admin — modern, fast, with real content modelling underneath
  • Multilingual content is a first-class feature, not a plugin bolted on
  • Nothing to patch: the vendor runs the CMS, the public site is static and has essentially no attack surface
  • Excellent performance and full markup control
  • Preview and draft workflows are properly solved
Arguments against
  • Smaller talent pool than WordPress — handover is possible but no longer trivial, and likely more expensive
  • A monthly subscription that grows with usage, and pricing is the vendor's to change
  • Vendor lock-in of a different flavour: content is exportable, but the modelling and integration are not portable
  • Two systems to reason about instead of one, which is more moving parts at handover even if fewer at runtime
  • Content changes need a build step, so publishing is not instant
Verdict. Technically the cleanest architecture of the four, and the nicest to write in. It falls behind on the two things that decide this project: how many developers can pick it up cold, and committing a one-person business to a subscription that only ever grows.

Static site with a git-based editor

Content as files in the repository, edited through a browser interface that commits on save. No database, no server-side application.

Viable
Arguments for
  • Cheapest to host and the most robust — there is almost nothing that can go down
  • Effectively nothing to hack: no database, no admin application exposed
  • Every content change is a commit, so history and rollback come free
  • Fastest possible site with complete markup control
  • Content is plain text the client owns — the most portable option of all
Arguments against
  • Editing feels least familiar; the mental model leaks technical concepts into everyday work
  • Rich content and image handling are noticeably clumsier than any real CMS
  • Publishing waits for a build, and a failed build is a confusing thing for a non-developer to face
  • Smallest talent pool of the four — handover is the weakest here
  • The editor layer is itself a dependency with a habit of changing shape
Verdict. The right answer for a site nobody edits often. This one is edited constantly — tours, dates, photographs, all season long — so the daily friction lands on exactly the person we are trying to help.

Keep the page builder

Redesign inside the existing Beaver Builder setup rather than replacing it.

Not recommended
Arguments for
  • Cheapest and fastest route to something that looks new
  • Nothing to migrate; the client changes nothing about how she works
  • Layout can be rearranged without a developer
Arguments against
  • Keeps every problem the client hired us to fix: the plugin stack, the update fragility, the security exposure
  • Builder markup is heavy and hard to audit — performance and SEO stay compromised by construction
  • The design gets bent to fit what the builder can express, rather than the other way round
  • Layout freedom is how the current site drifted into inconsistency in the first place
  • Locked to one product's roadmap and pricing indefinitely
Verdict. Listed so the decision is on the record, not because it is competitive. It treats the symptom and preserves the disease.

Side by side

Criterion WP + custom theme Headless CMS Static + git
Handover safety ● largest talent pool ● smaller pool ● niche skillset
Editing comfort ● functional ● very good ● technical feel
Maintenance surface ● patching forever ● vendor-managed ● almost none
Longevity ● two decades and counting ● vendor-dependent ● plain files
Performance & SEO ● full control ● full control ● full control
Running cost ● hosting only ● subscription ● lowest
Multilingual ● solved, needs care ● built in ● convention-based
The recommendation

WordPress with a purpose-built theme and effectively no plugins. It wins the criterion the client named first and unprompted — anyone can take it over — and it wins it by a distance no other option comes close to. The plugin problem is solved by removing plugins, not by leaving WordPress.

Its one real weakness is editing comfort, and that is the weakness we can actually fix ourselves. Most of the frustration people blame on WordPress comes from badly modelled content, not from WordPress: a builder page where every tour is hand-assembled is miserable, while a form with eight labelled fields takes a minute. Same platform, opposite experience — and the difference is entirely our design work.

The headless CMS is technically the cleaner architecture and the nicer place to write, and it stays the honest runner-up. It loses on the two things this particular client cares about most: a smaller pool of developers who could inherit it, and a subscription a one-person business carries forever.

Domain architecture — consolidate to one

Both names are the same descriptive brand translated, not a personal name: Wander-Erlebnis is German for "hiking experience" (wandern — to hike, Erlebnis — experience), and Hiking-Adventure is its English equivalent. This is a platform decision, not a marketing one — it sets the URL structure, the routing and the redirect map, so it has to be settled before the build starts.

One domain, /de/ and /en/

One site, one brand, language as a path segment. The second domain redirects permanently.

Recommended
Arguments for
  • Search authority compounds in one place instead of being split in half
  • One certificate, one DNS zone, one sitemap, one set of checks — permanently less to maintain
  • The brand finally has a single spoken name
  • Language switching becomes a routing problem we solve once, not a cross-domain hack
  • Adding Italian or French later is a third path segment, not a third domain
Arguments against
  • Whatever recognition the retired domain has built gets inherited through redirects rather than kept directly
  • Requires a complete, verified redirect map — the most common way a redesign loses rankings
  • A short ranking wobble while search engines process the move
Which one to keep. On reasoning, the German: the tours run around Zurich — Wädenswil, Horgen — in German-speaking Switzerland, the primary market, with English serving visitors. That points to wander-erlebnis.ch as primary. But decide on data. Pull Search Console and backlink figures for both first: if the English domain turns out to carry the authority, the answer flips. This is why Search Console access is a blocking item in the workflow plan.

Keep both domains, fixed properly

One install serving two domains, with correct reciprocal hreflang, x-default, and a sitemap each.

Only if asked
Arguments for
  • Keeps whatever each domain has already earned, with no migration risk
  • A keyword-matching domain per language, if that is felt to matter
  • Nothing to explain to anyone who already knows one of the addresses
Arguments against
  • Authority stays permanently split between two names
  • Every maintenance task is done twice, forever
  • No single brand name to say out loud
  • As built today it actively harms: no hreflang, no x-default, and German pages declaring lang="en-US" — search engines see two near-duplicates with no language signal
  • The exact-match-domain advantage this was presumably built for has largely evaporated
Verdict. Defensible only if the two domains served genuinely separate markets with separate marketing. They do not — one guide, one set of tours, two language versions of the same offer. Kept on the table because it is the client's call, and because doing it correctly is still far better than the current state.

If WordPress: what actually gets installed

Constraint set by the client: free plugins only, from the official WordPress directory — no licences, no subscriptions, no premium tiers. That is achievable, and it lands us in a better place than a paid stack would, because the honest way to hit it is to write in the theme what most sites install a plugin for. Fewer plugins is not a compromise here; it is the point.

Job How it is handled Cost
Tour fields & content model Secure Custom Fields — the official WordPress.org package, which includes the field types that used to be paid-only (repeaters, flexible content). Field definitions exported to the theme as code, so they live in the repository. Free · official
Tour listing & filters Theme code against the tour fields. No search-and-filter plugin. No plugin
SEO meta & structured data Theme code. Titles, descriptions, canonicals, Open Graph and schema.org output are a few hundred lines we control exactly — and no SEO plugin's opinions to fight. No plugin
XML sitemaps WordPress core has generated these natively since 5.5. Extend the core output rather than installing anything. Core
Enquiry form Theme code: core nonces for CSRF, server-side validation, honeypot plus timing check for spam, mail through the standard WordPress mail function. Roughly one file. No plugin
Two languages Polylang, free tier — it covers two languages, hreflang and a language switcher. The only genuinely unavoidable plugin on the list. Free
Tour map An open mapping library with no API key and no per-view billing, or a static image. Removes the broken-Google-Maps failure permanently. No plugin
Images & performance Core handles responsive images and modern formats; sizes registered in the theme. No optimisation plugin. Core
Instagram feed Replace the third-party plugin with a hand-picked gallery, or simply link out. Decision still open. No plugin
Backups Hosting-level or a scheduled job — not a plugin sitting inside the site it is meant to protect. Hosting
Two plugins instead of ten, and nothing to renew

That is the whole list: Secure Custom Fields and Polylang. Everything else is core WordPress or code in our theme, under version control, with a history and a rollback. Compare with what runs the site today — a page builder, its add-on pack, a conditional-logic extension, a search-and-filter plugin and its builder bridge, a post-display plugin, an iframe plugin, an Instagram plugin, a statistics plugin and a webfont kit. Every one of those is an update that can break and a vulnerability that can be disclosed.

The trade is honest: less plugin risk, more of our own code. That code has to be written well and documented, because it is what the next developer inherits.

Built once, reused after

This project is the pilot. The point is not only to ship one good site but to come out of it with a stack the studio can put on the next project, and the one after — so the second build starts at week three instead of week one. That ambition changes what "best" means: the winner is not the cleverest option, it is the one that stays boring, portable and free across many different clients.

Nothing to renew No licence, subscription or seat cost travels with the stack, so it can be reused on any budget without a recurring line item.
Runs anywhere Standard PHP hosting is available from every provider in every country. No client is ever forced to move host to accept our work.
Same shape every time Content model, field definitions, SEO output and form handling become a starter theme. Each project changes the design, not the machinery.
Fixes travel A bug found on one project is fixed in the starter and rolls forward. Every project makes the next one better instead of starting from nothing.
Any client can take it Works for a one-person business and for a company with its own developers, without changing platform.
No single point of failure No vendor can raise a price, change an API or shut down and take a portfolio of client sites with them.
Why this option, specifically, is the reusable one

The reuse goal settles the question more firmly than the single-project view did. A hosted CMS is pleasant on one project and a liability across ten: every client inherits a subscription, and one pricing change hits the whole portfolio at once. A static-plus-git setup is superb for brochure sites and wrong for anything a client edits weekly, so it could never be the default. WordPress on standard hosting is the only option here that fits every client we are likely to take, with no vendor able to change the terms underneath us.

The near-zero-plugin approach is what makes it reusable rather than merely familiar. The value we accumulate is our own code — the content model, the SEO output, the form handler, the build setup — and that is portable across projects in a way a particular assortment of installed plugins never is. Plugins have to be re-evaluated per project; our starter theme just gets copied.

Concretely, what should come out of this project: a starter theme with the build tooling and the deployment path already wired, a content-model pattern that adapts from tours to any other repeating entity, SEO and structured-data output ready to extend, a form handler with validation and spam protection solved once, and a launch checklist proven on a real site. That belongs in the studio templates alongside the existing playbooks, not in this project folder.

Internal working document · decision pending · see the Workflow Plan for the open questions this depends on