Build note 002 / 30 September 2026

The website was live. The system around it was not.

By Fahad Younis

A website can load in a browser and still be unfinished.

That was the state of fahadyounis.com. The domain existed, but it redirected to Podcast Growth Studio. The personal site existed separately as a working build. The design was ready. The surrounding system was not.

The remaining work looked small: point the domain at the new site and publish it.

It was really a problem of ownership, separation, recovery, and proof.

Diagram showing the domain, Cloudflare DNS, live static site, and private source backup.
The public page is one part of the system. DNS, deployment, and recoverable source each have a separate job.

The first rule was simple: do not disturb the working business.

Podcast Growth Studio already had a live website, active traffic, and its own Cloudflare setup. The personal site needed to move without changing any PGS route, deployment, or DNS record.

That constraint shaped every decision.

The personal site received its own static deployment. The domain received its own Cloudflare zone. The old redirect records stayed in place until the nameserver change was confirmed. The PGS project remained untouched.

This slowed the process down in useful ways. Each step had one job, and each change could be checked before the next one began.

DNS is part of the product.

The confusing part was not the code. It was deciding which system controlled the domain at each moment.

GoDaddy was the registrar. Its forwarding screen still showed the old redirect. Cloudflare became the authoritative DNS provider after the nameserver change. Once that happened, deleting the forwarding rule inside GoDaddy was no longer the important action. The live result depended on the DNS records inside Cloudflare.

The sequence that worked was:

  1. Add the domain to Cloudflare.
  2. Copy Cloudflare’s assigned nameservers into GoDaddy.
  3. Verify the nameserver change through public DNS.
  4. Remove the imported redirect records from Cloudflare.
  5. Connect the root domain to the new static site.
  6. Add the www hostname separately.
  7. Test both addresses from outside the dashboard.

The dashboard was useful, but public DNS and live HTTP responses were the evidence.

A deployment is not a source backup.

Cloudflare had a working copy of the website. That did not make it the source of truth.

The site source now lives in a private GitHub repository. Dependencies, generated output, local QA files, deployment archives, and Cloudflare’s local configuration are excluded. The repository contains the files needed to understand, rebuild, and improve the site.

That distinction matters. A deployed site can prove what is online. It does not automatically preserve the clean project that produced it.

The old deployment also stayed available during the move. It was a rollback option until the custom domain served the correct site.

Performance needed measurement, not a feeling.

The first version was already small, but the largest image was heavier than it needed to be on a phone.

I added responsive image variants, long-lived caching for static assets, and less rendering work below the first screen. The visible design stayed the same.

A live Chrome audit measured the homepage across three mobile runs and three desktop runs. The median results were:

These are lab measurements from one location, not field data from real visitors. They confirm that the current build is lightweight. They do not predict every network or device.

The broader QA covered seven pages at desktop, mobile, and narrow-mobile widths. It found no broken internal links, no horizontal overflow, no missing page headings, no failed images, and no WCAG A or AA violations in the automated scan.

Small controls can become public clutter.

During development, the site included a visible motion switch. It was useful while comparing animation behavior. It did not need to remain part of the public interface.

The switch was removed. Motion remains enabled by default. Visitors who prefer reduced motion still receive the reduced experience through their operating-system setting.

That is a small example of a larger rule: a tool used to build or test a product does not automatically belong in the product.

The finished thing is the system that keeps working.

The site is now more than a set of pages.

The domain has a clear DNS owner. The personal deployment is separate from PGS. The source has a private backup. The public routes have been checked. The performance claims have measurements behind them. The recovery path exists before it is needed.

None of this is the exciting part of a personal website. It is the part that makes the website dependable.

The next step is not another redesign. It is using the site for the work it was built to hold: practical notes about AI systems, production decisions, and the gap between an idea and something that works.

All build notes ↗