DEV Community: Richard Lemon

Schema.org markup and entity recognition in 2026

Richard Lemon — Fri, 06 Nov 2026 10:55:26 +0000

Treating the site as data, not just pages

In 2026, the SEO work that mattered most for Aftertype was treating the site as data instead of just a collection of pages. Concretely, that meant site-wide schema.org markup and a companion llms.txt file, so both classic search engines and AI systems could understand what the site is, not just what it says.

From impressions to entity recognition

Before structured data, Search Console made Aftertype look like a pile of pages and keywords. Impressions went up and down, clicks were fine, and the query mix was a foggy blend of terms that roughly matched the content.

After rolling out structured data across the site, the interesting change was how the site appeared inside Google’s own model of the world. Queries started clustering around Aftertype as an entity, not just as text on a page. Search Console made it clearer that the site was being treated as a thing in the graph, not just a set of strings.

What actually went into the markup

The work was not magic. It was mostly tedious, careful markup across three main types: Organization, Article, and FAQPage.

Organization schema

First step: describe Aftertype as an Organization. That meant being explicit about:

Official name
URL and logo
Contact details
sameAs links to profiles elsewhere

This is the base layer. Without it, every other piece of content floats around without an owner. With it, articles and FAQs can all point back to a single, stable entity.

Article schema across the site

Next step: treat each significant piece of content as an Article instead of a generic page. That meant marking up:

headline and description
author, publisher, and datePublished
mainEntityOfPage to connect the article to the canonical URL

This is boring, mechanical work, but it gives search engines a clean graph: this organization publishes these articles, on these topics, at these times.

FAQPage schema where it actually fit

FAQPage schema only went on content that was genuinely question and answer shaped. Each question and answer pair was marked up as Question and Answer inside a FAQPage.

The goal was simple: give both search engines and AI systems a clean, structured set of canonical answers for recurring questions, instead of scattering them across loosely formatted paragraphs.

llms.txt: a companion for AI search

Alongside the Schema.org work, Aftertype added a companion llms.txt file. Classic search engines read robots.txt to understand what they can crawl. AI-focused crawlers and LLM-backed search tools need a similar pointer, but with extra hints about what is actually useful for training or retrieval.

Where Schema.org describes the structure of each page, llms.txt describes which parts of the site are high signal, canonical, or stable enough to be worth ingesting. Together, they act as two halves of the same idea: one for traditional SEO, one for AI search.

GEO vs SEO in 2026

By 2026, the line between SEO and what you might call GEO (graph or entity optimization) is very visible.

SEO is still about ranking pages for queries.
GEO is about making sure you, your company, and your content exist as clear entities in the graph that search engines and LLMs use.

The Schema.org and llms.txt work for Aftertype sat squarely in the GEO bucket. Instead of chasing another round of on-page tweaks, the focus was on telling machines:

“This is the organization behind this site.”
“These are the articles and what they are about.”
“These are the canonical answers to recurring questions.”

Once that graph was in place, traditional SEO metrics started to look different. Branded and related queries clustered more logically, and Search Console began to look less like noise and more like a map of how the entity was understood.

What changed in Search Console

After deploying structured data site-wide on Aftertype, Search Console results shifted in a few ways that matched the GEO focus:

Queries tied more clearly to the organization name and core topics, instead of random long-tail matches.
Branded and entity-like queries became easier to track as a coherent group.
Rich results and enhanced snippets aligned more cleanly with marked-up FAQs and articles.

This was not about a viral spike or overnight doubling of traffic. It was a change in how the site was categorized and presented, and in how new content slotted into an existing entity graph instead of starting from zero each time.

Why this beat other SEO habits in 2026

Most SEO activity in 2026 feels like tuning a radio station that keeps changing frequency. Algorithms shift, SERP layouts change, and AI overviews eat more of the page. The Schema.org and llms.txt work for Aftertype targeted a slower-moving layer: how the site is modeled as data.

Instead of guessing which micro-optimizations might please the latest search experiment, the work focused on:

Making the organization unambiguous as an entity
Making each article unambiguous as a piece of content
Making FAQs unambiguous as canonical answers
Making AI crawlers unambiguous about what to read and reuse

That combination turned a loose collection of pages into something closer to an API for both search engines and LLMs. The payoff showed up less as raw volume and more as recognition.

If you only do one thing

If you are deciding where to spend limited SEO time in 2026, a simple order of operations looks like this:

Implement solid Organization schema site-wide.
Mark every significant content piece as an Article with proper metadata.
Use FAQPage schema only where the content is truly question and answer shaped.
Add an llms.txt file that points AI crawlers at your best, most stable content.

Everything else can wait. Entity recognition is the part that actually sticks.

Deriving a Ghost theme palette from one accent color

Richard Lemon — Wed, 21 Oct 2026 18:11:04 +0000

The constraint: Ghost gives you one color

Ghost themes get exactly one brand color from the admin: --ghost-accent-color. That value often needs to carry most of the UI: links, buttons, hovers, subtle backgrounds, borders.

You can add more theme settings, but it is possible to treat that single accent as the source of truth and derive everything else in CSS.

With one custom property in package.json, the theme can generate tints, hover states, borders and soft backgrounds using color-mix() and, where helpful, oklch(). No extra admin fields are required.

Starting point: normalize the accent color

Ghost exposes the accent color as --ghost-accent-color on :root. A simple first step is to mirror it into a small set of semantic tokens so the rest of the CSS never touches the raw accent directly.

:root {
  /* from Ghost admin */
  --ghost-accent-color: #ff1a75;

  /* base semantic tokens */
  --accent: var(--ghost-accent-color);
  --accent-text-on-solid: #fff;
}

--accent is the only color that is really “brand”. Everything else hangs off it with color-mix().

Using color-mix() for hover and focus states

A straightforward use is hover states. For buttons and links you can create a slightly stronger accent on hover without guessing a separate color.

:root {
  --accent-strong: color-mix(in srgb, var(--accent) 85%, black);
}

.button-primary {
  background: var(--accent);
  color: var(--accent-text-on-solid);
}

.button-primary:hover,
.button-primary:focus-visible {
  background: var(--accent-strong);
}

This works well for mid-range colors, but it can break down at the extremes. A very dark accent mixed toward black barely changes. A very light accent mixed toward black can jump too hard and fail contrast against white text.

Very light and very dark accents

Two cases tend to cause trouble:

Almost-white accents, like #fbe9ff or very light pastels.
Almost-black accents, like #050505 or deep navy.

With almost-white accents, Ghost often pairs them with dark text, not white. If you always use --accent-text-on-solid: #fff and darken the accent on hover, the background can still end up with too little contrast against white text.

With almost-black accents, mixing toward black on hover does very little visually. The button looks unchanged.

Instead of assuming the accent is a normal mid-tone, it helps to reason about it in oklch().

Using oklch to reason about lightness

oklch() exposes a lightness component that behaves more linearly than srgb. That makes it easier to decide two things:

Should text on the accent be light or dark?
Should hover move the accent lighter or darker?

First, convert the accent to oklch() in a custom property. Browsers can do this conversion implicitly:

:root {
  --accent-oklch: color-mix(in oklch, var(--accent) 100%, black 0%);
}

Then derive lighter and darker variants by nudging the lightness channel via mixes toward black or white.

:root {
  /* Slightly darker for hover, slightly lighter for subtle backgrounds */
  --accent-strong-oklch: color-mix(in oklch, var(--accent) 90%, black 10%);
  --accent-soft-oklch:   color-mix(in oklch, var(--accent) 90%, white 10%);
}

These are still oklch-space colors, but the browser returns them as usable CSS colors. For many accents this gives smoother steps than mixing in srgb, especially for saturated colors.

Choosing text color based on accent lightness

Ghost itself decides whether to use light or dark text on the accent in some places, but inside a theme it is useful to have a consistent rule. Accents above a certain lightness can be treated as “light backgrounds” and use dark text on them.

There is no native if() in CSS yet, so a practical approach is to define two modes in the theme, then switch modes based on a class that is set server-side or through a small script that inspects the computed accent color.

:root {
  --accent-text-on-solid: #fff;
}

.theme--accent-light {
  --accent-text-on-solid: #111;
}

A script can read getComputedStyle(document.documentElement).getPropertyValue('--accent'), convert it to oklch() using a helper, and toggle .theme--accent-light if the lightness is above a threshold. Extremely light accents then flip to dark text, and the hover and active colors derived from oklch stay on the right side of the contrast line.

Subtle backgrounds and borders from the same accent

For cards, badges and inline highlights you can use the accent to create a soft background and a slightly stronger border.

:root {
  --accent-bg-soft: color-mix(in oklch, var(--accent) 12%, white);
  --accent-border-soft: color-mix(in oklch, var(--accent) 45%, white);
}

.badge {
  background: var(--accent-bg-soft);
  border: 1px solid var(--accent-border-soft);
  color: var(--accent);
}

