DEV Community: Richard Lemon

Why I Track HRV Every Morning (And How It Actually Changes My Day)

Richard Lemon — Mon, 25 May 2026 05:00:00 +0000

HRV is only useful if it changes your day

I have tracked HRV every morning for a few years now. Not because I like graphs. Because it is the only number that consistently talks back when I am lying to myself.

I build web stuff, coach baseball, and play the biohacker hobby game. That combination makes it very easy to run on willpower and caffeine until something breaks. HRV is my early warning system.

But here is the key point. I do not care about the exact number. I care about what I do differently because of it. No behavior change, no point.

The setup: cheap, boring, and consistent

I do not treat HRV like a gadget fashion show. I want boring and repeatable.

My morning routine:

Wake up, bathroom, water.
Sit on the same chair.
Same 60–90 second HRV reading with a chest strap and phone app.
Eyes open, normal breathing, no breathwork tricks.

I care about three things only:

My rolling baseline. Roughly the 7–30 day trend.
Today vs that baseline. How far up or down.
Direction. Is it drifting up, flat, or sagging over a few days.

The app gives me a recovery score. That score is just math on top of the HRV number, but it is easier to work with a simple traffic light in my head.

The traffic light: green, yellow, red

I run my life on a very dumb, very useful mental model.

Green: Nervous system looks ready. HRV at or above baseline. Resting heart rate normal.
Yellow: Slightly suppressed HRV or resting heart rate a bit elevated, or both. Body is stressed but not falling apart.
Red: Noticeably down HRV, sometimes paired with a big bump in resting heart rate, plus I feel like cardboard.

That is it. No decimal worship. I do not care if my RMSSD is 68 or 72. I care if the light is green, yellow, or red and where that sits relative to my baseline.

The important part is what I decided in advance for each color. If you make rules on the spot you will negotiate yourself into dumb decisions.

Green days: permission to go heavy

On a green day, I treat HRV clearance as permission. Not as pressure.

I have three decision buckets that change when I see green: training, work, and recovery inputs.

Green training rules

Green usually means:

Hard session goes ahead: heavy lifts, sprint work, or a tough baseball practice.
Volume is allowed to climb: I may add a set or two, or stretch the conditioning a bit.
Experiment window is open: if I want to test a new drill, a different sprint pattern, or a new strength block, I try it on a green day.

Example from last month: I had a planned heavy lower body day with some sprint repeats. HRV was clearly green, slightly above baseline after two nights of solid sleep. Instead of just running the default, I pushed the sprint count by 20 percent and added one heavier top set on squats.

The session felt good, no grindy reps, and HRV stayed stable the next morning. That told me my body could handle that new load. So I locked that progression in as the new normal for the block.

Green work rules

Green day equals high-quality cognitive work window.

I schedule my hardest coding or design work as early as possible.
I avoid early calls. I move meetings to the afternoon if I can.
If there is a tricky refactor or a gnarly WebGL experiment, this is the day.

HRV does not directly tell me about focus, but there is a pattern. When recovery is solid, my willingness to sit with hard problems is much higher.

Green recovery rules

When I see green I do not celebrate with junk behavior. I do the opposite.

Keep caffeine normal, do not double it just because I feel good.
Stick to my usual bedtime rather than “rewarding” myself with a late night.
Give myself a small recovery boost, like a longer walk in the sun.

Green is where you build new capacity. You can only do that if you do not instantly spend all the extra energy on random nonsense.

Yellow days: ego control territory

Most days are not green or red. They are slightly off. That is where the traffic light actually earns its keep.

Yellow is where my ego wants to ignore the data. This is also where I have made the most dumb training mistakes in the past.

Yellow training rules

On a yellow day I do not cancel training. I change the framing.

Intensity stays, volume drops: I still lift heavy or move fast, but I cut sets or total reps.
Or volume stays, intensity drops: I keep the number of sets, but I stay well away from failure and keep heart rate lower.
No new experiments: I do not test 1RMs, new sprint distances, or brutal circuits.

Concrete example. My HRV is slightly below baseline after a late-night game or a long coding session that turned into a 1 AM situation. I had planned 5 x 5 heavy bench and a bunch of accessory work.

On a yellow day, I might keep the 5 x 5 but drop the load by 5–10 percent, skip one accessory exercise, and cut conditioning in half. I still show up. The workout still happens. I do not dig a deeper hole.

Yellow work rules

Yellow days are for progress without heroics.

Ship small pieces. Fix bugs, clean up code, handle admin.
Push big decisions to a green day if possible.
Be very suspicious of “one more hour” thinking in the evening.

If I force a late-night coding binge on a yellow day, HRV usually hits red the next morning. I have seen that pattern enough times to consider it basically deterministic for me.

Yellow recovery rules

On yellow I start turning dials.

Earlier cutoff for screens and work.
A bit more carbs in the evening to support sleep.
Move non-urgent life tasks to another day.

The idea is simple. Yellow means “you are drifting.” I want to see if I can pull myself back toward green tomorrow without skipping life.

Red days: forced humility

Red is where HRV saves me from myself. This is the only color where I am willing to scrap the plan completely.

Red usually comes from one of a few predictable causes for me:

Travel and broken sleep.
Back-to-back high intensity days because I ignored a yellow signal.
Getting sick, or fighting something off.
Two days of very late games or events.

Red training rules

On a red day I have a simple default.

No high-intensity training.
LISS cardio only: easy walk, light bike, mobility.
If I feel awful, full rest.

If I already stacked a few red or deep yellow days in a row, I usually remove any training pressure completely. I let the system reset. Every time I ignored that, HRV punished me with a longer slump and worse sleep.

One specific pattern: if HRV tanks and resting heart rate is up, and perceived effort spiked on what should have been an easy session the day before, I do not negotiate. I shut it down for that day. That combo almost always means something is off globally, not just “I am a bit tired.”

Red work rules

On red days I lower the ambition floor.

Cancel non-essential meetings if I can.
Move deep work to another day. Only do it if I somehow feel unusually sharp despite the score.
Knock out simple, mechanical tasks and stop pretending I will architect a whole new feature set in that state.

I had to get over the guilt of this. But every time I pretend I am fine on a red day, I pay for it later with sloppy code and more time spent fixing mistakes.

Red recovery rules

Red is where I go heavier on interventions.

Hard stop on screens at least an hour before bed.
Light dinner, no late heavy meals.
Walks instead of workouts, sunlight early in the day.
If possible, a short nap, but capped so I do not wreck the night.

I also use red days as an audit. Why am I here? Was it a one-off travel day or have I been stacking small stupid decisions for a week?

Where HRV actually changed my behavior

HRV itself did not change much in my life on day one. The traffic light and pre-committed rules did.

Here are a few specific shifts that stuck.

I stopped pretending sleep does not matter

Before HRV, I treated sleep like a flexible variable. If I wanted to code late or watch a game, I did it. I would “catch up” later.

HRV showed me something simple. Two short nights do more damage than one really short night. The second late night pushes the nervous system into a state where the next day is always worse than it feels in the moment.

Green-to-red swings after stacked short nights convinced me to protect at least five nights a week. I still have late nights, just fewer in a row.

I stopped proving toughness to no one

Most of the athletes I coach, and most developers I know, have the same problem. We mistake stubbornness for discipline.

HRV gave me a clean excuse to stop that. If the score is red and the trend has been sliding for three days, I do not get bonus points for “pushing through.” I get slower progress and more nagging injuries.

It took a while, but now if the traffic light is red and I still feel the itch to max out something, I treat that as a bug in my behavior, not a sign of commitment.

I started planning weeks, not days

Tracking HRV showed me that what I do on Monday is still echoing around on Thursday.

So now I design weeks around likely traffic lights:

Monday and Thursday are likely green: main heavy training and hardest coding.
Tuesday and Friday are more flexible: if I see yellow, those become lighter work or technique days.
Weekend is the buffer: travel, games, or family stuff that may push HRV around.

