I run parkruns on Saturday mornings. I travel to places I've never been. I write code for a living.

Three interests. Almost no audience overlap. The runner reading my Eglinton parkrun report has zero interest in .NET anti-patterns. The developer reading about MVC architecture doesn't care about my split times. The tourist just wants to know if the hotel was worth it.

The obvious answer is three blogs. But I didn't want three blogs. I wanted one home for all of it. One place that says "this is me" without forcing every reader to wade through content that isn't for them.

So I built sections.

The Problem With the Obvious Solutions

When you have multiple interests and want to write about all of them, the standard options are:

Separate blogs. One for running, one for travel, one for tech. Clean separation, but triple the maintenance. Three domains, three deployments, three designs. And it fragments your identity. You're not three people, you're one person with range.

Tags and categories on one blog. The default. Every post lands in a single chronological feed, and readers filter by tag if they can be bothered. But the homepage becomes a mess. A parkrun course review sits next to a post about ADO.NET sits next to a travel story. The blog has no personality. It has three personalities fighting for the same space.

A portfolio site with a blog section. Fine if you're showcasing work, but it pushes the writing into a corner. The blog becomes an afterthought, not the main event.

None of these felt right. I wanted each interest to have its own front door, its own visual identity, its own space to breathe, but all under one roof.

Sections as Mini-Sites

The solution I landed on was sections. Each section is essentially a mini-site within the main domain:

  • The Athlete: running, cycling, and pushing limits
  • The Tourist: travel stories and adventures
  • The Technologist: code, builds, and engineering

Each one gets its own landing page, its own accent colour, its own RSS feed, its own author bio, and its own URL space. The Athlete is red. The Tourist is teal. The Technologist is steel blue.

The homepage isn't a chronological list of posts. It's a section chooser. Three cards, three doors. Pick the version of me you're interested in.

flowchart TD
    HP["Homepage — Pick a section"]
    HP --> A["The Athlete"]
    HP --> T["The Tourist"]
    HP --> TE["The Technologist"]

    A --> A1["Parkrun reviews"]
    A --> A2["Training data"]
    A --> A3["Race reports"]

    T --> T1["Travel stories"]
    T --> T2["City guides"]

    TE --> TE1["Architecture posts"]
    TE --> TE2["Build logs"]
    TE --> TE3["Code deep-dives"]

    style A fill:#e63946,color:#fff
    style T fill:#2a9d8f,color:#fff
    style TE fill:#457b9d,color:#fff

This means a runner who finds my Cuningar Loop parkrun review through Google lands in The Athlete. Everything around them (the accent colour, the sidebar, the related posts, the "next post" link) is running content. They never see a post about MVC unless they go looking for it.

And a developer who finds my architecture post lands in The Technologist. Same blog, completely different experience.

How It Feels to Use

The real test of any design decision is whether it changes behaviour. This one did.

When I sit down to write a parkrun report, I'm writing as The Athlete. The section isn't just a label. It shapes the voice. The Athlete is informal, self-deprecating, heavy on the "I arrived late again" energy. The Technologist is more analytical. The Tourist, once it gets some content, will be something else entirely.

Having separate sections didn't fragment my writing. It clarified it. Each section has its own author bio, which means I can describe myself differently depending on context. In The Athlete, I'm "a runner and cyclist from Kilmarnock." In The Technologist, I'm "a software engineer experimenting with AI tooling." Both true. Neither complete. Together, they're closer to the full picture.

The accent colours do more work than I expected. When you're reading a post and everything, the headings, the progress bar, the reaction buttons, is tinted red, you know you're in The Athlete without thinking about it. Colour becomes navigation.

The Crossover Episodes

Some posts don't fit neatly into one section. My HUB Leagues post, about building a fair handicap system for parkrun competition, is both an Athlete post and a Technologist post. It's about running and about the algorithm behind the scoring.