For very dark accents, mixing toward white like this keeps the badge readable without turning it into a loud block. For very light accents, the badge is barely tinted; the accent still shows up in the border and text.

The same pattern works for focus outlines:

:root {
  --accent-outline: color-mix(in oklch, var(--accent) 65%, white);
}

:focus-visible {
  outline: 2px solid var(--accent-outline);
  outline-offset: 3px;
}

Checking contrast without designing per brand

Because the accent is user-controlled, you cannot guarantee perfect contrast for every possible color. You can only make it harder to get into trouble.

A practical approach is to test a small grid of accent colors locally:

Very light pastel
Mid-tone brand color
Deep saturated color
Near-black

For each, check a few key pairs in a contrast checker:

--accent vs --accent-text-on-solid
--accent-bg-soft vs body text
Focus outline vs page background

oklch-based mixes help keep these pairs within acceptable ranges for normal accents. Extremely low-contrast choices from the admin, such as an almost white accent on a white site background, will still be low contrast, but the theme does not make that worse by using the accent for long-form body text.

Fallbacks for browsers without color-mix()

color-mix() is not universal yet, so the theme should keep a basic experience for older browsers.

One pattern is:

:root {
  /* basic fallback */
  --accent-strong: var(--accent);
  --accent-bg-soft: rgba(0, 0, 0, 0.03);
}

@supports (color-mix(in srgb, black, white)) {
  :root {
    --accent-strong: color-mix(in oklch, var(--accent) 85%, black);
    --accent-bg-soft: color-mix(in oklch, var(--accent) 12%, white);
  }
}

In browsers without @supports (color-mix), buttons still use the accent, they just do not get a more intense hover color. Soft backgrounds fall back to a neutral tint instead of an accent-tinted one.

Keeping everything wired to one variable

The main benefit of this approach is that the entire palette stays wired to --ghost-accent-color. When someone changes the accent in Ghost admin, links, buttons, cards, focus states and badges all follow without touching the theme settings.

The trade-off is that you have to be conservative: avoid using the accent for long-form text, keep strong backgrounds limited, and lean on oklch and color-mix() to keep hover and subtle states in a safe range.

Who actually reads my llms.txt?

Richard Lemon — Sat, 17 Oct 2026 10:42:14 +0000

Checking who touches `llms.txt` in practice

/llms.txt and /llms-full.txt have been live on richardlemon.com for a while. The obvious next question: who, if anyone, is actually requesting them?

One way to approach that is to look at the web server logs directly. No dashboards, no vibes. Just the Nginx access log on the droplet.

Where the evidence lives: Nginx access logs

On a typical Nginx setup on a small VPS, access logs will usually live somewhere like:

/var/log/nginx/access.log
/var/log/nginx/access.log.1
/var/log/nginx/access.log.2.gz
...

The exact path depends on the distro and how Nginx was installed, but the pattern is similar: a current access.log plus rotated and sometimes gzipped older logs.

For anything related to llms.txt, the relevant fields are the request path and the user agent. That tells you which client asked for which file, and how it chose to introduce itself.

Filtering for `llms.txt` and `llms-full.txt`

First step is to pull out only the lines that touch those two files. You can do that with a simple grep across your logs. For example, from the directory where your logs live:

cd /var/log/nginx

grep -hE "llms\.txt|llms-full\.txt" access.log* > llms-requests.log

A few details here:

-h hides the filename in the output, which keeps the next steps cleaner.
-E lets you use an extended regular expression so you can match both filenames in one go.
access.log* will hit the current log and any rotated ones that are not gzipped. If you have .gz files, you can run zgrep similarly.

After this you have a smaller file, llms-requests.log, that only contains requests for your LLM-related files.

Grouping by user agent

The next step is to see who those requests belong to. For that you need the user agent field from each log line.

This depends on the Nginx log format, but on a fairly standard combined log format the user agent is the last quoted string in the line. You can extract and group it with awk and sort:

awk -F '"' '{print $6}' llms-requests.log \
  | sort \
  | uniq -c \
  | sort -nr > llms-user-agents.txt

What this does:

-F '"' tells awk to split on double quotes. In a combined log, the user agent ends up as field 6.
sort | uniq -c groups identical user agents and counts them.
The final sort -nr orders them by frequency, highest first.

At this point you have a list of all user agents that have requested llms.txt or llms-full.txt, plus how often they did it.

Bucketing into GPTBot, ClaudeBot, Perplexity, Googlebot, other

Raw user agent strings are messy. If you want something legible, it helps to bucket them into a small set of known crawlers and an “everything else” bucket.

For LLM-related traffic, the usual suspects are:

GPTBot (OpenAI)
ClaudeBot (Anthropic)
PerplexityBot
Googlebot (useful for comparison, even though it is not an LLM crawler in the same sense)
Other (browsers, random scrapers, SEO tools, misconfigured scripts)

You can do a rough classification with another awk pass that looks for substrings in the user agent string and assigns a label.

awk -F '"' '{
  ua = $6
  bucket = "Other"

  if (ua ~ /GPTBot/i) {
    bucket = "GPTBot"
  } else if (ua ~ /ClaudeBot/i) {
    bucket = "ClaudeBot"
  } else if (ua ~ /PerplexityBot/i) {
    bucket = "PerplexityBot"
  } else if (ua ~ /Googlebot/i) {
    bucket = "Googlebot"
  }

  print bucket
}' llms-requests.log \
  | sort \
  | uniq -c \
  | sort -nr

This does a few things:

Looks at each log line, extracts the user agent, and sets a default bucket of Other.
Checks for known bot identifiers with case-insensitive regexes.
Prints the bucket name for each request, then groups and counts.

The result is a small table of how many requests came from each crawler family. You can run the same script periodically to see if the mix changes over time.

What you might expect to see

Given that llms.txt and llms-full.txt have been live for months, it is reasonable to expect at least some of the known LLM crawlers to touch them occasionally if they are crawling the domain at all.

That could look like:

Sporadic hits from GPTBot, ClaudeBot, or PerplexityBot if they respect and look for llms.txt-style files.
Regular background noise from Googlebot and other search crawlers that might fetch anything that looks like a text file.
Manual requests from browsers or command-line tools when humans are testing or debugging.

If the logs show zero requests from a specific crawler family over a long period, that suggests either the crawler is not visiting the domain at all or it does not care about these particular files. If you see requests from a bot with a name that sounds like a major provider, that still needs a bit of skepticism.

Why a request is not the same as being in the training set

It is tempting to look at a log entry from something called GPTBot and immediately conclude that your content is now in some training corpus. That leap is not supported by the data.

The logs only prove one thing: at a certain time, from a certain IP, a client that claimed a particular user agent fetched a particular URL and got some HTTP status code back. Everything beyond that is inference.

Some specific limits:

Identity is self-reported. User agents can be faked. Without reverse DNS and IP range checks, you do not know if a request really came from OpenAI, Anthropic, or anyone else.
Fetching is not storing. A crawler can request llms.txt, read the policy, and then decide not to crawl or not to retain content. The file might be used purely as a routing or filtering hint.
Storing is not training. Even if content is cached, that does not prove it ends up in a training dataset. Providers often separate crawling, indexing, and training pipelines.
Training is not citation. Even if something is in a training set, there is no guarantee it will ever be surfaced as a citation or explicit reference in generated output.

So “I see GPTBot in my logs” is a weaker claim than “GPTBot trained on my content,” and much weaker than “GPTBot will cite my content.” The first is observable. The others are policy and implementation details on the provider side.

What this does and does not say about GEO

There is a lot of talk about geographic opt-out files and LLM-specific robots instructions as a way to control how models use content. Files like llms.txt are one piece of that conversation, but access logs do not tell you much about how GEO policies are actually enforced.

From the logs you can reasonably say:

“This crawler family appears to be aware of llms.txt and fetches it.”
“This crawler seems to visit from these IP ranges and with this frequency.”

From the logs you cannot safely say:

“This provider is fully complying with my GEO or usage instructions.”
“My content is excluded from all future training runs in all regions.”
“If I change llms.txt today, the effect will propagate everywhere by a specific date.”

At best, you can correlate: you publish or change llms.txt, you see a certain bot fetch it, and you assume that whatever policy they have that mentions the file is now in play. The real enforcement logic and the timelines sit behind someone else’s API and release notes.

Why still bother with `llms.txt` and logs

Even with all those caveats, llms.txt and llms-full.txt are still useful knobs to have:

They give you a clear, machine-readable place to state your preferences.
Access logs let you verify at least that some crawlers are paying attention.
When policies or providers change, you have a concrete file to update instead of guessing which meta tags or headers matter this month.

The flip side is that they are not magic. If you care about how your content is used in LLMs, logs are just the first, low-tech feedback loop. They tell you who knocked on the door. They do not tell you what happened to the data after it left your server.

Why I finally deleted NotePlan

Richard Lemon — Thu, 27 Aug 2026 23:42:15 +0000

The feature list looked perfect. The app did not.