This is not perfect. Life rarely respects my plans. But thinking in terms of green / yellow / red probability has made my training blocks far more stable.

HRV is not a boss, it is a negotiating partner

I do not outsource decisions to HRV. I use it as one more voice in the room.

Sometimes I override it. For example, if it is a once-a-year event or competition, I am going to show up and do the thing, even on a red day. I just go in with my eyes open. I expect a recovery tax afterwards and I plan around it.

Most days though, the traffic light is enough to keep my ego in check and my training productive.

If you want to steal this system

If you want to copy anything here, copy the decision loop, not the tech.

Pick one HRV method. Keep it boring and consistent.
Track for a few weeks without changing anything just to see your baseline.
Define your own clear green, yellow, red thresholds in that app or in a notebook.
Write down rules for each color before you see the next score.
Commit to following those rules for a month and see what happens to performance and mood.

I think most people obsess over gadgets and miss the point. HRV is not about who has the highest number. It is about having a simple, brutally honest mirror that you agree to listen to every morning.

That is why I still track it. Not because I care about today’s exact milliseconds. Because it changes what I do at 9 AM.

The Make.com Modules I Actually Use Every Week (And The Ones I Killed)

Richard Lemon — Sat, 23 May 2026 22:00:00 +0000

The problem with my Make.com setup

I use Make.com a lot. Client work, my own projects, experiments, tracking weird biohacking data, even baseball stuff. It started simple. Then, like every tool I enjoy, it turned into a zoo.

Too many scenarios. Too many modules. Too many runs where I had to ask: “Why did this even fire?”

A few months ago I did a hard audit of all my Make scenarios. Not a theoretical one. I looked at what ran weekly, what broke, what I ignored, and what quietly ate time and operations without giving anything back.

This is the result. The Make modules that actually earn their place in my stack every week. And the ones I stopped using because they were just clever complexity.

Ground rules for staying in my stack

I started by setting a few brutal rules. A module or pattern had to tick at least one of these boxes to survive:

It removes a recurring manual task I was doing at least weekly.
It surfaces information I actually act on within 24 hours.
It is easy to debug at 23:30 when a client pings me.

If a module only existed because it was “cool” or because some YouTube tutorial said it was “powerful”, it went on the chopping block.

With that, here is what survived.

HTTP modules: boring, essential, everywhere

If Make.com removed the HTTP modules tomorrow, half my setup would die. HTTP is my default way to talk to anything that does not have a decent Make app, or has one but I do not trust it.

The ones I use every week:

HTTP → Make a request For hitting custom webhooks, internal tools, small APIs I host on cheap servers.
Webhook → Custom webhook For receiving events from my own apps and client projects.

Example from my actual stack. I have a tiny Go API that aggregates baseball practice data, sleep metrics, and a couple of biomarker logs. Make calls this API via HTTP every morning at 06:00, does a bit of mapping, and posts a summary into a private Slack channel I call #body-log.

I used to run this through three different native integrations. It broke often. I was constantly re-authing things. Replaced everything with one HTTP module, one custom webhook, and a small script on my server. Zero regrets.

Module verdict: HTTP stays. Always.

Routers + filters: my actual “no-code if/else”

I tried to avoid routers for a while. They felt heavy and visually noisy. Then I realised I was trying to fake routers with duplicated scenarios and filters at the start. That was worse.

Now I use routers and filters in almost every scenario that survives longer than a week.

Typical weekly pattern. I have a master “events in my world” scenario. It listens to webhooks from:

My portfolio contact form
Client project error hooks
New newsletter signups
Some very opinionated monitoring pings I run on my infra

One router. Four paths. Each path has a very clear filter like “type = 'contact_form'” or “severity >= 'error'”. The outputs hit different Slack channels, different Notion databases, and in one case an SMS if it is client-critical.

The important part. I stopped doing clever nested routers. One level only. If I need more logic than that, it goes into my code, not into Make.

Module verdict: Routers stay, but only one level deep.

Slack: my notification bus, not my database

Slack is my broadcast layer. Not my brain. Not my storage. If a scenario ends in Slack, I either need to react or at least see it once. Otherwise it should not go there.

Modules that run every week:

Slack → Create a message For system alerts, new leads, and health summaries.
Slack → Create a scheduled message For repeating nudges. Example: a weekly prompt to do a quick retrospective on projects and training.

One specific flow. When someone fills in a project inquiry on my site, Make receives the webhook, tags it based on budget and timeline, pushes it into a Notion CRM database, then posts a short summary to #inbox with a direct “Reply in under 12 hours” reminder tag.

I used to push every possible event into Slack. Deploy hooks. CI results. New followers. Half of that turned into noise. I killed an entire category of Slack notifications and did not miss them once.

Module verdict: Slack stays, but only for things I can act on quickly.

Notion: slow, slightly painful, still very useful

I have a love-hate relationship with Notion as an API target. It is not fast. It is sometimes weird with rate limits. But it sits in the middle of how I plan work and content, so I tolerate it.

Every week I use:

Notion → Create a database item Anything that should live longer than a notification.
Notion → Update a database item For syncing status from other tools.

One concrete example. For this blog, I draft in Markdown locally. When I push a new post into my Git repo, a small server-side hook hits Make via webhook. Make then creates or updates a Notion page in my “Content Log” database with:

Title
Slug
Status (Draft, Scheduled, Live)
URL
Technical notes (stack, integrations, experiments)

I used to manage that inside Notion directly with templates and properties and a whole ceremony. Now Make is the bridge from my real workflow (git, editor, deploy) into my “remember this later” tool.

What I stopped doing. I used to sync every little metric into Notion. Newsletter subscriber counts. Basic analytics. It felt like a quantified self dashboard. I never looked at it. Now I only store artefacts and decisions, not vanity numbers.

Module verdict: Notion stays, but only for durable records, not dashboards.

Google Sheets: my scratchpad and debug console

I think Google Sheets is underrated as a Make companion. Not as a database, but as a scratchpad.

Weekly modules:

Google Sheets → Add a row For lightweight logging and temporary reports.
Google Sheets → Get a cell / Get a row For quick lookups when a real database would be overkill.

Example. During a recent experiment on sleep and training volume, I patched together data from several APIs that did not agree on timestamps or time zones. Before building a nice pipeline, I sent everything to a Google Sheet first. One flat sheet. One row per event. Timestamps, scores, tags.

I used that as a human-readable debug view while I iterated on the mapping logic in Make. Once I trusted the pipeline, I replaced the sheet with a proper HTTP call into my API. The sheet scenario is still there, just turned off. It is my “turn this on for debugging” escape hatch.

Module verdict: Sheets stays as my visible logbook, not as core storage.

Text & data transformers: the unsung heroes

If a Make scenario feels complicated, it is usually because I forgot that Make has a lot of little transformer modules and functions that remove the need for code.

Every week I use:

Text parser and regex-related functions For pulling IDs out of URLs, cleaning labels, normalising tags.
Formatter → Date and time For making timestamps actually readable and consistent.
Array → Aggregate / Iterator For reshaping messy API responses.

One real scenario. My monitoring setup sends JSON payloads with long nested structures. Make receives them, then I use “Iterator” to walk through failing checks, clean each label with a Text function, and then aggregate them back into a compact Slack message.

I used to firehose the raw JSON into Slack. No one read it. Not even me. Now the message is human-sized and I only link to the raw payload when I actually need to debug.

Module verdict: These stay. They make other modules simpler.

The modules I stopped using regularly

Now the fun part. The tools I actively moved away from. Some of them are great on paper, just not for how I work.

Gmail & email modules as the primary trigger

I used to have a bunch of scenarios that started with “New email in Gmail” or “Watch emails”. They tried to be smart. Auto-labeling. Auto-forwarding. Auto-creating tasks.

The problem. Email is already messy. Adding an automation layer that sometimes works and sometimes does nothing makes it worse. I also do not want to give every automation direct access to my entire inbox.

