My first website — and what I do differently since

This was family work, and I say so

My first website was not made for a stranger but for my father — his name is on the site. He is a real estate agent and rental specialist in Budapest, with a small portfolio, which for him is a principle: fewer mandates, more attention for each.

I do not hide this, because this is what makes it honest: here I learnt how a site comes together, what a business's shop window needs, and what questions a client asks — even when he asks them over dinner.

Why it was built from a ready theme

Real estate sites are a genre of their own: filtered listings, detail pages with parameters and galleries, featured offers, an agent profile. Building that from scratch as a beginner would have taken months — the off-the-shelf, industry-specific theme handed it over in days, bilingual support included.

The price showed later, and not all at once: the theme carries features the site never uses; its updates ask for caution, because much depends on them; and when I wanted something done differently, I ran into the wall of its settings. In a ready theme you are a guest, not the owner of the house.

The same question came up from another direction too: on an inherited website I did not choose the layers, yet their consequences stayed with me.

What this means if your situation is similar

If you run a one-person business and need a shop window fast, a ready theme is a decent first step — it was here too, and the site works to this day. The question does not come at the start but years later: who can maintain it, and what changing it costs.

For this site the answer was not one large switch but many small ones. I replaced the foundation underneath it in steps — while the design stayed exactly as it was from the start. For the client that is the important part: nothing moved on the visitor's side, and the work happened entirely below the surface.

The surface stayed the same; everything under it was replaced

The site runs on one custom theme with no plugins. That matters because every plugin updates on its own schedule, and any one of those updates can break something it has no apparent connection to. Where there is a single component, that risk does not arise.

The database has twelve tables, and all twelve are in use. The media library holds the real photographs with no generated duplicates — three of WordPress's six image sizes are switched off, because the theme does not use them.

The visitor downloads one stylesheet and one script, 31 and 10 KB compressed, with no jQuery.

This page said above that in a ready-made theme you are a guest, not the host. Here the other side of that is true as well: the code on the site is mine. That is what makes a fault visible where it is, and what keeps a fix from depending on someone else releasing an update.

That the design really did stay the same is not something I judged by eye — I measured it. One tool walks the page and writes out, property by property, what the browser actually renders: colour, font size, line height, weight, margin, corner, alignment. A second one pairs up the elements of the old and the new version and lists every difference between them.

On the last run the listings archive had zero differing elements, the home page one (a paragraph wrapping in three lines instead of four), and the property page two — two box titles are inline elements on the old version and blocks on mine, which look identical. No difference in colour, font size, line height, weight, margin, corner or alignment remained on any page.

Two differences remain on purpose, and both are places where the old version was broken. On its subpages the header had grown to 672 pixels tall because of an unconstrained 569-pixel logo; on mine the same 140-pixel header runs on every page. And the featured carousel on the home page stood empty, because the old theme's slider never initialised — there is a real card there now.

Every build of mine starts from there: as few foreign parts as possible, and what can be, fitted to the situation the site actually works in.

What the industry theme provides under the hood

The core of a real estate theme is the property as a data type: price, floor area, rooms, location, status — and every interface builds on it. The listing filters on these, the detail page displays them, the “featured offer” selects from them. This is what would have been hardest to design well as a beginner, and the theme provided it ready.

The same core explains its weight: the theme does not know it serves a one-person rental specialist, so it also ships the parts meant for large agencies — agent teams, mortgage calculators, subscription packages. These do not show, but they are there, they load, they update.

One cause of the fragility: the same field in four places

An audit traced back to a single cause what I had experienced as many small annoyances. A property field — floor area, say — lived in four places at once: in the theme's field-builder table, in the page-builder template, in the theme's PHP, and in the translation dictionary. Renaming it could break all four, and only one of them would say so.

On the new site one PHP array describes every field: key, Hungarian and English label, type, allowed values, unit, whether it is filterable, icon. From it the editor screen, the saving and validation, the property detail sheet, the filter bar, the structured data sent to search engines and both languages are generated. Adding a field is six lines, in a single file.

The difference shows up in maintenance time. On a site with twenty-five components the first half of any debugging session is not about the fault — it is about which foreign part changed. If I wrote the code, that round is skipped.

How to prove the design did not change

When the foundation under a site is replaced, the client's first question is rightly whether it will still look the same. “I looked at it and it’s fine” is not an adequate answer: a four-pixel margin or a shade of grey does not stand out one at a time, but in twenty places it is a different page.