On paper, NotePlan inside Setapp can look like a great home for tasks. Daily notes. Calendar integration. Linked references. A whole personal system in one place.

In practice, it never stuck for me. I would install it, poke around, half-commit to moving things in, then slide back to Todoist and other tools.

The problem was not the feature list. It was the feeling of using it.

NotePlan vs Todoist: the difference you actually feel

Todoist has one trick that keeps pulling me back: natural language input that feels like talking to the app instead of configuring it.

Typing something like:

Call Sam tomorrow at 3pm #work p1

and watching it turn into a properly dated, tagged, prioritised task is hard to beat. The interface mostly gets out of the way. You think about the task, not the tool.

NotePlan, by comparison, always felt like work before the work. The interface is visually dense: panes, calendars, notes, metadata. The power sits in front of you instead of behind you. Every time I opened it, I had a small moment of friction: where does this thing go and what is this screen trying to show me?

That friction is subtle. It is not a crash, a bug, or a missing feature. It is a half-second of hesitation every time you capture or review. Multiply that by a few dozen interactions a day and you end up with a tool that looks great in theory and quietly loses in practice.

Visual friction is adoption friction

Visual friction is what happens when the interface makes your brain do admin before it can do the actual task.

With NotePlan, the combination of calendar, notes, and tasks in one view sounds efficient, but it also asks for constant micro-decisions:

Is this a note, a task, or an event?
Should it live in a daily note or a project note?
Am I looking at the right pane for the thing I care about?

Todoist, in contrast, is visually boring in a good way. It is a list with some filters. The natural language input means the main interaction is: type what you mean, hit enter, move on. The visual layer confirms what you did instead of asking more questions.

That difference is one reason a “richer” app like NotePlan can lose to a “simpler” one like Todoist. The richer app has more states to understand. The simpler one lets you stay slightly under-loaded mentally, which is exactly where you want to be when you are trying to actually do things.

The moment I finally deleted NotePlan

There was no dramatic break-up. I was using Todoist every day, and NotePlan had become an ambitious side system that never quite got fully adopted.

At some point you have to admit that if you keep re-opening the same app every few months and it never sticks, the problem is not that you have not found the right configuration. The problem is that the tool does not match how your brain wants to see work.

So I removed NotePlan from the rotation and stopped pretending it was “almost” my all-in-one solution. The result was not a loss of features. It was a gain in clarity.

The 4-app stack that replaced the all-in-one dream

Instead of forcing everything into one environment, I ended up with a small stack where each app has exactly one job. That constraint turned out to be more useful than any integrated feature set.

The current daily drivers look like this:

1. Todoist: tasks only

Todoist is where every actionable item lives. If it has a verb and a clear “done,” it goes here. Nothing else.

No notes, no long-form thinking, no project briefs. Just tasks, with natural language input doing most of the heavy lifting. This keeps the interface clean and the mental model simple: open Todoist when you want to decide what to do next or capture something you must not forget.

2. Calendar: time, not tasks

The calendar is for events and time blocks. That is it.

Meetings, training sessions, and any block of time that is actually reserved goes here. Tasks do not live on the calendar by default. If something from Todoist needs protected time, I block it in the calendar, but the task itself still belongs to Todoist.

This separation avoids the usual mess where tasks and events fight for the same space and you cannot tell what is optional and what is fixed.

3. Notes app: thinking, not tracking

A notes app handles all the text that does not have a clear “do this” attached.

Project outlines, ideas, meeting notes, and reference material live here. Tasks that emerge from notes get promoted into Todoist, but the note itself stays as context, not as a to-do list.

The key is resisting the temptation to turn the notes app into another task manager. That is how you end up with ghost tasks scattered through documents that never get reviewed.

4. Whiteboard or sketch tool: structure, not storage

For planning and untangling bigger pieces of work, a whiteboard or sketch tool fills the gap between messy thinking and structured tasks.

This is where you map flows, group ideas, and see relationships. Once the structure makes sense, the actual actions go into Todoist. The board is allowed to stay messy. It is not a database.

Why “one job each” beats “one app for everything”

Feature lists push you toward consolidation. If an app can technically do tasks, notes, calendar, and planning, it feels rational to put everything there. In reality, this often creates a second problem: you now have to remember how you decided to use that flexibility.

Giving each tool exactly one job does a few useful things:

You always know where something belongs.
You reduce context switching inside each app, because you are not jumping between modes.
You are free to swap out one tool without rethinking your entire system.

NotePlan tried to be the place for everything. The 4-app stack is a set of single-purpose rooms. That small architectural change removed a lot of silent friction.

Visual appeal and intuition beat feature checklists

None of this shows up in a comparison table. Natural language input vs markdown syntax. Calendar integration vs external calendar. Daily notes vs separate notes app. On a spreadsheet, NotePlan can look like the smarter choice.

The problem is that you do not live in a spreadsheet. You live in the interface.

If an app feels visually heavy, if it asks micro-questions before it lets you act, if you keep bouncing off it even though you like the idea of it, that is data. Ignoring that and chasing features is how you end up maintaining a system instead of doing the work the system was supposed to support.

Deleting NotePlan was basically admitting that intuition and visual comfort matter more than theoretical power. Once the tool stopped fighting my habits, everything else got simpler.

Gamifying Cardiac Rehab with Habitica

Richard Lemon — Thu, 27 Aug 2026 23:41:55 +0000

Why I turned recovery into a game

Cardiac rehab is a long, repetitive grind. The problem is that it feels like a grind. The exercises matter, the sleep and nutrition matter, but the feedback loop is slow and fuzzy.

Habitica gives me an immediate feedback loop. I turn recovery into an RPG: quests, parties, XP, streaks. The medical side still lives with doctors and devices. The day-to-day compliance lives in a game.

The Habitica party: making recovery a team sport

Habitica is built around parties: small groups of players who share quests and damage. A screenshot of my party setup would show a few key things:

Everyone has their own class, gear, and cosmetics, so it looks like a proper RPG group.
We share quests that trigger when people complete specific tasks.
Missed Dailies deal damage to the whole party, not just you.

That last part is the hook. If I skip a rehab task, it is not just my avatar taking a hit. The whole party pays for it. That bit of social pressure does more than any abstract “you should really exercise” notification.

Dailies vs Habits: wiring rehab into the game

Habitica has two core building blocks for behavior:

Dailies are recurring tasks that are either done or not done on a given day.
Habits are behaviors you can do multiple times, or avoid, and they can give positive or negative rewards.

For recovery, I use Dailies for the non-negotiables. If a cardiologist would frown when you skip it, it is probably a Daily. Things like specific rehab sessions, medications, and sleep windows fit here. They show up every day (or on selected days), and if I do not check them off, my character and my party take damage at midnight.

Habits are better for sliders than switches. They track intensity, quality, and “more vs less” decisions. A Habit might reward extra walking, stretching after sitting too long, or choosing a sensible meal. Negative Habits can punish the things I am trying to avoid.

The distinction matters because it changes how the task feels. A missed Daily is a clean failure. A missed Habit is just a missed opportunity. Rehab needs both: hard commitments and soft nudges.

The 6:40 circuit checklist as a Daily

The backbone of my setup is a specific rehab block: a 6:40 circuit. Habitica turns it into a simple Daily with a checklist. The Daily itself is “Complete 6:40 circuit” and inside it lives the step-by-step sequence.

The checklist looks like:

0:40 warmup
1:00 cardio block
1:00 strength block
1:00 cardio block
1:00 strength block
1:00 cooldown / breathing
0:20 notes / log

The Daily makes sure the circuit happens. The checklist turns one vague “do rehab” task into a series of small wins. Every tick gives a little hit of progress before the final completion reward.

Using WHOOP recovery as a daily XP multiplier

WHOOP gives a daily recovery score. It is a compact summary of how ready your body supposedly is for strain: sleep, HRV, resting heart rate, and so on rolled into one number.

In my setup, that recovery score becomes an XP multiplier for the day. The logic is simple:

High WHOOP recovery = high multiplier. Rehab work that day should be a little heavier and more rewarding in-game.
Low WHOOP recovery = low multiplier. Focus on the minimum viable Dailies and do not chase streaks with hero workouts.

Practically, I look at the WHOOP score in the morning and mentally tag the day as “green,” “yellow,” or “red.” Then I adjust how aggressively I chase Habitica rewards.

On a green day, I try to clear all the Dailies, complete the full 6:40 circuit, and hit a few bonus Habits. It feels like a double-XP weekend: the game and the body are aligned.

On a red day, the win condition is narrower. The goal is to protect streaks on the core Dailies, keep the party from taking damage, and then stop. The game does not get to overrule the recovery score.

The Todoist shutdown ritual as a quest

Recovery is not just workouts and heart rate graphs. A big part of it is not carrying work stress into the evening. For that, I use a shutdown ritual in Todoist and mirror it in Habitica as a quest.

The Todoist side holds the actual work tasks: review the inbox, clear or reschedule remaining tasks, capture loose ideas, and pick the top priorities for tomorrow. It is a straightforward checklist that closes the workday.