What I do instead. Email is almost always the output now, not the input. If something critical happens in a system that is not wired into my attention stack, I send myself a short email. That is it.

Module verdict: Gmail triggers are out. Email stays as occasional output only.

Make Data Store as a hidden database

Make has a built-in Data Store. On paper it is convenient. Throw key-value pairs in there. Persist things. Done.

In practice, I found it dangerous. It is invisible from the outside, hard to migrate, and a bit too easy to rely on for critical data. I had one scenario where I used Data Store to track daily task limits per client. When I rebuilt that scenario a year later, I forgot the Data Store even existed and almost wiped it.

Now I keep state either in my own API, in a real database, or in something like Notion if the stakes are low. Data should live somewhere I can back up, inspect, and move without Make in the middle.

Module verdict: Data Store is out for me, except for throwaway experiments.

Scheduling heavy logic directly inside Make

I went through a phase where I tried to make Make my central scheduler. Complex recurring jobs. Custom repeat rules. User-specific offsets. You can do it. I did. It was fragile.

Make is great at “When X happens, do Y”. It is less great at being a full-on job scheduler for dozens of different rules and calendars. Especially once you start mixing time zones.

Now I keep scheduling logic in my own services. They decide when to call Make, usually via webhook. Make just does the orchestration work.

Module verdict: Advanced scheduling inside Make is out. I trust my own code for that.

Over-using search modules as if Make was my search engine

Make has lots of “Search” modules. Search rows. Search pages. Search messages. I abused them early on.

Pattern looked like this. Scenario triggers. Then: “Search X by Y” to find a record. Then update it. Worked fine at small scale. Terrible once you grow a bit. Slow. Expensive. Painful to debug when matching goes wrong.

These days I try to design flows so I always pass IDs around explicitly. When something is created, I keep the identifier and store it in the other system right away. No more “guess which row” logic.

Module verdict: Search is a fallback now, not a default.

How I decide if a new module earns a place

Every time I add a new module or app into my Make world, I run it through a simple checklist.

Can I explain this scenario in one sentence? If I cannot, it is already too complex.
Can I debug it half-asleep? If an error email at midnight would confuse future me, I simplify it.
Can I rebuild this without Make? If the answer is no, I am locking too much into one tool.

Make is fantastic glue. It is not my app platform. It is the thing that connects my apps, my scripts, and the buckets where I keep data.

The modules that survived this audit all share one thing. They do boring, reliable work. HTTP moves data. Routers branch logic. Slack shouts when something matters. Notion stores decisions. Sheets gives me a visual log. Everything else is optional.

If your Make account feels loud and untrustworthy, I would start there. Open your scenario list. Sort by last run. Keep what actually runs weekly and makes your life easier. Kill the rest. You will not miss as much as you think.

CSS :has() Selector: The Layout Trick I Wish I Knew 5 Years Ago

Richard Lemon — Sat, 23 May 2026 05:00:00 +0000

CSS :has() is not just a fancy :parent

When :has() started popping up in specs and tweets, I mentally filed it under “cool, but not for shipping work.” I was wrong.

Now it is in Chrome, Safari, Edge, and Firefox. I use it in real projects. It has removed entire JavaScript files and a pile of .is-active classes that I was embarrassed to maintain.

If you are a working frontend dev, the shorthand is this: :has() turns CSS from “style what is there” into “style this thing if it contains that thing”. That one capability changes layout, state, and validation flows.

I will walk through three places where it made a real difference for me:

Parent styling without JS
Sibling state UIs without wiring events
Form validation UI that reacts to the DOM, not a framework

All of this shipped with zero additional JavaScript.

Quick mental model of :has()

The syntax looks like a pseudo class on a selector:

.card:has(img.hero) {
  /* styles here */
}

Read it as: “select .card elements that have a descendant img.hero somewhere inside.” It is a conditional filter on the left side of the selector.

You can also scope it more tightly:

.tabs:has(> .tab.is-active) {
  /* direct children only */
}

Or use it with relational selectors like siblings:

.field:has(+ .field--error) {
  /* this .field is followed by an error field */
}

Once that clicks, you start seeing places to remove JS.

1. Parent styling in a content-heavy project

First real use: a content-heavy marketing site for a biohacking brand I work with. Editors can drop components in any order with a CMS. Sometimes a card has an image, sometimes it is text-only. The layout should adapt.

Previously I solved this with modifier classes from the CMS, or a hydration script that scans the DOM and adds classes like .card--with-media. Boring, fragile, and slightly gross.

With :has() I deleted that script.

Image-aware cards

The card markup is boring on purpose:

<article class="card">
  <img class="card__media" src="hero.jpg" alt="">
  <div class="card__body">
    <h2>Title</h2>
    <p>Some text...</p>
  </div>
</article>

<article class="card">
  <div class="card__body">
    <h2>Another Card</h2>
    <p>Text-only card.</p>
  </div>
</article>

Now the CSS decides layout based on presence of media.

.card {
  display: grid;
  gap: 1rem;
}

.card:has(.card__media) {
  grid-template-columns: minmax(0, 2fr) minmax(0, 3fr);
  align-items: center;
}

.card:not(:has(.card__media)) {
  padding: 2rem;
  background: #111;
  color: #eee;
}

Result: if marketing drops in an image, the card becomes a two-column layout. If not, it becomes a full-width text block. No new class. No CMS configuration. No JS.

I like this because the markup stays semantic and dumb. The layout is a true function of the content, which is what CSS was always supposed to do but rarely could at the parent level.

Auto-promoting “hero” sections

Same project. Editors could add a .section stack: some had a prominent CTA, some were just copy. If a section had a primary CTA, design wanted extra padding and a gradient background.

<section class="section">
  <h2>Get early access</h2>
  <p>Short description.</p>
  <a class="btn btn--primary" href="#">Join the beta</a>
</section>

<section class="section">
  <h2>What you get</h2>
  <p>More text...</p>
</section>

With :has() I treat any section with a primary button as a pseudo hero.

.section {
  padding: 2rem 1.5rem;
  background: #050505;
}