Rather than forcing a choice, posts can belong to multiple sections. One section is the "canonical" home, the one that determines the URL and the primary styling. The others get an "Also in:" link at the top.

flowchart LR
    POST["HUB Leagues post"]
    POST -->|canonical| ATH["The Athlete<br/>/the-athlete/hub-leagues/"]
    POST -->|also in| TECH["The Technologist<br/>(links to athlete URL)"]

    style ATH fill:#e63946,color:#fff
    style TECH fill:#457b9d,color:#fff

The post lives at one URL (/the-athlete/hub-leagues/) but it appears in both section landing pages. Readers in The Technologist see it listed alongside the architecture posts, and clicking through takes them to The Athlete's version. The content is the same, but the journey there is different.

In practice, most posts belong to one section. The crossover option exists for the exceptions, and it costs nothing when you don't use it.

Under the Hood

This section gets into how the build system implements sections. If you're here for the story rather than the code, feel free to skip to "What I Learned" below.

The entire sections system is driven by a single JSON config file:

// sections.json
[
  {
    "name": "The Athlete",
    "slug": "the-athlete",
    "description": "Running, cycling, and pushing limits",
    "accentColour": "#e63946",
    "order": 1,
    "bioText": "Alan is a runner and cyclist from Kilmarnock..."
  }
]

At build time, the pipeline reads sections.json and validates it. Every section needs a name, slug, description, accent colour, and sort order. Posts declare their sections in YAML frontmatter:

---
title: Cuningar Loop Parkrun
sections: [The Athlete]
category: parkrun
---

The build script validates every section name in every post against the config. A typo like [The Athelete] doesn't silently create a broken page. It fails the build with a clear error. That was a deliberate choice, config-plus-validation over auto-discovery. It's one more thing to get right, but it prevents the kind of silent failures that only surface when a reader hits a 404.

From there, the pipeline fans out:

flowchart LR
    CFG["sections.json"] --> BUILD["Build pipeline"]
    POSTS["Markdown posts"] --> BUILD

    BUILD --> HP["Homepage<br/>(section chooser)"]
    BUILD --> SP["Section landing pages<br/>(one per section)"]
    BUILD --> PP["Post pages<br/>(at canonical URL)"]
    BUILD --> CP["Category pages<br/>(per section)"]
    BUILD --> TP["Tag pages<br/>(per section)"]
    BUILD --> RSS["RSS feeds<br/>(global + per section)"]
    BUILD --> SI["Search index<br/>(all sections)"]

The accent colour is injected as a CSS custom property (--accent) into each page. Templates reference var(--accent) for headings, links, progress bars, and card borders. No per-section CSS files, no colour logic in templates. Just one variable that cascades through everything.

Adding a new section means adding one object to sections.json. The landing page, navigation links, RSS feed, category pages, tag pages, and homepage card all generate automatically on the next build. The first post you write with that section in its frontmatter populates it.

What I Learned

The biggest surprise was how much the sections changed my writing, not just my architecture. Having a clear home for each type of content lowered the friction of starting a new post. I never sit down thinking "what should I write about?" I think "I ran a parkrun, that's an Athlete post" or "I built a newsletter system, that's a Technologist post." The section is the first decision, and everything else follows.

The second surprise was how little code this required. The entire sections system (loading, validation, routing, landing pages, per-section listings, RSS feeds) is driven by one JSON file and about 200 lines in the build script. No database, no CMS, no framework. A flat config file and a few loops.

If I were starting over, I'd add section-level descriptions that are longer than a tagline. Something that could serve as an "about this section" intro on each landing page. Right now the landing pages jump straight into the post list, which works but feels slightly abrupt.

The broader lesson is about identity. When you have multiple interests and you're building a platform for yourself, the instinct is to either separate everything or lump it all together. Sections are the middle path. Unified identity, distinct spaces. One person, three front doors.

I'm building WaddingtonWrites, a personal blog with a custom Node.js build pipeline. Three sections, one dependency, zero frameworks.