In Habitica, this becomes a quest-like Daily. The checklist looks like:

Review today’s completed tasks in Todoist
Reschedule or drop any remaining tasks
Write down tomorrow’s 1–3 priorities
Close work apps and mute notifications

Completing it earns XP and gold, like a battle. Skipping it means walking into the evening with open loops, which is exactly what I do not want when recovery is the priority.

A CSS Hover-Reveal Pattern for Technical Specs

Richard Lemon — Fri, 21 Aug 2026 06:46:13 +0000

The problem on the Gate Seal page

The Gate Seal product page for a maritime client needed to present detailed specifications without turning the layout into a wall of text or a table that looked like an export from Excel. The technical detail buyers cared about was present, but visually buried.

The requirement was to surface those details in a compact way, keep the implementation CSS-only, and make sure it still worked with keyboard navigation.

The hover-reveal pattern

The pattern below uses a hover-reveal on key specification rows. On desktop, moving the cursor over a spec row reveals additional context. With a keyboard, focusing the same row does the same thing. No JavaScript is required for the basic interaction.

Structurally, each spec item is a container with two layers of content:

Always-visible summary (label and primary value)
Hidden detail that appears on hover or focus

Here is a simplified version of the markup:

<div class="spec-list">
  <button class="spec-item">
    <div class="spec-main">
      <span class="spec-label">Gate size</span>
      <span class="spec-value">Up to 6 m</span>
    </div>
    <div class="spec-detail">
      Custom diameters available for retrofit situations.
    </div>
  </button>

  <button class="spec-item">
    <div class="spec-main">
      <span class="spec-label">Seal material</span>
      <span class="spec-value">EPDM / NBR</span>
    </div>
    <div class="spec-detail">
      Oil-resistant compounds for lock gates in heavy traffic.</div>
  </button>
</div>

The choice of <button> here is deliberate: it is naturally focusable, works with keyboard navigation, and is announced as an interactive element by assistive technology. In a production implementation, the button semantics can be adapted depending on whether you need a true button or a different element with role="button".

The CSS-only interaction

The interaction is controlled through :hover and :focus-visible, with a basic transition for a smoother reveal.

.spec-list {
  display: grid;
  gap: 0.75rem;
}

.spec-item {
  width: 100%;
  text-align: left;
  border: 1px solid #d0d5dd;
  border-radius: 4px;
  padding: 0.75rem 1rem;
  background: #ffffff;
  cursor: pointer;
  position: relative;
}

.spec-item:focus-visible {
  outline: 2px solid #004b8d;
  outline-offset: 2px;
}

.spec-main {
  display: flex;
  justify-content: space-between;
  align-items: baseline;
  gap: 1rem;
}

.spec-label {
  font-weight: 500;
}

.spec-value {
  color: #344054;
}

.spec-detail {
  margin-top: 0.4rem;
  font-size: 0.875rem;
  color: #475467;

  max-height: 0;
  opacity: 0;
  overflow: hidden;
  transition: max-height 0.18s ease-out, opacity 0.18s ease-out;
}

.spec-item:hover .spec-detail,
.spec-item:focus-visible .spec-detail {
  max-height: 6rem; /* large enough for typical copy */
  opacity: 1;
}

The detail block is always in the DOM and available to assistive technology, but visually collapsed until the user shows intent to inspect that spec with the mouse or the keyboard.

Keyboard and accessibility fallback

A pure hover interaction would be a problem for keyboard users and some assistive technologies. Mirroring the behavior on :focus-visible avoids that.

With the structure above:

Each .spec-item is focusable and reachable via Tab.
The same detail that appears on hover also appears on focus-visible.
The content is not injected; it is in the DOM and readable by screen readers regardless of the visual state.

If stricter control of what screen readers announce is required, aria-expanded attributes can be added and toggled with a small amount of JavaScript, but the base pattern does not depend on that. The important part is that there is no information that is only available on hover.

On touch devices, there is no hover, so the interaction degrades to a tap-to-focus behavior. The spec item receives focus when tapped, the detail appears, and tapping elsewhere moves focus away again. If that feels too subtle on mobile, details can be kept always visible below a certain breakpoint:

@media (max-width: 768px) {
  .spec-detail {
    max-height: none;
    opacity: 1;
  }
}

This keeps specs compact and interactive on larger screens where hover exists, and straightforward on phones.

Using this pattern on the Gate Seal page

On the Gate Seal page, this pattern can be applied to key specifications such as material options, mounting configurations, and maintenance notes. Core numbers stay visible, and the hover-reveal carries clarifications and edge-case notes.

The Gate Seal product page exists to support real purchasing decisions, so the interaction should be reserved for supplementary context rather than critical safety, pricing, or legal information. Those details should remain visible by default.

The Schema.org Markup Every Client Site Should Ship With

Richard Lemon — Sun, 16 Aug 2026 12:13:46 +0000

My default structured data bundle

I got tired of treating Schema.org like a research project.

You know the drill. New client. New niche. Too many schema types. Then you add nothing because it feels endless.

So I stopped doing that. I built a small default bundle instead. A set of JSON-LD blocks I ship on almost every marketing or SaaS site, plus a couple of variants for blogs and local businesses.

This is the technical walkthrough of that bundle. No theory. Just the markup I actually use, and where it lives.

Core rules I follow

Before the snippets, a few constraints I stick to.

JSON-LD only. No microdata, no RDFa. It lives in <script type="application/ld+json"> blocks.
One primary entity per page. Google can handle more, but I keep it simple unless I really need composites.
Generated, not hand-written. I wire this into the build step or CMS fields. No manual copy paste for every page.
Data must exist visually. If the user cannot see it, I do not put it in schema. That keeps me out of spam territory.

Where I inject JSON-LD

I put JSON-LD in the HTML head wherever possible.

React / Next.js: I attach it to a <Head> component. Astro / Svelte / plain HTML: I write it straight into <head>.

If I need dynamic data, I render the JSON on the server, then drop it in as stringified content.

<script type="application/ld+json">
{ ...jsonHere }
</script>

No CDNs. No external scripts. Search engines want the JSON inline.

1. Site-wide: WebSite + SearchAction

Every multi-page site I ship gets a base WebSite schema on the homepage. It is tiny, and Google uses it for sitelinks search boxes.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Acme Analytics",
  "url": "https://acmeanalytics.com/",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://acmeanalytics.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}

A few rules I stick to:

Only on the root URL. I keep this script on /, not on every page.
Search endpoint must exist. If there is no search, I drop potentialAction. No fake endpoints.
Exact canonical URL. I match the url value to the canonical link tag, every time.

Implementation detail. I have a small buildWebsiteSchema(config) helper where I feed siteName, url, and optional searchUrl. The page component just calls it and stringifies the JSON.

2. The main entity: Organization or LocalBusiness

Almost every client site represents a company of some sort. I start with a generic Organization. For brick-and-mortar clients I switch to a more specific LocalBusiness subtype.

Global company: Organization schema

This is my baseline for SaaS, agencies without public shops, and any online-only service.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Analytics",
  "url": "https://acmeanalytics.com/",
  "logo": "https://acmeanalytics.com/assets/logo.svg",
  "sameAs": [
    "https://twitter.com/acmeanalytics",
    "https://www.linkedin.com/company/acme-analytics/"
  ],
  "contactPoint": [
    {
      "@type": "ContactPoint",
      "telephone": "+31-20-123-4567",
      "contactType": "sales",
      "areaServed": "NL",
      "availableLanguage": ["en", "nl"]
    }
  ]
}

Some details I do not skip:

Logo URL. I use the same logo as in the header, absolute URL, and make sure it is crawlable.
sameAs. Only real social profiles, nothing else. I do not put random directories in there.
contactPoint. If we show a phone number on the site, I reflect it here. Otherwise I remove the block.

This usually lives on the homepage next to the WebSite schema. Two separate scripts.

Local business: LocalBusiness schema

For gyms, clinics, restaurants, barber shops, I use the matching LocalBusiness subtype instead: Restaurant, Physiotherapy, HealthClub, and so on.

Example for a gym:

{
  "@context": "https://schema.org",
  "@type": "HealthClub",
  "name": "Lemon Performance Lab",
  "image": "https://lemonperformance.nl/og-image.jpg",
  "@id": "https://lemonperformance.nl/#business",
  "url": "https://lemonperformance.nl/",
  "telephone": "+31-6-1234-5678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Brouwersgracht 100",
    "addressLocality": "Amsterdam",
    "postalCode": "1013 GP",
    "addressCountry": "NL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 52.381,
    "longitude": 4.887
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Wednesday", "Friday"],
      "opens": "07:00",
      "closes": "18:00"
    }
  ],
  "sameAs": [
    "https://www.instagram.com/lemonperformance/"
  ]
}

Things that matter here:

I add an @id with a hash fragment. It gives the entity a stable identifier I can reference later if needed.
I do not invent coordinates. I pull them from Google Maps or the client.
openingHoursSpecification must match the actual hours displayed on the page.