So two tools were written for it. One measures the page: in a real browser it walks the elements and writes out, property by property, what the browser actually renders. The other pairs up the elements of the old and the new version and lists every difference at once, grouped by property — no hunting them down one by one.

Pairing goes by visible text, with two refinements. Relative vertical position is needed because the same phone number appears in both the header and the footer — without it, a header element would have been compared against a footer one. Matching element type is needed because a menu item would otherwise have paired with a page title carrying the same words.

Two false positives had to be filtered out as well. In a left-to-right language, start and left alignment are the same thing. And the old version referenced a font name that does not exist, which the browser drew in its default sans-serif — visually identical to what the current stylesheet asks for.

$ tools/measure.py <url> measurement.tsv
$ tools/diff.py old.tsv mine.tsv

listings archive   0 differing elements
home page          1  (a paragraph wraps in 3 lines instead of 4)
property page      2  (two box titles inline vs. block, identical appearance)

The upload, which is a daily operation

This site has one daily operation: publishing a new listing. The old interface left that to WordPress defaults, and here those defaults were misleading. A listing has exactly one status, one type and one district; WordPress offered these in four separate boxes as checkbox lists, where two could be ticked, and scrolling twenty-three districts was tedious.

They are dropdowns now, and they sit where they belong. What genuinely can be plural — jacuzzi, alarm, sauna — stayed a checkbox. Required fields carry an asterisk but deliberately not browser-level validation: a half-finished listing has to be saveable as a draft, and browser validation would block that save too. Instead a box at the top of the sidebar lists what is still missing — it does not forbid, it shows.

Two operations were worth the work on their own. Coordinate lookup from the address: until then the coordinates had to be copied by hand from the map, which was the most common place to mistype — and a wrong coordinate puts the map in a different part of town. The request goes from the server, not the browser, so no external request leaks onto the visitor-facing side. And duplicating a listing: one building often has several flats to let with mostly identical data, so the duplicate carries every field, the gallery and all three classifications across, as a draft.

The parts that are not obvious

Bilingual support was the best buy here

The site runs in Hungarian and English — in rentals, the foreign tenant is not an exception but a target audience. The theme and the translation tooling worked together out of the box, and that is the part I still call a good decision: adding a second language later hurts far more than switching it on first.

Your first client teaches you the questions

A family commission differs from a stranger's in that the questions are blunter and more frequent. This is where I first heard “why does changing this take so long?” — and looking for the answer taught me that the number of layers is not a technical detail but a question of the client's wallet. Every site I have built since has fewer layers than this one.

Two faults in moving the content were caught by a number looking wrong

When the content was moved across, the gallery turned out to live in several rows: the image list sat in fifteen to twenty separate rows per listing, all under the same key. The first export therefore saved a single image per listing — 97 instead of 929. Nothing failed; the number simply did not add up. Sixty-one listings do not produce ninety-seven images.

With the coordinates, the old system wrote the zoom level next to the pair. The cleaner treated that as malformed, so nine out of sixty-one coordinates would have survived. The pattern now accepts the third number and drops it — not only for the migration's sake: a line copied off a map looks exactly like that.

The measurement lied while the cookie bar covered the content

The comparison between the old and the new site reported a match in places where there was in fact a difference: the consent bar sat on top of the page, and the measuring tool either could not see the elements behind it or saw them elsewhere. Since that came out the rule has changed: if a measurement gives a suspiciously good result, I check the instrument first rather than believing the reading.

Questions about this project

Summary

My first website was built for my father's real estate business in Budapest — a rental specialist with a small portfolio — and this page says so openly: a family commission, the work I learnt the craft on. The site was built on an off-the-shelf, industry-specific WordPress theme, which delivered listings, search, detail pages and bilingual support within days; its price showed later, in the weight of unused features, delicate updates and the walls of its settings. The site is live and works in two languages. The design is the same as on day one; what sits underneath it I replaced step by step, and it now runs on a custom theme with no plugins. That the appearance really is unchanged is shown by measurement: on the last comparison the listings archive had zero differing elements, the home page one and the property page two, with no difference in colour, font size, line height, weight, margin, corner or alignment left on any page. The core of its custom behaviour is a single PHP array: from it the editor, the validation, the detail sheet, the filter, the structured data and both languages are generated. Its most lasting lesson is in every later work of mine: fewer layers, because the number of layers ends up being a question of the client's wallet.

← All case studies