.section:has(.btn--primary) {
  padding: 4rem 1.5rem;
  background: radial-gradient(circle at top, #2f80ed, #050505);
  color: #fff;
}

.section:has(.btn--primary) h2 {
  font-size: 2.25rem;
}

That tiny selector replaced a custom “hero” block type in the CMS that content editors kept misusing. I stopped explaining “use the hero component for this” and just let the CSS infer intent from presence of a primary CTA.

You can do similar things with :has(video), :has(.badge--new), etc. It is a good fit for messy CMS content where you want layout to respond to what your editors actually do, not what the schema designer hoped they would do.

2. Sibling state UIs without event listeners

Second use case: stateful UIs that I used to wire up with click handlers. Tabs, disclosure panels, navigation highlights, that stuff.

Yes, you can still do it in JS. But if the state is already visible in the DOM, :has() lets CSS own more of the behavior. That means less code, fewer states to sync, and fewer bugs.

Tabs powered by :target and :has()

On a little side project for baseball drills, I built a tabbed interface where each tab is actually a link to an anchor. I wanted a sticky tab bar that changes style when any tab content is active.

<div class="tabs">
  <nav class="tabs__nav">
    <a href="#hitting">Hitting</a>
    <a href="#pitching">Pitching</a>
    <a href="#fielding">Fielding</a>
  </nav>

  <section id="hitting" class="tabs__panel">...</section>
  <section id="pitching" class="tabs__panel">...</section>
  <section id="fielding" class="tabs__panel">...</section>
</div>

The panels show / hide with a regular :target trick.

.tabs__panel {
  display: none;
}

.tabs__panel:target {
  display: block;
}

Old me would now add JS to toggle classes on the nav. Instead I lean on :has().

.tabs {
  border-bottom: 1px solid #333;
}

.tabs__nav a {
  padding: .5rem 1rem;
  text-decoration: none;
  color: #888;
}

.tabs__nav a:is(:hover, :focus-visible) {
  color: #fff;
}

/* highlight the active tab label */
.tabs__nav a[href^="#"] {
  position: relative;
}

.tabs:has(#hitting:target) .tabs__nav a[href="#hitting"],
.tabs:has(#pitching:target) .tabs__nav a[href="#pitching"],
.tabs:has(#fielding:target) .tabs__nav a[href="#fielding"] {
  color: #fff;
  font-weight: 600;
}

/* make the whole tabs block look active if any panel is targeted */
.tabs:has(.tabs__panel:target) {
  border-color: #2f80ed;
}

I am not pretending this scales to 50 tabs. For most content UIs, 3 to 5 tabs is realistic. Writing those few selectors is still cheaper than adding a tab manager, handling history state, and worrying about hydration.

The key pattern is: some child panel already has state via :target or [aria-selected="true"]. Let :has() bubble that state up to parents and siblings.

Accordion with native <details> and :has()

I use <details> a lot. It is surprisingly powerful with :has(). On a settings panel I wanted the container to visually compress when no section was open, then expand once any accordion entry was open.

<section class="settings">
  <details class="settings__item">
    <summary>Profile</summary>
    <div>...</div>
  </details>
  <details class="settings__item">
    <summary>Privacy</summary>
    <div>...</div>
  </details>
</section>

CSS:

.settings {
  padding: 1rem;
  border-radius: .75rem;
  border: 1px solid #333;
  max-height: 60vh;
  overflow: auto;
  transition: box-shadow .2s ease, border-color .2s ease;
}

.settings:has(.settings__item[open]) {
  border-color: #2f80ed;
  box-shadow: 0 16px 40px rgba(0, 0, 0, .55);
}

.settings__item + .settings__item {
  border-top: 1px solid #222;
}

.settings__item summary {
  cursor: pointer;
}

Once any <details> is open, the whole settings block feels “in focus”. No JS to listen for the toggle event, no syncing of .is-active classes. The HTML already has [open]. CSS reacts.

3. Form validation UI with zero JavaScript

The biggest win for me: form UI that uses :has() with built-in browser validation. No client-side validation library. No “touched” state juggling.

On my own site I revamped a contact form and a simple experiment log form. I wanted:

Parent field wrappers that highlight error or success
Inline messages that only show when actually invalid
Submit button that changes state based on form validity

Browser validation already tracks validity. The DOM knows. :has() lets CSS hook into that.

Field states from input validity

Markup:

<form class="form" novalidate>
  <div class="field">
    <label>
      Email
      <input type="email" name="email" required>
    </label>
    <p class="field__error">Please enter a valid email.</p>
  </div>

  <div class="field">
    <label>
      Message
      <textarea name="message" minlength="10" required></textarea>
    </label>
    <p class="field__error">Write at least 10 characters.</p>
  </div>

  <button type="submit">Send</button>
</form>

You can bind field styling to the input inside, purely with CSS.

.field {
  margin-bottom: 1.5rem;
}

.field input,
.field textarea {
  width: 100%;
  padding: .6rem .75rem;
  border-radius: .4rem;
  border: 1px solid #444;
  background: #050505;
  color: #eee;
}

.field__error {
  display: none;
  margin-top: .35rem;
  font-size: .8rem;
  color: #ff6b6b;
}

/* highlight when invalid and touched (using :user-invalid where supported) */
.field:has(input:user-invalid),
.field:has(textarea:user-invalid) {
  color: #ff6b6b;
}

.field:has(input:user-invalid) input,
.field:has(textarea:user-invalid) textarea {
  border-color: #ff6b6b;
  box-shadow: 0 0 0 1px rgba(255, 107, 107, .6);
}

.field:has(input:user-invalid) .field__error,
.field:has(textarea:user-invalid) .field__error {
  display: block;
}

/* success state */
.field:has(input:user-valid),
.field:has(textarea:user-valid) {
  color: #4caf50;
}

.field:has(input:user-valid) input,
.field:has(textarea:user-valid) textarea {
  border-color: #4caf50;
}

No custom event handlers. The browser decides when the input is valid or invalid. CSS uses :has() to move that state to the wrapper and the message.

If you want broader support than :user-invalid, you can fall back to :invalid and accept that some browsers show the state earlier.

Form-level feedback and submit button state

Now zoom out one level. The entire <form> element also exposes validity via :valid and :invalid. Combine that with :has() and your submit button can react.

.form button[type="submit"] {
  padding: .7rem 1.25rem;
  border-radius: .4rem;
  border: none;
  background: #333;
  color: #aaa;
  cursor: not-allowed;
  transition: background .15s ease, color .15s ease, transform .05s;
}

/* any invalid field keeps button in "disabled" style */
.form:has(:invalid) button[type="submit"] {
  background: #333;
  color: #777;
}

/* all fields valid, button goes live */
.form:has(:valid) button[type="submit"] {
  background: #2f80ed;
  color: #fff;
  cursor: pointer;
}

.form:has(:valid) button[type="submit"]:active {
  transform: translateY(1px);
}

If you want to actually disable the button, you still need a tiny bit of JS to toggle the disabled attribute. I usually do not bother for simple forms; the button just looks inactive until the browser considers the form valid.

The nice part is that the logic lives where it belongs. The browser enforces constraints. CSS reads that state. JS, if present at all, sends the request and displays a toast.

4. Layout tweaks based on children, not breakpoints

One more pattern that has crept into my “default toolkit”: adjusting layout based on how many items a container has.

On my baseball drills page, each drill has one or more tags. I wanted single-tag drills to show the tag inline next to the title, and multi-tag drills to move them into a separate row. Doing that in JS felt silly.

<article class="drill">
  <header class="drill__header">
    <h3 class="drill__title">Front toss</h3>
    <div class="drill__tags">
      <span class="tag">Hitting</span>
    </div>
  </header>
</article>

<article class="drill">
  <header class="drill__header">
    <h3 class="drill__title">Relay race</h3>
    <div class="drill__tags">
      <span class="tag">Fielding</span>
      <span class="tag">Conditioning</span>
    </div>
  </header>
</article>

With :has() and the :nth-child() selector you can treat the two cases differently.

.drill__header {
  display: flex;
  gap: .5rem;
  align-items: baseline;
  flex-wrap: wrap;
}

/* one tag only: keep inline */
.drill__tags:has(.tag:nth-child(1):last-child) {
  order: 0;
}

/* more than one tag: push tags to next line */
.drill__tags:has(.tag:nth-child(2)) {
  flex-basis: 100%;
  order: 1;
}

No JavaScript counting nodes. No data attributes. Just “if there is at least a second tag, change layout”. If product decides to add a third or fourth tag, the CSS keeps working.

Reality check: performance and support

I am not going to pretend :has() is free. The browser has to do more work, because selectors now depend on what is inside elements and how that changes.

My take after profiling a few real pages: do not go wild with global *:has(...) selectors. Scope them. Prefer direct children or close relationships.

/* Bad idea */
*:has(.error) { ... }

/* Reasonable */
.form:has(.field__error) { ... }

/* Even better */
.form:has(.field > .field__error) { ... }

Support is good now. Chrome, Edge, Safari, Firefox all ship :has(). Old Safari versions are the main risk. If you work on something critical for a weird enterprise fleet, check caniuse and add progressive enhancement.

Most of my patterns above fail gracefully. You lose a highlight or a layout tweak, not core functionality. That is a good bar to aim for.

How I think about :has() now

I used to reach for JavaScript whenever a parent needed to know about a child, or a sibling needed to react to state. That felt normal. It also created a lot of glue code that did not age well.

Now my filter is simple:

Is the state already visible in the DOM? (attribute, pseudo class, anchor, etc.)
Can that state reasonably drive styling only?

If the answer is yes, I try :has() first. JS comes later, if at all.

Five years ago I was writing tab managers and form validators by hand. I would not go back. :has() is the layout trick that finally lets CSS act on the structure we already have, instead of the utility classes we wish we had planned better.

If you have a component that keeps growing event listeners and state flags, look at the HTML for five minutes. There is a decent chance :has() can take some of that weight off.

The Real Cost Of Self‑Hosting Ghost On DigitalOcean In 2026

Richard Lemon — Fri, 22 May 2026 05:00:00 +0000

The Real Cost Of Self‑Hosting Ghost On DigitalOcean In 2026

I like owning my stack. I also like not waking up to surprise invoices.

So for my own Ghost installs I stopped guessing and ran the actual 2026 numbers for self‑hosting on DigitalOcean, then compared them against Ghost Pro. Below is the messy, honest version. Dollars, not vibes.

Quick context: what I actually run

I am not running some theoretical benchmark blog that gets 3 hits a month.

The setup I am talking about here:

Ghost 5.x, Node 18, Ubuntu 22.04
One production blog, one staging instance on the same box
~25k pageviews / month
Light membership use, no paid newsletter yet
Image-heavy posts, but nothing crazy like a photography portfolio

Traffic is modest but not toy-level. Good enough to stress a $6 droplet and make bandwidth and backups real numbers.

DigitalOcean pricing reality in 2026

DigitalOcean did their usual small bumps. In early 2026, the realistic entry point for a Ghost blog that you do not hate maintaining looks like this.

Droplet: 1 vCPU, 2GB RAM, 50GB SSD — $12 / month
Automatic backups (20% of droplet price) — ~$2.40 / month
Spaces object storage (optional but smart) — $5 / month for 250GB + 1TB transfer
Domain — $10–$15 / year (I will call it $1 / month)
Transactional email (Mailgun, Postmark, SES) — $10 / month tier is the practical floor

Those are retail prices, not affiliate-optimistic numbers. You can shave a few dollars if you are aggressive. You can also blow past them with zero effort.

Baseline self‑host setup: what you actually pay

Let me walk through the stack I recommend and what it costs month to month.

Droplet: how small can you go?

You can run Ghost on a 1GB droplet. I did this for a while. It was fine until it was not.

Anything beyond a few thousand pageviews or one heavy Node task and you suddenly meet your old friend: swapping and 5+ second response times.

So I treat 2GB as the actual minimum in 2026.

DigitalOcean Basic droplet 1 vCPU / 2GB / 50GB SSDPrice: $12 / month

This comfortably runs:

Nginx (reverse proxy)
One Ghost instance, plus a small staging instance
Certbot for SSL

If you expect real traffic spikes, just skip straight to 2 vCPU / 4GB at $24 / month. Anything above that and you are deep into “I should probably just pay Ghost Pro” territory.

Backups: the boring expensive part

There are two backup concerns:

Server-level: DigitalOcean automatic droplet backups
App-level: Ghost content exports, database dumps, theme repo

I pay for DigitalOcean backups because I like sleeping.

Droplet: $12
Automatic backups: 20% of droplet price = $2.40

Total so far: $14.40 / month.

On top of that I push database dumps to a private GitHub repo and occasionally export Ghost JSON manually. That is basically free, just time.

Storage: local disk vs Spaces

Ghost stores uploaded images on disk by default. On a 50GB droplet this is fine for a while. Then you hit 60% disk usage and start cleaning your own mess.

I think DO Spaces is the saner option.

DigitalOcean Spaces: 250GB storage + 1TB bandwidthPrice: $5 / month

Host images and media there. Front Ghost through a CDN endpoint. You keep the droplet disk clean and predictable.

You can skip Spaces initially, but I would not architect around permanent local disk storage unless your blog is text-only.

Bandwidth: the thing you forget until you pay

DigitalOcean gives you bundled outbound traffic with each droplet. For the 2GB plan that is usually around 2–3TB. My Ghost blog with 25k monthly pageviews sits safely under 100GB outbound per month.

So realistically:

Outbound traffic from droplet: effectively included, $0 unless you go viral
Spaces bandwidth: first 1TB included in that $5

If you spike to Hacker News front page levels, DO overage is around $0.01–$0.02 per GB. That is still cheaper than the stress of an AWS bill. Just know that “unlimited” is not a thing here.

Transactional email: the hidden required line item

Ghost needs email for:

Signup and login magic links
Member notifications
Newsletter sending

Your droplet will not deliver email reliably. You need a provider.

The realistic minimal plans in 2026:

Mailgun Foundation: $15 / month for 50k emails
Postmark: $15 / month for 10k emails
AWS SES: cheap, but you trade cost for AWS overhead and deliverability tuning

If you only send a small member newsletter, SES can keep this under $5, but you will pay with your time. I put a line item of $10 / month here as a middle ground.

Domain and DNS

Domain names are boring, but they count.

.com domain: $10–15 / yearAmortised: $1 / month
DNS: Cloudflare free tier is fine for most Ghost blogs

So domain plus DNS is basically $1.

Self‑hosting total: realistic monthly cost

Let me put that together for a single production Ghost blog, plus staging, on DigitalOcean in 2026:

Droplet 2GB: $12.00
Droplet backups: $2.40
Spaces (media + 1TB transfer): $5.00
Transactional email (rough average): $10.00
Domain: $1.00

Total monthly cash cost: $30.40

Call it $30–35 / month for a robust, no-drama Ghost setup for a dev who knows their way around a terminal.

You can get it under $20 if you:

Drop DO backups and roll your own
Skip Spaces and keep media on local disk
Use AWS SES exclusively and stay under their free/cheap thresholds

If you are that person, you probably know your risk tolerance already.

What Ghost Pro actually costs in 2026

Ghost Pro pricing moves, but the structure is steady.

At the time of writing, realistic tiers look roughly like this:

Starter: around $9–11 / month billed yearlyOne site, limited members, shared infrastructure
Creator: around $25–30 / month billed yearlyHigher member limits, better performance
Team / Business: $50+ / month for serious membership and publication use

Prices vary slightly with annual vs monthly billing and how many members you have, but this is close enough for a decision.

Important bit: Ghost Pro includes a bunch of stuff you had separate line items for on DigitalOcean:

Hosting and scaling
Automatic updates and security patches
Backups
Email infrastructure for newsletters
CDN for assets

You still pay for your domain name. Everything else is bundled.

Self‑hosting vs Ghost Pro: the raw comparison

If you strip away features and ideology, the question is simple. For a typical developer blog, is it cheaper to self‑host Ghost or pay Ghost Pro?

Scenario 1: small personal blog

You write a few posts a month. 5k pageviews. Maybe a small free member list.

Ghost Pro Starter: about $9–11 / month (plus $1 for domain)
Self‑host on DO (minimum):

1GB droplet: $6
No DO backups: $0
No Spaces: $0
SES for transactional + small newsletter: $2–3
Domain: $1

Best case self‑host cash cost: $9–10 / month.

So the money is roughly the same. Ghost Pro starts to look very reasonable unless you just like running servers.

Scenario 2: serious blog with modest traffic

This is closer to my setup. 20k–50k pageviews, some members, regular newsletters.

Ghost Pro Creator: about $25–30 / month (plus $1 domain)
Self‑host realistic:

2GB droplet: $12
DO backups: $2.40
Spaces: $5
Mailgun/Postmark/SES combo: $10
Domain: $1

Self‑host cash cost: ~$30–35 / month.

Now self‑hosting is actually more expensive in pure dollars than Ghost Pro Creator, if you configure it like a responsible adult.

Scenario 3: membership business

If you are running a paid publication and making actual money, the pricing conversation changes.

Ghost Pro Business: $50–100+ / month, depending on member count
Self‑host:

2–4GB droplet: $24–48
Backups: $5–10
Spaces: $5–10
Email: $10–30 (volume)
Monitoring / extras: $5–10

You can probably keep this around $50–80 / month if you know what you are doing. So you might save a little compared to the higher Ghost Pro tiers.

But at this point you have a business. Personally, I would not want my subscription revenue running on a stack where I am the single point of failure, unless infrastructure is my hobby.

The cost nobody lists: your time

Money is the easy comparison. Time is ugly to quantify and more important.

Here is my rough time log for a self‑hosted Ghost blog over a year:

Initial setup and config: 2–4 hoursDigitalOcean droplet, Nginx, SSL, Ghost install, mail provider, DNS
Updates and maintenance: 1 hour / monthGhost upgrades, OS updates, certificate renewals, package updates
Random incidents: 2–5 hours / yearDisk nearly full, email DNS issue, unexpected 500s, one bad migration

Total: roughly 14–20 hours / year.

If you value your time at $50 / hour (which is low for many devs), that is $700–1000 / year of time cost. Spread across 12 months and you just silently added $60–80 to your “cheap” $30 / month self‑hosting bill.

On Ghost Pro my time log is basically:

Initial theme setup: 1–2 hours
Zero hours per month on infra

That is the real gap. Ghost Pro makes infrastructure disappear. Self‑hosting gives you toys to play with and things to fix.

Why I still self‑host (sometimes)

Given all that, why bother?

For me there are three reasons:

Full control. I want to tinker with Nginx configs, custom logging, weird A/B testing scripts, or external services at the server level.
Learning value. I like using my own sites as a lab. Self‑hosting is part of that.
Multiple projects. If I stack several side projects on the same DO account, the per‑site cost drops a lot.

If I only had one serious blog, and I wanted it to just work, I would pick Ghost Pro without hesitation. The numbers are simply better once you include time and all the extra services.

When self‑hosting actually makes sense financially

There is one situation where self‑hosting wins hard.

If you already pay for DigitalOcean or another VPS for other projects, and you are comfortable running multiple apps on one machine, then the marginal cost of adding Ghost is tiny.

Example from my actual setup:

One 2 vCPU / 4GB droplet at $24
Running: a small API, a side project dashboard, and my Ghost blog
Backups: ~$5
Spaces: $5 shared across projects

Spread across three projects, the per‑project cost is around $12–15 / month. That beats Ghost Pro easily.

You still pay with time, but now the cost per site is more justifiable.

Practical recommendation

If you are a developer thinking about Ghost, here is my blunt take based on the numbers above.

If you want one blog and no hassle, use Ghost Pro Starter or Creator. Your total cost will land around $10–30 / month and your time cost is effectively zero.
If you want to learn infra or already live in DO/AWS land, then self‑hosting is fun and defensible. Expect to pay $20–35 / month plus a few hours a quarter.
If you are building a paid publication and you are not a backend engineer, I think self‑hosting is a bad business decision. Pay Ghost. Focus on content and growth, not SSL configs.

The myth that self‑hosting Ghost is “basically five bucks” was maybe true for a toy blog on a tiny droplet with no backups in 2018.

In 2026, if you want something stable and production‑grade on DigitalOcean, the real monthly cost looks a lot like Ghost Pro. Sometimes higher. The only real question is whether you would rather spend your budget on servers or on your own time.

My Full Make.com Blueprint For Automating a Sheets OpenAI Ghost Content Pipeline

Richard Lemon — Thu, 21 May 2026 07:00:00 +0000

Why I stopped hand-assembling content

I got tired of copy pasting my way through content.

Idea in Notion. Outline in Docs. Draft in ChatGPT. Formatting in Ghost. Images in Figma. Every post felt like a manual QA job instead of building something once and letting it run.

So I pushed the whole thing into Make.com.

Now a single row in Google Sheets turns into a drafted or published Ghost post. Titles, meta fields, tags, even a first-pass excerpt. All wired together with OpenAI in the middle.

This is the exact blueprint. Not theory. This is the scenario that runs my real content pipeline.

The high-level architecture

The stack is simple on purpose:

Google Sheets as the content control panel.
Make.com to orchestrate everything.
OpenAI to generate and clean up text.
Ghost (self-hosted) as the CMS.

One sheet row = one post. Status and flags in that row decide if Make should ignore it, draft it, or publish it.

I keep the Make scenario focused. One job. Turn structured data in Sheets into structured content in Ghost.

The Google Sheet schema

Here is the actual column setup from my sheet. No fluff.

A: id – internal ID, just an incrementing number.
B: status – idea, ready, generated, published.
C: title – human-written title seed.
D: slug – usually auto-generated in Make if empty.
E: brief – 2–4 bullet outline or a short paragraph.
F: target_keywords – comma separated SEO terms.
G: tone – e.g. direct, informal, first-person.
H: word_count_goal – rough length like 1200.
I: tags – comma separated Ghost tags.
J: generated_html – where I store the body HTML from OpenAI.
K: meta_title
L: meta_description
M: excerpt
N: publish_flag – draft or publish.
O: ghost_post_id – for updates.

I do not trust LLMs to guess intent. So I give them a tight brief and flags.

The Make.com scenario: the main flow

I run a single Make scenario that does all of this:

Polls Google Sheets for new ready rows.
Generates content and meta fields via OpenAI.
Writes the generated content back into the sheet.
Creates or updates a Ghost post.
Updates status and IDs.

I will walk through every module and what it actually does. No hand waving.

Module 1: Google Sheets “Search Rows”

Trigger: I run this scenario on a schedule. Every 15 minutes works for my pace.

First module is a Google Sheets > Search Rows module.

Spreadsheet: my Content Pipeline sheet.
Sheet: Posts.
Filter: status = ready.
Limit: I cap at 3 rows per run. I prefer small batches.

This returns an array of rows that are ready to be turned into drafts.

Each row carries all the columns I mentioned earlier.

Module 2: Iterator

I drop an Iterator right after Search Rows.

No magic here. It splits the list of rows into separate bundles so I can process each post independently.

The iterator just takes the array of rows from Sheets and iterates over values[].

Module 3: Data cleanup with Text & Tools

I do some pre-processing before I hit OpenAI.

Trim whitespace from things like title and slug.
Normalize commas in tags and target_keywords.
Generate a fallback slug if the cell is empty.

In practice this is a couple of Tools > Text aggregator / Text parser modules and one Set variable module.

Example: to generate the slug I use a simple Make formula in a Set variable module:

lowercase(
  replace(
    replace(
      replace(
        stripDiacritics(title);
        " "; "-"
      );
      "--"; "-"
    );
    "[^a-z0-9-]"; ""
  )
)

If the slug column in Sheets is already filled, I keep it. Otherwise this kicks in.

Module 4: OpenAI “Create a chat completion” for the article body

Now the fun part.

I use the OpenAI > Create a chat completion module. Currently on gpt-4.1 but I keep this modular so I can swap models.

I feed it a structured prompt that merges sheet data and my own style instructions. Here is the actual system + user content simplified to fit here.

System message (in the module):

You are Richard Lemon, a creative web experience developer.
Write opinionated first-person blog posts.
No em dashes. Short paragraphs (max 2-3 lines).
Direct voice, practical, specific.
Use HTML with <h2>, <p>, <ul>, <li>, <pre>.
Do not add <html> or <body> tags.

User message template:

Write a blog post with the following constraints:

Title: {{title}}
Brief: {{brief}}
Target keywords: {{target_keywords}}
Tone: {{tone}}
Word count target: {{word_count_goal}}

Rules:
- Write in first person as if I actually did the thing.
- Be concrete and technical where useful.
- Use only HTML tags for structure (<h2>, <p>, <ul>, <li>, <pre>, <code>).
- No introduction fluff, start with context or action.
- No conclusion heading.

Return only the HTML body.

The output is pure HTML. I do not want Markdown here because Ghost accepts HTML just fine and I like having precise control.

Module 5: OpenAI for SEO meta + excerpt

I split generation into two calls instead of asking one model response to do everything.

Second OpenAI > Create a chat completion module takes the title, target keywords, and a short summary of the generated HTML and creates meta fields plus an excerpt.

System message:

You create SEO metadata for blog posts.
Always stay under the specified character limits.
Return JSON only.

User message:

Post title: {{title}}
Target keywords: {{target_keywords}}
Body HTML (truncated): {{body_preview}}

Generate:
- meta_title: max 60 chars, must include at least one keyword.
- meta_description: 120-155 chars, natural and specific.
- excerpt: 1-2 sentences, no clickbait.

Return JSON like this:
{
  "meta_title": "...",
  "meta_description": "...",
  "excerpt": "..."
}

I then parse that JSON with a JSON > Parse JSON module.

Could I compress this into one call? Sure. I tried that. The meta fields got worse and harder to constrain. So I split it.

Module 6: Write everything back to Google Sheets

At this point I have:

Cleaned title and slug.
Generated HTML body.
Meta title, description, and excerpt.

Before touching Ghost I push this back into the sheet.

I use Google Sheets > Update a Row with:

Column J → generated_html from OpenAI.
Column K → meta_title from JSON.
Column L → meta_description.
Column M → excerpt.
Column D → final slug.
Column B → set to generated.

Why write back before publishing?

Because I like a manual checkpoint. I can read the generated HTML in Sheets, tweak the brief or title, flip status back to ready if I want a regen.

This effectively makes Sheets my content staging area while Ghost stays clean.

Module 7: Filter on publish_flag

Not every generated post should go live.

I add a filter between the Sheets update and the Ghost modules:

publish_flag = "draft" OR publish_flag = "publish"

If publish_flag is empty or something else, the scenario stops for that row. It will still update the generated fields, but nothing touches Ghost.

When I want a post to move to Ghost I set publish_flag to draft or publish in the sheet.

Module 8: Router for create vs update in Ghost

I use Ghost both for new posts and edits triggered from Sheets.

So I drop a Router with two branches:

Branch 1: Create when ghost_post_id is empty.
Branch 2: Update when ghost_post_id is not empty.

This lets me tweak a title or tags in Sheets, set publish_flag again, and push an update to the existing Ghost post.

Module 9: Ghost “Create a post” (branch 1)

On the create branch I use the Ghost > Create a post module.

Here is how I map things:

Title → Sheet title.
Slug → final slug from Module 3.
HTML → generated_html.
Excerpt → AI generated excerpt.
Meta title → meta_title.
Meta description → meta_description.
Tags → split tags column on comma, trim each value.

For status I map directly from publish_flag:

draft → Ghost draft.
publish → Ghost published.

Ghost returns a post object with an id. I capture that and write it back to the sheet.

Module 10: Google Sheets “Update a Row” with ghost_post_id

Immediately after the create call I drop another Google Sheets > Update a Row module.

It takes the id from Ghost and stores it in column O: ghost_post_id. I also set:

status = published if publish_flag was publish.
status = generated if publish_flag was draft.

This keeps my spreadsheet the single source of truth. I can filter ideas, generated drafts, and published content without logging into Ghost.

Module 11: Ghost “Update a post” (branch 2)

On the update branch, I use Ghost > Update a post with the stored ghost_post_id.

I do not blindly overwrite everything. Here is my mapping logic:

Always update HTML from generated_html.
Update title and slug only if the sheet values changed.
Update meta fields if they exist in Sheets. Otherwise keep Ghost values.
Tags are rebuilt from the tags column every time.

In Make that means I use if expressions in the field mapping. For example:

if(
  empty(sheet_meta_title);
  ghost.meta_title;
  sheet_meta_title
)

I apply a similar pattern for slug and description.

Module 12: Error handling and logging

I do not like silent failures.

So I added a simple error path using Make’s built-in error handlers:

If Ghost or OpenAI throws an error, I catch it in a separate route.
Then I write the error message into a errors column in Sheets.
I also ping myself with a Gmail > Send an email module when something breaks.

Nothing fancy. Enough to see when the pipeline has issues without watching Make all day.

Why I structured it this way

I tried a few alternative versions before landing on this flow.

What I did not like:

Single gigantic OpenAI prompt that tried to output HTML, meta, title variants, tag suggestions, everything. It was brittle.
Direct Sheets to Ghost without writing generated content back first. Harder to see what the model produced.
No publish_flag, so everything went straight to draft in Ghost. That got noisy fast.

What works better for me now:

Sheets is the control tower. All fields visible. Easy to override.
Make is the transport layer. No business logic hidden in Ghost.
OpenAI is a dumb transformer that takes structured inputs and outputs structured HTML and metadata.

The end result is that I spend time on outlines and ideas, not formatting posts or fighting CMS UI.

How this feels in daily use

Here is my actual workflow on a random Tuesday.

I open the Posts sheet and dump three new ideas as rows with rough titles and briefs.
I set status = ready and leave publish_flag empty.
Make picks them up, runs OpenAI, writes back generated HTML and meta, sets status = generated.
I skim the HTML in Sheets. If a post feels off, I tweak the brief or title, flip status back to ready and let it regenerate.
Once I like a post, I set publish_flag = draft or publish.
Next run, Make pushes it into Ghost accordingly.

I still edit inside Ghost sometimes. Especially for code-heavy posts or things where I want to insert images manually.

But 80 percent of the grunt work is automated. Which is the point.

If you want to copy this

If you are already using Make, you can rebuild this in an afternoon.

The three non-negotiables in my experience:

Use Sheets as a real schema, not a random dumping ground.
Keep OpenAI prompts tight and specific. One job per call.
Always round trip data back into Sheets so you can see what the system did.

From there you can layer on extras. Social post generation, image generation, cross-posting to other platforms. I keep those in separate scenarios so this core pipeline stays boring and reliable.

That is the full blueprint I run right now. It will probably change again in a month. But the core idea stays the same. Treat your content as structured data, not as a CMS typing session.

My Minimalist iPhone + Lightroom Photo Workflow (Like Reusable Components)

Richard Lemon — Wed, 20 May 2026 06:42:19 +0000

Why I treat photos like UI components

I build web experiences for a living, so my brain is wired around components. Small pieces. Clear inputs. Predictable outputs.

When I started taking photography more seriously, I fell into the same trap most devs do. Gear research. Camera reviews. Lens rabbit holes. Editing suite comparison charts with way too many checkmarks.

Meanwhile, my camera roll was a mess and my Instagram was dead.

So I did what I always do when a hobby starts to feel like work. I stripped the whole thing down until it felt more like React props than creative suffering.

Right now my photography workflow is: iPhone camera + Lightroom on my phone. That is it. No DSLR body. No plugin zoo. No 45-minute “mood crafting” sessions per photo.

Everything is built around a component mindset. Reusable pieces. Minimal configuration. Fast feedback. Just enough control to make it mine.

The constraint: photography as a side-quest, not a second job

I have a few non‑negotiables for creative hobbies.

I can start in under 10 seconds.
I can ship in under 5 minutes.
The results look consistent enough to feel intentional.

If any of those break, my interest drops. That is true for side projects, for training plans, and for photography.

I also know myself. If I carry a big camera bag, I will start thinking in “photo session mode” instead of “notice stuff and shoot” mode. That kills the fun for me.

So I made a rule: if it does not fit in my pocket, it does not exist in my workflow.

That leaves me with the device I already use to check stats, answer clients, and record baseball drills. The iPhone.

The capture layer: keeping the raw input simple

In front‑end, if the data that comes into your components is garbage, no clever UI will save it. Same with photos. If the input is bad, Lightroom is just a colorful coping mechanism.

I do not shoot RAW on my phone.

Yes, RAW is technically better. Yes, there is more dynamic range. I have shot RAW. I can tell the difference. I also know it bloats storage and slows down every step that comes after.

For a mobile, Instagram‑first flow, I would rather optimize the system than chase theoretical quality. So I stick to HEIC or JPEG from the stock camera app.

My “componentized” capture settings look like this:

Photo mode only. No Pro, no filters, no Portrait for Instagram work. Portrait mode looks nice on the phone then falls apart in editing with weird edges and fake blur.
Grid enabled. I treat the grid like a layout system. Rule of thirds, leading lines, horizon sanity check. Same as a CSS grid overlay for a new layout.
Exposure control. I tap to focus and slide down slightly to underexpose. Phones love bright, flat images. I prefer a bit of headroom and mood.
Lens discipline. I mostly stick to the main wide lens. The ultra‑wide is a special‑purpose component for architecture or big interiors. Digital zoom is basically a bug, so I “disable” it mentally.

I also have a couple of mental capture presets. Not camera presets. Just tiny rules I repeat.

“Find the clean background”. Before I raise the phone, I quickly scan behind the subject. I move one or two steps to clean up lines and remove clutter. This is the same thinking as simplifying a DOM tree before styling.
“Commit to one light direction”. I walk around the subject until I can clearly see where the light is coming from. I shoot primarily from that side. This keeps shadows intentional instead of random.

That is it. No half‑hearted HDR toggles. No live filters. Clean input.

Lightroom as a component library, not a blank canvas

Lightroom can be a black hole. Infinite sliders. Panels inside panels. If you treat it like a design tool, you will happily tweak a single photo for 30 minutes. Then you will burn out and stop posting.

I treat Lightroom mobile like a component library.

Components have props and sensible defaults. You are not redesigning a button every time. You pick a variant. You override a couple of values. You ship.

My Lightroom setup uses the same idea.

Building my “preset components” from actual use

I did not download a random preset pack from some influencer. I am not against presets, I just do not like trusting a black box that was tuned for Bali sunsets when I am shooting Dutch winter light.

Instead, I shot for a week in my normal routine. Commute. Lunch walks. Baseball field. Home. Every time I edited a photo in Lightroom, I forced myself to notice patterns.

Typical slider changes for me:

Exposure slightly down, contrast slightly up.
Highlights down, shadows slightly up.
Whites up a bit, blacks down a bit.
Vibrance up, saturation almost untouched.
A small S‑curve in the tone curve panel.

I also realized I almost always desaturate yellow and raise orange luminance, especially for skin. Greens get tamed a bit. Sky blues get a tiny saturation bump.

That observation process is boring but important. It is like scanning your commits over a week and realizing you always add the same utility classes. That is your implicit design system trying to exist.

After a few days I created my first real preset. I applied my “default” edit to one photo, then saved those settings as a preset in Lightroom mobile. I named it something aggressively uncreative like RL_Base_Daylight.

That preset is now my default component. It handles 70 percent of my shots.

Preset variants, like component variants

One preset is not enough, but ten are too many. I treat presets like button variants. A few solid ones. Clear scenarios. No overlap.

Right now I use four Lightroom presets regularly:

Base Daylight. For most outdoor daytime shots. Neutral, slightly contrasty, moderate saturation, restrained greens.
Soft Overcast. Slightly warmer temp, reduced clarity, gentler contrast. Built for grey Dutch skies that kill depth.
Indoor Warm. For home or coffee shops. Temp pushed a bit cooler to fight orange LEDs, plus more noise reduction and less clarity.
Field Night. For baseball training under floodlights. More aggressive noise control, cooler white balance, lifted shadows to pull detail out of dark uniforms.

Each preset bakes in everything except crop and local adjustments. White balance is “soft opinionated” so I still tweak it per shot. Same idea as default props that can be overridden.

This is the core of the workflow. Pick a preset like you pick a component variant. Then only touch the necessary knobs.

The micro‑flow: editing a single photo

Here is the actual sequence I use for a photo I plan to post. No theory. Just the real steps.

Pick a favorite. In the Photos app I quickly star or favorite 3–5 candidates from a moment. I only import those into Lightroom. I do not invite my entire camera roll to the party.
Import into Lightroom mobile. One tap from the share sheet. I keep albums very loose: Daily, Field, Travel. Enough to find things, not enough to become a second job.
Apply a preset. I start with Base Daylight or one of the variants. No raw sliders yet. Just a single preset tap.
Fix crop first. I correct horizon, straighten buildings, and tighten the frame. Cropping first is like fixing container width before adjusting typography.
Tune light. I nudge exposure, then check shadows and highlights. If I spend more than 30 seconds here, I restart from the preset and force a smaller adjustment.
Tune color. Small tweaks to temperature and tint. Maybe HSL on orange / yellow if skin tones look off. I try to never open the full HSL panel unless something clearly bothers me.
Detail and effects. A bit of sharpening, lens correction if needed, and sometimes a tiny vignette. No artificial grain. I think fake grain is overrated on phone photos.
Export to camera roll. Highest resolution JPEG back to Photos. Then straight to Instagram.

That whole cycle usually takes under two minutes. If it does not, the photo is not worth it for Instagram. I archive it and move on.

Batching photos like UI states

One nice thing about Lightroom presets is that they behave like the default state for a group of similar shots. I try to think of “sets” of images the same way I think about button states.

Say I shot 10 photos at the field on a cloudy evening. Those are clearly one group. Same light, same environment, similar subject.

My mini‑batch flow:

Import all 10 into a Field album.
Pick my favorite and edit it fully, using the Field Night preset as a base.
Copy the settings in Lightroom and paste them to the other 9.
Only adjust exposure and crop on each of the others.

Now the entire set has a consistent look and took maybe 10–15 minutes. I do not love batch editing as a creative act, but as a system design problem it feels honest and efficient.

Constraints that keep it fun

A workflow is only good if you actually use it repeatedly. I have a few constraints that keep this photo thing in the hobby zone instead of the productivity zone.

No laptop editing. If I cannot finish the edit on my phone, I do not post it. I spend all day in front of a bigger screen already.
No “someday” folders. If an image does not get edited the same day or the next morning, it goes to the archive with zero guilt. No backlog to manage.
Instagram only. I am not trying to print gallery pieces. My target medium is a small glowing rectangle people scroll past during coffee. That simplifies choices a lot.
One crop rule. I edit for a single aspect ratio per session. Usually 4:5 vertical for Instagram. I do not make web, story, and print crops for the same photo.

Those sound strict, but they are just guardrails. They stop me from turning a relaxing walk into a production pipeline.

Why this feels like front‑end work (in a good way)

The fun part for me is how much this resembles front‑end thinking once you strip away all the drama around “art”.

Inputs. Light, subject, environment. Same as data and API shape.
Components. Presets and small editing patterns. Like buttons, cards, text styles.
System. The capture → edit → export flow. Like your build tooling and deployment script.
Constraints. Pocketable gear, Instagram output, phone‑only edits. Same as targeting a specific device range or performance budget.

Once I started to see it that way, it stopped being overwhelming. I do not need the “best” lens any more than I need the “best” JavaScript framework for a static product page.

I need a small, opinionated stack that I actually use on a Tuesday when I am tired and just want to post a photo of late‑night batting practice.

What I would change next

This workflow is not sacred. I treat it like a codebase. Small pull requests. No rewrites.

A few things I am experimenting with:

One black and white preset. For rare cases where color distracts. I want a single, bold look, not 8 moody variations.
A “story” preset. Slightly higher contrast and clarity to survive Instagram compression on stories.
Shooting a tiny bit more RAW. Very selectively. Maybe one RAW frame per interesting scene when I know I might want a print later.

If any of these start slowing down the main flow, they get reverted. Same rules as any healthy component library. If a new component adds more cognitive load than value, it goes.

Keeping a hobby frictionless

I like building complex things at work. I like keeping my hobbies aggressively simple.

iPhone camera. Lightroom mobile. A handful of presets I actually understand. A capture habit that fits around coaching, building products, and generally living a normal day.

If photography currently feels heavy or guilt‑shaped for you, try cutting it until it feels closer to shipping a small UI component. Limited props. Clear output. Low drama.

It is supposed to be fun.