On local sites this block is non-negotiable. Rankings and knowledge panel consistency improve a lot once it is in place.

3. Every page: WebPage schema

Most devs skip WebPage. I like it because it gives me a predictable way to describe the actual page entity, tie it to the main organization, and reuse metadata I already have.

I generate this on every indexable page with a simple helper.

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Customer data without the headaches",
  "url": "https://acmeanalytics.com/customer-data-platform",
  "description": "Acme Analytics gives you a privacy-first CDP your team can actually maintain.",
  "inLanguage": "en",
  "isPartOf": {
    "@type": "WebSite",
    "url": "https://acmeanalytics.com/"
  },
  "about": {
    "@id": "https://acmeanalytics.com/#organization"
  }
}

A couple of notes:

name is almost always the page title.
description mirrors the meta description or a trimmed hero copy.
about points to the @id of the organization on the homepage.

On static site generators this fits nicely into a layout template. I already have title, description, url variables, so I just feed them into buildWebPageSchema().

4. Blog posts: Article schema

Any site that has a blog or resources section gets Article markup on each post. I do not go crazy with subtypes unless I have a good reason. BlogPosting is enough.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How I shipped our analytics migration in 3 weeks",
  "description": "The exact process I used to move 12 properties from UA to GA4 without losing our minds.",
  "image": [
    "https://acmeanalytics.com/blog/ga4-migration/cover.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "Richard Lemon",
    "url": "https://richardlemon.com/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Acme Analytics",
    "logo": {
      "@type": "ImageObject",
      "url": "https://acmeanalytics.com/assets/logo-512.png"
    }
  },
  "datePublished": "2024-03-18T09:00:00+01:00",
  "dateModified": "2024-03-20T10:30:00+01:00",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://acmeanalytics.com/blog/ga4-migration"
  }
}

This is where text data from the CMS pays off. I map fields directly:

Title field to headline.
Excerpt field to description.
Featured image to image.
Author model to author object.
Published / updated timestamps to datePublished and dateModified.

If the blog supports multiple authors, I let author be an array. Same structure, just wrapped.

5. Product or pricing pages: Product + Offer

I am careful with Product schema. I only use it if there is an actual product with pricing and a way to buy. That could be an ecommerce product, a SaaS plan, or a course.

Here is a simple SaaS plan example on a pricing page.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Analytics Pro",
  "description": "Event-based analytics for product teams that need real-time dashboards.",
  "image": "https://acmeanalytics.com/assets/pro-plan.png",
  "brand": {
    "@type": "Organization",
    "name": "Acme Analytics"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://acmeanalytics.com/pricing",
    "priceCurrency": "EUR",
    "price": "79",
    "priceValidUntil": "2025-12-31",
    "availability": "https://schema.org/InStock"
  }
}

Key constraints I follow:

Exact price. It has to match the visible price on the page. If we show “starting at 79”, I use that number.
No fake discounts. If the site does not show a discount, I do not use priceSpecification with price vs priceBeforeDiscount.
Limit the scope. I only put this schema on the pricing page or the dedicated product detail page, not globally.

For shops with reviews, I also wire in aggregateRating and review only when the rating count and values are rendered in the UI.

6. BreadcrumbList for content depth

If the site has a clear content hierarchy, I add BreadcrumbList. This can produce breadcrumb rich results, but I mostly like it because it encodes structure explicitly.

Example for a blog post nested one level deep.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Blog",
      "item": "https://acmeanalytics.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "GA4 Migration",
      "item": "https://acmeanalytics.com/blog/ga4-migration"
    }
  ]
}

I let the router or CMS build this automatically from the URL structure. If there is no real breadcrumb UI, I skip this. I like my structured data to mirror the layout.

7. How I actually wire this up

All of this is useless if it lives in a Notion doc. The power comes from making it boring, repeatable, and hard to break.

This is roughly how I integrate it on client projects.

Step 1: Central schema helpers

I keep a schema/ or seo/ folder with tiny pure functions that return POJOs for each type.

// schema/website.ts
export function buildWebsiteSchema({ name, url, searchUrl }) {
  const base: any = {
    "@context": "https://schema.org",
    "@type": "WebSite",
    name,
    url
  };

  if (searchUrl) {
    base.potentialAction = {
      "@type": "SearchAction",
      target: `${searchUrl}?q={search_term_string}`,
      "query-input": "required name=search_term_string"
    };
  }

  return base;
}

Each helper hides the annoying details. Pages just pass real data.

Step 2: Shared head component

I do not scatter <script> tags everywhere. Instead I use a shared SEO or head component that accepts structured data as an array.

function JsonLd({ data }) {
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(data) }}
    />
  );
}

function SeoHead({ title, description, schemas = [] }) {
  return (
    <Head>
      <title>{title}</title>
      <meta name="description" content={description} />
      {schemas.map((schema, i) => (
        <JsonLd key={i} data={schema} />
      ))}
    </Head>
  );
}

Now any page can plug in the relevant schema variants without repeating the script wrapper logic.

Step 3: Validate in CI at least once

I do two passes.

During development I use the Schema.org or Google Rich Results test against my local or a staging URL.
Before launch I run a quick automated check that hits a couple of canonical pages and asserts the <script type="application/ld+json"> blocks exist.

I am not chasing zero warnings. I mostly want to avoid accidentally shipping broken JSON or wildly inconsistent data.

The minimal bundle I recommend

If you build sites for clients and want a minimum structured data set that covers most use cases, I would ship this on every project:

Homepage: WebSite + Organization or LocalBusiness + WebPage.
Standard pages: WebPage.
Blog index: WebPage (optionally CollectionPage if you want, but I do not bother).
Blog posts: WebPage + BlogPosting + BreadcrumbList.
Pricing / product pages: WebPage + Product (with Offer) when there is a real product.

This keeps the implementation small enough that you can wire it up properly, automate it, and forget about it. Which is the point. Structured data should be boring infra, not a one-off SEO stunt.

Ship it once, wire it into your layouts, and your future client projects get it for free.

CSS Container Queries In Production: Where They Shine And Where Media Queries Still Win

Richard Lemon — Sun, 16 Aug 2026 12:12:27 +0000

Refactoring a real project to container queries

I stopped reading hot takes about container queries and actually refactored a real client project. A mid-sized marketing site with a component library, a CMS, and the usual pile of legacy CSS.

The goal was simple. Use container queries wherever component-level decisions made more sense than viewport-level ones. Keep media queries where they still pull their weight. No heroic rewrites. No greenfield fantasies.

This is not a spec tour. This is what I actually changed, what hurt, what felt great, and why I did not burn my media queries to the ground.

The old setup: media-query soup

The project started life the way a lot of responsive sites did. Global breakpoints like this:

:root {
  --bp-xs: 480px;
  --bp-sm: 640px;
  --bp-md: 768px;
  --bp-lg: 1024px;
  --bp-xl: 1280px;
}

@media (min-width: 768px) { /* ... */ }
@media (min-width: 1024px) { /* ... */ }

Most components were basically: "If viewport is at least md, do layout X, otherwise stack Y". Classic.

The problem showed up when the same component lived in completely different layouts. Hero section inside a full-width page. Same hero in a sidebar-heavy layout. Same hero inside a CMS block inside a card.

Viewport-based breakpoints started to feel wrong. The component did not care about the viewport. It cared about its box.

Before touching CSS: I had to fix the HTML

Container queries need containers. Obvious, but it changes how you structure your HTML.

I did a quick audit. The rule I used was:

If a component needs to respond to its own width, it gets a container.
If a part inside a component needs to respond to the component, the parent becomes the container.

That turned into a few standard patterns.

Pattern 1: Layout shells as containers

Grid sections, sidebars, cards. Anything that wrapped other components and controlled width. Those became container roots.

<section class="page-section" data-layout="two-column">
  <div class="page-section__content">
    <article class="feature-card">...</article>
    <article class="feature-card">...</article>
  </div>
</section>

And the CSS:

.page-section__content {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1.5rem;
  container-type: inline-size;
  container-name: page-section;
}

Now the children could ask: "How wide is my section wrapper?" instead of "How wide is the viewport?".

Pattern 2: Cards and blocks as containers

Any reusable block in the design system got its own container. Things like .feature-card, .stat-block, .media-object.

.feature-card {
  container-type: inline-size;
  container-name: feature-card;
}

I did not add containers everywhere. Only where I had previously written a media query for "small card layout" vs "large card layout".

The first win: components stopped arguing with the viewport

The hero card was the first thing I switched. Previously it looked like this:

.hero-card {
  display: grid;
  gap: 1.5rem;
}

@media (min-width: 768px) {
  .hero-card {
    grid-template-columns: 3fr 2fr;
  }
}

The problem. When the hero card lived in a skinny sidebar at 1440px viewport width, it still tried to go two-column. It just looked broken.

With container queries, the hero only cares about its own box.

