Case study · A project that never concluded

The finished site that never went live

Finished, paid for, maintained for a year — and it never reached the live address. Three years, two long pauses.

The situation
A market research firm had a website, but it had aged. A new one was needed: a more current look, an ordered service structure, two languages — without downtime, because the old site was working.
What I did
Hosting migration, a full build on a development subdomain alongside the old site, legal documents, content transposed from a presentation, then a year of maintenance.
The outcome
The site was finished and paid for, but never went live: the client ceased to exist as an independent company and the contract ended. The old site ran undisturbed throughout.

The work in numbers

Key facts of the project
PeriodMarch 2023 — summer 2026
Longest pauseseveral months
Where it was builton a dev subdomain, beside the old site
Maintenance12 months, under contract
Alongside6 Google Sites microsites
Fate of the sitefinished, paid for — never published
Project
market and data research
Role
Migration, build, legal documents, maintenance
Engagement
Contracted build + 12 months maintenance
Three years, two long pauses A timeline with six events. Spring 2023: template selection, hosting migration and the developer subdomain. Summer 2023: the first round of feedback. Then a long pause. 2024: finalising; autumn 2024: contract and invoicing; then twelve months of maintenance across 2024 and 2025. Then another long pause. Summer 2026: the client ceased to exist as an independent company, and the site never went live at its own address. The axis is dashed at both pauses. spring 2023 Template, hosting, dev subdomain summer 2023 First round of feedback long pause 2024 Finalising autumn 2024 Contract and invoicing 2024—2025 Twelve months of maintenance long pause summer 2026 The site never went live the client ceased to exist on its own
Every stage ran; the closing one did not. Both pauses show on the axis — they took the larger part of the three years.
  1. 01 Template, hosting, dev subdomain spring 2023
  2. 02 First round of feedback summer 2023
  3. 03 Finalising 2024
  4. 04 Contract and invoicing autumn 2024
  5. 05 Twelve months of maintenance 2024—2025
  6. 06 The site never went live the client ceased to exist on its own summer 2026

The chain broke in two places — a long pause between summer 2023 and 2024, then again between 2025 and 2026.

Who did what

On the client side one person held the creative work together, and another arrived with concrete design and structure ideas. My job was to build them. That split worked well: I did not have to invent how the site should look — I had to make it, and to say where the idea met a technical limit. At the start several people shaped the direction.

Why it caused no harm

The site was built on a new. development subdomain rather than the live address, so the old website could keep working. The switchover would have been one planned step at the very end.

When the project never reached that step, this arrangement meant nothing visible happened: visitors saw the working site throughout, no half-finished work had to be taken down anywhere, and no mess was left behind. The same decision paid off on another project too, where the content was never written.

What stretched it: not the development

The work started in March 2023 and was broken by two long pauses. The longer one lasted several months: there was nothing to do on the build during it, as the next step needed a decision and content on the client's side. Word came in March 2024 that it could continue.

During the pauses the site stayed exactly where we had left it. This kind of waiting costs a developer little; it costs a business more, because nobody was getting the benefit of the new site in the meantime.

What this means if you are in a similar position

If you have a working website and are commissioning a new one, two things are worth fixing at the start. One is that the new site should be built at a separate address until it is ready — so there is no downtime and no half-finished state in public.

The other is stating who approves the final version. On this project comments arrived from several directions at one point, and I had to ask which to follow — I now settle that at the start of a project.

If you have an old website that needs replacing but you do not want to risk downtime or a half-finished public state, write a few sentences about where things stand. One exchange of emails usually shows how to schedule the switch.

kristof@kristofkarner.com
Technical detail

From here the details: the SSL ordering at install time, a typeface that does not speak Hungarian, the page builder's reverting global settings, and a loader that made a fast site look slow.

The order of the start

Choosing the host began with comparing two providers, then came the migration and the development subdomain. That is where I hit the first obstacle: I installed WordPress over https, because that was the clean approach — except SSL was not yet switched on at the host, so the admin interface was never created.

Issuing the SSL certificate, in turn, needed the hosting control panel, which I had no access to. The fix was a round of emails with the company's technical contact — but the lesson is about sequence: SSL is a precondition of the install, not the step after it.

