We started from templates and built without one

The template question the client asked

The work started with a template shortlist: I sent over a few sites I found more distinctive than average. Their question back was precise, and it decided the direction of the project — they asked what is fixed in a template, what cannot be changed.

The answer turned out to be nothing. Nor did they have to choose one template: collect what you like from each, and I will assemble a single coherent version from that. Where there is no instruction, I either improvise or ask along the way.

In the end not one template made it in. What is being built is a custom theme — the templates stayed in only insofar as they showed what the client likes.

The domain did not have to be moved

The site sat with an earlier provider, together with the company mailboxes. I looked into it and concluded that the domain did not need moving: a development subdomain with an A record pointing at my server was enough. The main domain's settings stayed as they were, email kept working, and no new contract was needed.

The client's own systems administrator set it up, from a request written out point by point in the client's own email. Moving a domain tends to be the developer's convenience rather than a technical necessity.

What this means if you are in a similar position

If you want a one-page introductory site, a page builder gives little: there are no many subpages to maintain, and in exchange it puts layers underneath. With a custom theme the result is exactly what we agreed on, and an editable part can still be added later where it is actually needed.

And if you are changing developers: ask why anything would have to be moved. Often it does not, and disturbing a working email system is the most expensive part of a step that can be skipped.

The size of the build

$ find . -name "*.php" -not -path "*/vendor/*" | wc -l
      30
$ cat $(find . -name "*.php" -o -name "*.css" -o -name "*.js" | grep -v vendor | grep -v rough.min) | wc -l
    7301
$ grep -c "=>" inc/strings.hu.php inc/strings.en.php
inc/strings.hu.php:143
inc/strings.en.php:143

Two languages without a plugin

Multilingual plugins bring a large system with them: their own database structure, their own editing interface, their own upgrade risk. On an eight-section one-page site that is more weight than it removes.

Instead the texts live in two PHP files with identical structure, and 14 custom rewrite rules handle the addresses: the /en/ prefix switches to English, and the legal subpages have their own English addresses. The two string sets are identical, at 143 keys — if one goes missing from either, the comparison shows it.

The English legal addresses had to go before the general ^en/(.+?) pattern in the rule list. Placed after it, WordPress would have tried to resolve them as page names and would not have found their template.

The legal pages build

The imprint, the privacy notice and the cookie notice are not hand-written HTML. Each is generated from a configuration file and a Markdown template, in both languages, from a single source. The company data lives in one place; the Hungarian and the English version come from the same origin.

The generation passes through two gates, and if either one stops it, no output is produced:

1. Placeholder gate. If any unfilled placeholder is left in the template, the run exits with an error code.
2. Statutory gate. The configuration lists all eight points of the imprint section of the Hungarian e-commerce act. Each point carries either proof — configuration paths whose values must appear verbatim in the finished text — or a justification for why it does not apply; and that justification has to reach the page too.

Of the eight points, six carry proof and two are closed with a justification. The reason this is worth it: an imprint tends to be silently incomplete. It renders neatly, it looks right, and meanwhile the hosting provider is missing from it — precisely the item most people forget. So putting the data in the configuration is not enough: if its place is left out of the template, the build fails.

1. 01 Data + template
2. 02 Two gates
3. 03 Finished text
4. 04 1. unfilled placeholder if any is left, the run stops
5. 05 2. the eight statutory points proof or justification, verbatim

single source · stops → no output · Hungarian and English

The map was not waiting to be drawn

There is a map in the contact section. The first version behaved so that after scrolling stopped it stayed a motionless grey box for 1.3 to 3.4 seconds. It would have been natural to blame the browser's main thread.

The measurement said otherwise. Of the 1,550 milliseconds it took to come up, only 165 fell on the main thread; the rest was network waiting, because the thirteen requests to the tile service only started once the visitor had already arrived. The single slowest request was the font set, at 730 milliseconds.

The fix was not speeding things up but moving them earlier. The connection to the tile service is established at page load, and a warm-up step pulls the style, the sprite and the fonts into the browser cache during idle time, after loading. The map itself still only builds when the visitor comes near it.

Measured: dead time fell by 60 per cent on desktop and 31 per cent on mobile, at zero extra main-thread cost — the warm-up is a network operation, not drawing.

What is not obvious

The cookie banner currently gates nothing

Replacing the map provider removed the last element on the site requiring consent, so the cookie plugin would not have shown the banner by itself. The client decided it should stay, because measurement or advertising may come later.

That is a defensible decision, but the code records that the banner currently gates nothing, and exactly what has to be deleted once measurement arrives. On another site the same question led to the opposite answer — this site has no banner, because there is nothing to consent to.

Where the plugin loads, it is already too late

Forcing the banner did not fit in the theme. The cookie plugin creates its banner loader as it starts up, and the theme runs later than that. The setting therefore went into a separate module that loads earlier — and since it is not in the theme, a theme update does not carry it, so it has to be installed separately on the live site. This is the kind of dependency that tends to surface at handover.

Two designs, one of them archived

Two complete versions of the design were made, and for a while both were reachable at their own addresses — so the client chose by comparing working pages, not descriptions. After the decision the older version did not go in the bin: its files stayed in the codebase, they simply no longer load. Eight sections sit in that archive.

Questions about this project

Summary

A bilingual one-page website for a Budapest research firm trading since 2003 has been in the making since June 2025. The client asked for anchor navigation that looks like a menu, with their own visual identity; we started from a template shortlist, but the answer to their question — what is fixed in a template — was that nothing is, and in the end not one template made it in. What is being built is a custom theme: 30 PHP templates, 7,301 lines, eight sections, no page builder. The two languages run on 14 custom rewrite rules and two string files of identical structure, 143 keys each, rather than a multilingual plugin. The three legal subpages are generated from a configuration file and Markdown templates through two gates: an unfilled placeholder, or a missing proof for one of the eight statutory points, and there is no output. The contact section's map stall turned out on measurement to sit on the network rather than the main thread; with an early connection and a warm-up the dead time fell by 60 per cent on desktop. The domain did not have to be moved: the work runs on a subdomain, and the live site and the company email are untouched. The first complete design went over in July 2026; the content is being finalised.

← All case studies