.hero-card {
  display: grid;
  gap: 1.5rem;
  container-type: inline-size;
  container-name: hero-card;
}

@container hero-card (min-width: 560px) {
  .hero-card {
    grid-template-columns: 3fr 2fr;
  }
}

Now the hero goes two-column only if the card itself is at least 560px wide. Not if the viewport happens to be big. That felt like how it should always have worked.

Where container queries really shine

After a week of refactoring, a few patterns stood out as massive improvements.

1. Components reused in unpredictable layouts

The design system had "content blocks" that editors could drop anywhere in the CMS. You can imagine the chaos.

Inside full-width sections
Inside narrow sidebars
Inside cards that lived in carousels

In the old version I cheated. I limited where editors could place certain components. I basically told the CMS what the layout was allowed to be, just to protect my media queries.

With container queries that restriction went away. Each block simply responded to the space it actually received.

.content-block {
  container-type: inline-size;
  container-name: content-block;
}

@container content-block (min-width: 700px) {
  .content-block--image-right {
    display: grid;
    grid-template-columns: 1fr 1fr;
    gap: 2rem;
  }
}

The same content block behaved nicely in a 900px region and inside a 420px sidebar. No new breakpoint. No layout-specific modifier. Just local logic.

2. Nested complexity without breakpoint explosions

One section had a nasty nesting problem. Three cards across on desktop. Cards had stats, icons, buttons, and sometimes a badge. Each card also changed layout internally at md.

With media queries I had two sets of breakpoints. One set for the section grid. One set for the cards. They needed to stay in sync. You know how this ends.

Container queries let the section and cards negotiate separately.

.stats-section {
  display: grid;
  gap: 1.5rem;
  container-type: inline-size;
  container-name: stats-section;
}

@container stats-section (min-width: 900px) {
  .stats-section {
    grid-template-columns: repeat(3, minmax(0, 1fr));
  }
}

.stat-card {
  container-type: inline-size;
  container-name: stat-card;
}

@container stat-card (min-width: 340px) {
  .stat-card__body {
    display: grid;
    grid-template-columns: auto 1fr;
    gap: 1rem;
  }
}

The section manages its columns. The card manages its internal layout. No cross-dependency. No mental math about "what does 340px inside a 900px grid mean at 1024px viewport".

3. Dark corners of the design system became predictable

Every design system has a few awkward components. For me it was a "media object" pattern that designers used everywhere. Image + content + actions. Sometimes horizontal, sometimes vertical, sometimes tiny.

Previously I had a mess of modifiers: .media--compact, .media--horizontal-lg-only, all wired to global breakpoints. Maintaining them sucked.

Switching to container queries let me cut that down to "respond when too small or big".

.media-object {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
  container-type: inline-size;
  container-name: media-object;
}

@container media-object (min-width: 520px) {
  .media-object {
    flex-direction: row;
    align-items: flex-start;
  }
}

Editors could now throw this pattern wherever they wanted. I did not need to ship ten variants. That felt like an actual productivity gain, not a theoretical nice-to-have.

Where I intentionally kept media queries

I am not treating container queries like a new religion. Viewport media queries still win in a few places and I kept them.

1. Global layout shifts

Some layout changes are tied to the viewport, not a container. Header navigation is a good example.

The site went from mobile nav to horizontal nav at around 900px viewport width. This is not a per-component decision. This is a global "how do we use the top 80px of the screen" decision.

@media (min-width: 900px) {
  .site-header {
    grid-template-columns: auto 1fr auto;
  }

  .nav-toggle {
    display: none;
  }

  .primary-nav {
    display: flex;
  }
}

I could have wrapped the whole page in a container and used container queries there. I did not bother. Viewport width is the right source of truth for this.

2. Typography scale and rhythm

Global type scale based on viewport still makes sense to me. Things like base font size, vertical rhythm, and heading scales.

Container queries inside components are great for "if my card is cramped, reduce the heading size a bit". But the general "phone vs desktop reading experience" feels like a viewport choice.

html {
  font-size: 15px;
}

@media (min-width: 768px) {
  html {
    font-size: 16px;
  }
}

@media (min-width: 1200px) {
  html {
    font-size: 17px;
  }
}

I experimented with wrapping the main content area in a container and tying typography to that. It felt fussy and added complexity without real benefit. Viewport queries stayed.

3. "Hard" layout breakpoints in marketing pages

There were a few full-bleed marketing sections that changed layout aggressively. Big storytelling panels.

Those were designed around fixed viewport breakpoints in Figma. Trying to force them into container logic gave me weird edge cases. Things broke in exactly the places the designer cared about.

So I did not fight it. I kept simple viewport media queries:

@media (min-width: 1024px) {
  .story-section {
    grid-template-columns: minmax(0, 1.2fr) minmax(0, 1fr);
  }
}

Sometimes the boring answer is the right one.

What actually changed in my workflow

Once the refactor settled, a few habits changed for good.

1. I think in "component width" instead of "screen size"

My first question used to be: "What happens at 768px and 1024px?". Now it is: "At what width does this component start to look stupid?".

That leads to smaller, more honest breakpoints.

@container card (min-width: 420px) { ... }
@container card (min-width: 640px) { ... }

I stopped pretending all components share the same breakpoints. They do not. And that is fine.

2. My CSS files are more local and less global

The old codebase had big global breakpoint sections. All components shared them. That sounds organized. In practice it meant every change risked side effects.

With container queries, most responsive logic lives next to the component styles.

.feature-card { ... }

@container feature-card (min-width: 480px) { ... }
@container feature-card (min-width: 720px) { ... }

I like this a lot better. When I open a component file I see all of its behaviour, including responsiveness, in one place.

3. Fewer "support grid X only" rules in the CMS

The CMS previously had hidden layout rules. We told editors: "You cannot put block Y inside layout X because it breaks at tablet."

That sort of rule is a smell. It tells you the CSS is too coupled to a specific layout. Container queries finally gave me a way to fix that instead of just documenting around it.

After the refactor, we removed several "you may not combine these" notes. Editors have more freedom. I get fewer layout bug tickets. That is an easy win.

Gotchas that actually hurt

It was not all magic. A few things were annoying enough that I would warn future-me before doing this again.

1. You must be deliberate about container boundaries

Early on I just sprinkled container-type: inline-size; everywhere. That was a mistake.

Too many nested containers make it hard to reason about which container is actually being queried.

.card {
  container-type: inline-size;
  container-name: card;
}

.card__content {
  container-type: inline-size;
  container-name: card-content;
}

Then inside CSS I wrote @container (min-width: 500px) without a name. Suddenly some rules were responding to card, others to card__content.

I fixed it by:

Using named containers for anything complex.
Limiting containers to a few well-known layers: page, section, component.

2. DevTools muscle memory is wrong

Checking responsive behaviour with container queries feels different. You no longer just drag the viewport. You need to also think about how the container width changes when the layout changes.

Modern DevTools help, but they are not perfect yet. Chrome and Firefox both have container query overlays, which helps a lot. But I still occasionally misdiagnose a bug as "container query not firing" when it is actually "different container is active".

3. Performance paranoia

Specs and browser teams have done a good job making container queries efficient. But old instincts kick in when you sprinkle dozens of them into a complex page.

I stress tested a few templates. So far, normal marketing-site scale has been fine. But I would not blindly apply container queries to every tiny utility component in a mega-dashboard without measuring.

How I would approach the next project

If I started a fresh project tomorrow, I would not go "container queries only". I would set some rules upfront.

Use viewport media queries for global layout, navigation, and base typography.
Use container queries for reusable components and CMS blocks that live in variable layouts.
Define a small set of standard container layers: page-shell, section, component.
Keep container names explicit in CSS, avoid unnamed queries except for trivial cases.

The main mental shift is this.

Media queries answer: "What does the world look like?". Container queries answer: "What does my box look like?".

You need both. Trying to force everything into one or the other is dogma, not engineering.

So, was the refactor worth it?

For this project, yes. Strong yes.

The biggest win was not fewer lines of CSS. It was fewer layout-specific hacks in the CMS and fewer weird "component behaves badly in this one layout" bugs.

Container queries made the system more honest. Components now respond to the thing they actually depend on: their own size. Media queries still run the global show.

If you have a design system that shows up in many layouts, or a CMS where editors can shuffle blocks freely, then I think you are leaving real value on the table by not using container queries.

If your app is mostly a couple of fixed layouts with hand-tuned breakpoints, then viewport media queries are still perfectly fine. I would not refactor just for the buzzword.

Use container queries where the component cares about its own box. Use media queries where the design cares about the screen. Once you draw that line, the rest becomes straightforward.

Why Littlebird Sits At The Center Of My AI Stack

Richard Lemon — Sun, 16 Aug 2026 11:53:10 +0000

The AI subscriptions I cancelled

I used to pay for several AI tools every month. Over time that turned into more overlap than value, so I shut most of them down and kept one thing at the center of the stack: Littlebird.