The typeface that does not speak Hungarian

The client wanted to keep the display typeface from the old site. It turned out that the family contains no Hungarian characters, so Hungarian text cannot be set in it — the missing letters would cut holes in the words.

The choice does narrow at that point. I looked through a language-filtered typeface list for a family with a similar feel and Hungarian support, and that went onto the site. This is the kind of check that takes a minute at the design stage and becomes a brand question at the end.

What is not obvious

A global setting can revert

In the page builder the global typefaces and colours stopped surviving into the published version at one point: they looked right in the editor, and the public page came back with the old values. This is the kind of fault that does not announce itself with an error message, but with the client seeing something different from you — which is why you do not believe them at first.

A fixed-duration loader makes a fast site look slow

One piece of feedback was that the site loads for three to four seconds, then a static page appears that ought to render in half a second. The observation was accurate: the delay was not the loading but the fixed duration set on the opening animation — it played itself out even when the page had long been ready.

Motion effects collide with each other

The menu bar kept “stepping” on scroll for a long time. After several attempts it emerged that the motion settings were colliding: more than one plugin was writing rules for the same behaviour. The fix was to take the menu's animation out of that group and handle it separately.

An invoicing error the other side found

After the contract and the invoicing, the client's accounting flagged during VAT preparation that one item appeared twice across my invoices. They were right: starting out, I had miscounted the numbering. I settled it with a credit note. Since then I go through the issued invoices myself every month rather than leaving it to my accountant alone.

Questions about this project

Why can a website build stretch across years?

Rarely because of the development, usually because of the decisions. On this project the work started in March 2023 and was broken by two long pauses — the longest was several months, and word came in March 2024 that it could continue. During the pauses there was nothing to do on the build itself: the next step needed content, approval or an internal decision. What helps here is splitting the project into phases, each with an owner and a deadline.

What happens if a finished website ultimately never goes live?

If the build ran on a separate subdomain, nothing visible happens: the old site keeps serving visitors, and the new one stays where it was built. That is exactly how this project ended — the site was finished, paid for, kept under maintenance for a year, and then the client ceased to exist as an independent company and the contract ended. The fee for work done was unaffected, and the client never had to take a half-finished site off the live address.

Why build on a separate subdomain alongside an existing website?

Because the old site keeps running throughout, and the new one stays invisible until it is ready. On this project the build lived on a new. subdomain while the old site served visitors undisturbed — the switchover would have been a single planned step at the end. When the project never reached that step, this arrangement is what kept anything half-finished from going public. A subdomain creates no link to the main domain by itself: they share a name and a host, nothing more.

Whose feedback should a developer follow when several people say different things?

The person the client designates as the decision-maker — and if that has not been said, it is worth asking. On this project comments arrived from two directions at one point, so I said in writing that I did not know which to follow, and added my own recommendation to each item. The reply was reassuring, and the question has been part of my method ever since: at the start of a project we settle who approves the final version.

What should I check when choosing a typeface for a Hungarian-language website?

Whether the typeface contains the Hungarian accented characters — particularly the long ő and ű, which many popular families omit. On this project the display typeface from the client's previous site was to be kept, but it turned out to contain no Hungarian characters, so Hungarian text could not be set in it. The fix was a language-filtered typeface list, from which a similar-feeling family with Hungarian support went onto the site. This is worth checking at the design stage, because afterwards it becomes a brand question.

Summary

A market research firm's new website was built from March 2023: template selection, hosting migration, then a full build on a development subdomain so the old site could keep running undisturbed. The legal documents were completed, the content came from the company's presentation, and several obstacles were solved along the way: the ordering of the SSL certificate and the install, replacing a typeface without Hungarian diacritics, the page builder's reverting global settings, and a fixed-duration loader animation that made a fast page look slow. Two long pauses broke the work, the longer one several months. Autumn 2024 brought the contract and invoicing, then twelve months of maintenance, with six Google Sites microsites alongside. The site was finished and paid for; it never went live, because the client ceased to exist as an independent company in the summer of 2026 and the contract ended. Thanks to the development subdomain it closed without a trace: the old site worked throughout.

Kristóf Karner

Independent developer in Budapest. I ran this project myself — questions are welcome at the address in the contact section.

← All case studies