How I generate the social stats on this site

The numbers on the homepage are not typed in by hand.

They are generated during the build, written to a local data file, and then rendered like any other part of the site. That keeps the homepage honest without turning it into a live dashboard that can fail every time a platform API has a bad day.

The goal

I wanted a simple way to show a few useful social signals:

• views
• hours watched
• likes
• shares
• followers

The point is not to obsess over vanity metrics. The point is to show that the content is reaching people and that there is some real-world traction behind the work.

Why I do it at build time

This site is static. That is a strength.

If every page request had to call out to third-party APIs, the homepage would become slower, more brittle, and harder to deploy. Build-time fetching avoids that.

The flow is simple:

1. A script runs before astro build.
2. It fetches the latest stats from the platforms I care about.
3. It normalises those values into one small JSON file.
4. Astro renders that file into the homepage.

If the APIs are unavailable, the build does not collapse. The script can fall back cleanly rather than taking the whole site down with it.

Where the data goes

The generated values are written into a small file in the project and imported like normal content data.

That means the homepage component does not need to know anything about platform APIs. It only needs a predictable shape:

[
  { "label": "Views", "value": 184000, "format": "compact" },
  { "label": "Hours watched", "value": 4200, "format": "compact" }
]

That separation matters. The fetch logic can evolve without forcing the homepage markup to change every time.

Why this is better than typing numbers in manually

Manually updating social proof is one of those tasks that sounds simple and then never happens consistently.

The usual result is one of these:

• the numbers become stale
• they quietly disappear
• they get exaggerated because nobody is checking them carefully

An automated build step is a cleaner middle ground. It is not live, but it is current enough to be useful and low-maintenance enough to keep.

The tradeoff

Build-time stats are not real-time stats.

If a video takes off this afternoon, the homepage will not know until the next deploy. That is a perfectly acceptable tradeoff for this kind of site. I care more about reliability and clarity than shaving a few hours off freshness.

The main point

This is the same principle I apply elsewhere: keep the system as simple as it can be, but no simpler.

The homepage gets useful proof. The site stays static. The content stays easy to maintain.

That is usually a better outcome than bolting on something “live” just because it sounds more advanced.