Here is what I cancelled:

ChatGPT Pro
Claude Pro
Perplexity Pro

That is three separate subscriptions gone. The monthly savings are the combined cost of those plans that I am no longer paying. Instead of spreading budget across multiple assistants, I pay for Littlebird and use it to orchestrate the rest of the stack.

Why Littlebird is the one I still pay for

Littlebird is not just another AI assistant alongside the usual suspects. It is the layer that sits in front of them and coordinates how they are used.

Instead of logging into different sites, copying prompts around, and trying to remember where a specific conversation lives, Littlebird becomes the front door. I talk to it, and it decides which underlying model or tool to call, with what context, and how to feed the results back into my ongoing work.

The result is that I do not need separate paid accounts for every model to feel like I have a strong stack. I need one orchestrator that can talk to them intelligently.

The Mac Studio as a sovereign AI hub

All of this is organized around a Mac Studio that acts as a kind of sovereign AI hub. Instead of treating AI as a collection of cloud websites I visit, I treat the Mac Studio as the place where my data, agents, and workflows live.

That hub does a few important things:

Central storage: files, notes, code, and local tools live on a machine I control.
Local context: when an AI tool needs context, it is pulled from the hub, not from random uploads scattered across different services.
Single integration point: automations, scripts, and agents plug into the Mac Studio instead of every service trying to talk to every other service.

Littlebird sits on top of that. It treats the hub as the source of truth, and it treats external models as stateless workers that come and go. The stability lives on the Mac Studio; the interchangeable part is which model is used for a specific task.

How the context loop actually works

The useful part is the loop between Littlebird, the Mac Studio hub, and the external AI tools.

At a high level, the loop looks like this:

Start in Littlebird: I give Littlebird a task in natural language: a coding question, a research prompt, or something related to a project on the Mac Studio.
Attach context from the hub: Littlebird can pull in relevant context from the Mac Studio: local files, previous notes, project structure, or past conversations.
Route to the right model: Based on the task, Littlebird calls out to one of the external AI tools or models. The external tool does not see everything; it just gets the slice of context Littlebird decides to share.
Pull results back into the hub: When the external model returns an answer, Littlebird writes the useful parts back into the Mac Studio environment: updated files, new notes, or structured data.
Keep the conversation going: The next time I ask a related question, Littlebird can see the updated state on the hub and continue from there without me manually pasting anything.

The key is that the context is not owned by any single vendor. It lives on the Mac Studio. Littlebird is the thing that keeps that context in sync with whatever external model it is using at the moment.

From many tabs to one orchestrated stack

Using multiple AI tools usually means multiple browser tabs and separate histories. A coding thread might live in one place, a research thread in another, and none of them know about the files on my machine unless I upload them manually each time.

With Littlebird in front and the Mac Studio underneath, the stack becomes one surface instead of three or four:

I talk to Littlebird, not to individual vendors.
The Mac Studio holds the long-term memory.
External AI tools are workers that come and go.

This is why paying for Littlebird makes more sense than keeping separate subscriptions alive. The value is in the coordination and the context loop, not in having another slightly different chat UI.

Why the premium plan matters

Littlebird has an upcoming premium plan. That matters less as yet another subscription and more as a way to keep the orchestrator sharp while the underlying models keep changing.

The external tools will continue to compete on speed, quality, and features. Some will be better for code, some for research, some for structured data. I expect that mix to keep shifting. The premium plan is a way for Littlebird to keep adding better routing, deeper integrations with the Mac Studio hub, and smarter context handling without requiring a full rebuild of the stack every few months.

The important part is that the premium plan sits at the coordination layer, not the model layer. The point is not to pay for one more model. The point is to pay for a better conductor for the models I already have access to.

ABM landing pages for maritime cybersecurity

Richard Lemon — Sun, 16 Aug 2026 11:52:41 +0000

Industrial B2B meets product-page UX

Account-based marketing can look tidy in a deck and messy in a browser. The tension is sharp when you mix an industrial niche like maritime cybersecurity with expectations shaped by modern product pages.

The Blackhole Networks case sits in that gap. On one side are complex, high-stakes problems around ships, ports, OT networks, and regulatory pressure. On the other are buyers who expect clarity, proof, and a clear next step.

A useful way to frame the work is a simple question: what needs to change between a generic homepage and an ABM landing page for a specific maritime account?

Why a generic homepage is the wrong tool

A generic homepage has to do too many jobs at once. It has to explain the company, route different audiences, and show some credibility. That usually leads to safe, abstract copy and a lot of navigation.

For a visitor from a named maritime account, that is almost the opposite of what you want. They already know roughly who you are. They arrive from targeted outreach or a campaign built for their segment. Sending them to the homepage is like inviting someone to a meeting and then handing them your company brochure.

Three things tend to be missing when you treat ABM traffic like generic traffic:

There is no focused way to capture the lead.
There is not enough visible social proof.
The copy does not speak in the language of the sector.

The Blackhole Networks case is a way to look at those gaps in a maritime context.

1. Lead capture: from “contact us” to a specific next step

Many industrial cybersecurity sites rely on a “Contact” link in the header and a form in the footer. That is acceptable for general inbound, but weak for ABM. If there has already been investment in targeting and outreach, the page should behave more like a product page: clear offer, clear action.

On the ABM side, that usually means a dedicated landing page with:

A single primary call to action, not several competing buttons.
A form that matches the value on offer, instead of a generic “get in touch”.
Copy around the form that reminds the visitor why this is worth their time.

For maritime cybersecurity, the question is not “contact sales” but “what is a low-friction, high-relevance step for a port IT lead or fleet security officer?” The exact answer will differ per company, but the UX pattern is consistent: treat the ABM page like a focused product page, not a mini homepage.

2. Social proof that speaks to risk, not just logos

In industrial B2B, it is common to show a strip of client logos and call that social proof. It is better than nothing, but it does not help a maritime buyer connect an offer to their specific risk profile.

On an ABM landing page, social proof can be much more specific:

Short, concrete statements about outcomes relevant to maritime operations.
References to similar environments: ports, vessels, OT networks, or regulatory regimes.
Comments or summaries of feedback from roles that match the target account’s team.

The pattern comes from product pages: you do not just show that people use the product, you show that people like the target account use the product for a clear reason. In a maritime cybersecurity context, that might mean emphasizing uptime, incident response, or audit readiness rather than generic “security posture” language.

3. Sector-specific copy instead of generic cybersecurity language

Generic homepages tend to talk about “organizations” and “businesses” and “digital transformation”. That is safe, but it does not sound like a port or a shipping company. It sounds like a template.

ABM landing pages have the room to be more direct:

Use the domain language of the sector: vessels, terminals, OT, shoreside networks, fleet operations.
Refer to the kinds of incidents and constraints that matter in that world.
Frame benefits in terms of day-to-day reality: delays, downtime, inspections, and crew impact.

This is where a product-page mindset helps. A good product page does not describe a category. It describes a specific use case in specific terms. Applied to maritime cybersecurity, that means writing as if you are already inside their environment, not pitching from the sidewalk.

Mixing industrial B2B with product-page UX

Industrial buyers use consumer apps and SaaS tools all day. They are used to clarity and low-friction flows. The useful move is to borrow the right patterns without pretending maritime cybersecurity is a simple subscription.

Some of the product-page patterns that translate well:

Hero section with a sharp promise: One line that connects capability to a maritime-specific outcome, not a long mission statement.
Problem / solution layout: Short blocks that describe concrete operational problems and how the offer addresses them.
Minimal navigation: Enough to orient, not enough to distract from the main call to action.
Scannable structure: Clear headings, short paragraphs, and visual hierarchy that respect short attention windows.

What does not translate is a casual tone. Maritime cybersecurity is attached to physical risk and regulatory pressure. The page can be clear and modern without being flippant.

From homepage to ABM: a phased rollout

Shifting from a single generic homepage to a set of ABM landing pages is usually easier in phases than as a big relaunch, and the Blackhole Networks work followed that logic.

The first phase is structural: define the core layout, decide how lead capture will work, and identify the places where social proof and sector-specific copy need to live. This is the point where product-page patterns are selected and adapted.

The second phase is about content. For maritime cybersecurity, that means gathering the right language from sales conversations, incident reports, and existing clients, then shaping it into copy that can live on a page. The same structure can support other sectors later, but the first version should be unapologetically specific.

The third phase is account-specific refinement. Once the base maritime page exists, it can be cloned and adapted for individual named accounts: adjusting examples, emphasizing certain outcomes, or aligning with their internal terminology. The UX and structure stay stable while the message tightens around each target.

This phased rollout keeps the risk manageable. A single maritime ABM page can sit alongside the existing homepage, a small number of accounts can be routed to it, and the results can inform the next iteration.

What changes when you take ABM seriously

The interesting part of mixing industrial B2B with product-page UX is not the visual layer. It is the shift in what the page is for.

A generic homepage tries to tell the whole story. An ABM landing page for maritime cybersecurity has a narrower job: help one type of buyer at one type of company decide whether to take one specific next step.

Once you design for that, the missing elements become obvious: you need lead capture that fits the offer, social proof that speaks to their risk, and copy that sounds like their world. The rest is implementation detail.

Letting AI refactor one legacy stylesheet

Richard Lemon — Thu, 13 Aug 2026 13:06:26 +0000

The patient: one legacy Sass file

The target was a legacy client CSS file: about 1,200 lines of hand-written Sass from before Tailwind was standard at Ideebv. It defined 47 component classes, 12 utility classes that duplicated Tailwind defaults, and a section of commented-out gradients from a 2021 rebrand.

I fed the whole thing to Claude with a single prompt:

“Refactor this to Tailwind v3 utility classes where possible, preserve the custom properties, and flag anything that looks dead.”

What came back was a neatly formatted diff that looked reasonable at first glance. The real work started after that, going line by line and deciding what to accept, what to change, and what to reject.

The audit took 45 minutes: about 20 minutes to get a usable diff, and 25 minutes to verify the context and consequences. The file ended up cleaner. The interesting part is how that happened.

What I accepted: mechanical spacing refactors

The safest chunk was spacing. The original Sass was full of declarations like:

.card {
  margin-top: 24px;
  padding: 0 16px;
}

Claude systematically mapped these to Tailwind utilities:

margin-top: 24px; became mt-6
padding: 0 16px; became px-4

It also correctly identified that the client’s spacing scale was already on a 4 px base, so 4 px increments lined up with Tailwind’s default spacing scale. In total it caught 89 instances that were exact, lossless translations from raw values to Tailwind classes.

I accepted these without modification. They were pure syntax transformations: no layout changes, no semantic changes, no new assumptions about the design system. Just shorter, more consistent code.

What I changed: color mappings without project context

Colors were where “looks right” and “is right” diverged.

The original Sass used custom properties like:

.btn-primary {
  color: var(--brand-primary);
  background-color: var(--brand-primary);
}

Claude suggested converting these to Tailwind’s default color utilities:

color: var(--brand-primary); → text-blue-600
background-color: var(--brand-primary); → bg-blue-600

The pattern was sane: replace custom color declarations with semantic Tailwind classes. The problem was the data behind it. This project has a custom tailwind.config.js that maps a brand color token to a specific hex value that is not Tailwind’s default blue.

The AI had no access to that config. It guessed. The guess was wrong.

I kept the structural idea but changed the actual classes to:

text-brand instead of text-blue-600
bg-brand instead of bg-blue-600

So the refactor went in two steps:

Let AI propose a mapping pattern from custom properties to Tailwind utilities.
Replace the guessed tokens with the project’s real design tokens.

On paper that looks like a small edit. In practice this is the line between “AI refactored my CSS” and “AI suggested a template, and I refactored my CSS using it.” The syntax was automated. The semantics still came from the project’s existing design system.

What I rejected: grid architecture changes

One component used a CSS Grid setup with subgrid for alignment. The idea was that nested cards should align their internal rows across columns, so when content varied in length, the visual grid still lined up. The key line was:

grid-template-rows: subgrid;

Tailwind does not yet support subgrid natively, and Claude did not recognise why it was there. It proposed replacing the whole grid with a simpler layout:

grid-cols-4 for the outer grid
A flex-based workaround for the inner layout, with fixed heights to “stabilise” rows

On real content, that would have broken as soon as one card had longer text than the others. The entire point of the original subgrid setup was to avoid exactly that failure mode.

I rejected the suggestion and kept the original CSS grid declaration. I also added a comment to make the constraint explicit:

/* Using subgrid to align card rows across columns.
   Tailwind does not support this yet; do not replace with grid-cols-* or flex.
*/

This was the first place where the cost of verification showed up clearly. The AI could rewrite the layout syntax, but it could not see the layout behaviour or the design intent. It saw an opportunity to use Tailwind utilities; it did not see the trade-off it was making.

What I rejected: “unnecessary” pseudo-elements

The file also contained ::before pseudo-elements used for decorative-looking borders. Claude flagged them as “likely unnecessary visual noise” and suggested removing them to simplify the CSS.

What was not in the file was the reason they existed. Those pseudo-elements were part of a specific accessibility requirement for the client’s WCAG 2.2 compliance audit. They provided a visible focus indicator for keyboard navigation. No pseudo-element, no visible focus ring. No visible focus ring, no compliance.

The AI saw CSS. It did not see the legal and accessibility constraints behind it.

I rejected the removal and added another explicit comment:

/* ::before used for WCAG 2.2 focus indicator.
   Required for accessibility audit. Do not remove.
*/

This is where a “helpful cleanup” could have turned into an expensive regression. Not because the model was malicious, but because it had no way to know which parts of the file were bound to requirements that lived in tickets, audits and contracts, not in code.

The time balance

On paper, the numbers looked like this:

45 minutes total for the audit
20 minutes to generate and massage the diff into something usable
25 minutes to verify context and decide on three architectural calls

The AI saved me the manual typing of 89 Tailwind spacing replacements. It also tried to “help” with three structural changes: color tokens, grid layout, and focus indicators. All three needed correction or rejection because they depended on project context the model could not see.

The net result was a cleaner file, fewer one-off spacing declarations, and a bit more documentation around the tricky bits. That was not AI magically refactoring a legacy stylesheet.

AI refactored CSS syntax. A human still had to refactor CSS meaning.

Replacing Three Client Dashboards With One Local n8n

Richard Lemon — Thu, 13 Aug 2026 13:05:43 +0000

The client problem: three logins for one simple question

A client needed recurring reports from three separate tools. Nothing fancy: pull the latest numbers, clean them up, and send them in a format they could actually use.

The pain wasn’t the data. The pain was access. They had:

Three different dashboards
Three different URLs and login flows
Three different ideas of what “last month” means

Every time someone new joined their team, they had to be onboarded into this little zoo of dashboards. Every time someone left, they had to be offboarded from the same zoo. Nobody was sure which dashboard was the source of truth, so people ended up screenshotting charts into slides anyway.

The question behind all of this was simple: “Can we just get the reports in one place?”

One n8n instance instead of three dashboards

One way to answer that question is to run a single n8n instance locally. Instead of sending the client into three web apps, the automations run in the background and hand them the result in one consistent format.

On the n8n canvas, a setup for this kind of reporting might look like:

Three data source nodes (one for each tool)
Transformation nodes to normalize fields and dates
A formatting step to build a clean report
An output step that delivers the report on a schedule

The client never has to see n8n. They just see a single link or a recurring email. No extra login, no jumping between products to answer one question about their numbers.

Why local automation beats another SaaS subscription

Plenty of SaaS automation tools can connect APIs and schedule workflows. The difference is where the workflows run and where the data flows.

With a local n8n instance:

The workflows run on a machine you control.
API keys and secrets stay in your environment.
Client data doesn’t pass through another company’s servers.

For recurring client reports, that matters. You are often touching:

Revenue and conversion data
User behavior and identifiers
Internal performance metrics

Every extra SaaS tool in the chain is another privacy policy, another DPA, and another potential leak path. Keeping the automation local keeps the blast radius smaller.

Control beats feature lists

Cloud automation platforms tend to sell you on connectors and templates. Local automation is about control.

With a local n8n instance you decide:

When to update
How to back up
Which ports are open
How logging is handled

For client work, that control maps directly to trust. When a client asks where their data goes, you can give a concrete answer instead of pointing at a long list of sub-processors.

Cost difference vs Make.com

There is also the recurring cost angle. A typical Make.com setup that replaces three client dashboards usually means:

A paid scenario with enough operations to handle scheduled reports
Extra headroom for spikes and retries
Potential overage if a client wants more frequent reporting

With n8n running locally, the cost is mainly:

The server or machine you already have
Your time to set up and maintain workflows

There is no per-scenario or per-operation billing. Once an instance is running, adding a new client report is mostly a matter of cloning and adjusting an existing workflow instead of upgrading a SaaS plan.

Over a year of recurring reports, the difference between a fixed local setup and a growing Make.com bill can be significant, especially if you are handling multiple clients.

Client experience: fewer doors, clearer answers

From the client’s perspective, the win is simple: they go to fewer places to get the data they care about.

Instead of:

Logging into three dashboards
Exporting CSVs
Copy-pasting numbers into a slide

They get:

One report, delivered consistently
One definition of each metric
No extra logins to remember

They do not need to learn new tools just to check their own performance. The automation takes that complexity away.

When local n8n is a better fit than cloud automation

Local n8n starts to look better than a SaaS automation platform when:

You are handling recurring reports across multiple tools
Clients care about where their data lives
You want predictable costs instead of usage-based billing
You prefer to keep infrastructure under your control

There are cases where a SaaS tool still makes sense, especially for quick one-off integrations or when a team wants a non-technical interface. But for recurring client reporting with sensitive data, a single local n8n instance can quietly replace a surprising number of dashboards and subscriptions.