DEV Community: RAXXO Studios

Accessible Color Contrast Without Killing the Brand

RAXXO Studios — Fri, 10 Jul 2026 00:05:32 +0000

I keep a dark UI with a bright accent WCAG-AA readable at 4.5:1
Shift lightness not hue to fix failing text
Two documented exceptions: decorative accents and large display text
Free tools I use to check every color pair before ship

My store runs a near-black background with a single bright accent. It looked sharp and failed accessibility on half the text. Here is how I fixed the contrast without touching the brand color everyone recognizes.

Why A Dark UI Punishes Bright Accents

A dark interface feels premium. It also hides a math problem. Contrast is a ratio between two luminance values, and bright saturated colors sit lower on the luminance scale than people expect. My accent read as loud and glowing on screen, so my eyes told me it was fine. The numbers said otherwise.

WCAG-AA asks for 4.5:1 between text and its background for normal text, and 3:1 for large text (roughly 24px regular or 19px bold). My accent against the dark background measured 2.8:1. That is a fail. It passed the vibe check and failed the ratio, which is the exact trap that dark UIs set.

The reason is that saturation tricks you. A vivid orange or a hot green looks energetic, but energy is not luminance. When I ran the accent through a contrast checker, the color that felt like it was screaming off the screen was quietly under the line for anyone with reduced vision, on a cheap laptop panel, or reading outside in daylight.

I do not treat accessibility as a legal chore. It is a quality signal. If a customer squints at my product name, they leave. On mobile in bright sun the failing pairs became almost invisible, and mobile is most of my traffic. So the cost of ignoring contrast is not abstract, it is people who cannot read the button that leads to checkout.

The other thing dark UIs punish is the assumption that white text fixes everything. Pure white on near-black often overshoots, causing halation where the text seems to buzz for tired eyes. So I ended up with two problems on the same screen: an accent too weak and body text too harsh. Both are contrast issues, just from opposite directions.

Before I changed a single value I wrote down my three background shades and every place the accent touched text. That list was 14 pairs. Nine passed, five failed. Knowing the exact failing pairs meant I could fix five specific things instead of redesigning the palette in a panic. If you want the deeper context on setting up a working environment for this kind of audit, see Claude Blueprint which walks through my whole build discipline.

How I Actually Check Contrast

I check every color pair with numbers, not eyeballs. My workflow has three layers and takes about ten minutes for a full palette.

Layer one is the browser. Chrome DevTools shows a contrast ratio right in the color picker when you inspect any text element. It even draws a line on the color field showing which shades would pass. I open the inspector, click a heading, and read the ratio. If it says 4.5 or above with a checkmark, that pair is done. This catches most problems in the actual rendered page, which matters because computed colors after opacity and blending are not the same as the hex in your CSS.

Layer two is a standalone checker for the raw values. WebAIM's contrast checker takes two hex codes and returns the ratio plus pass or fail for AA and AAA at both text sizes. I paste my accent and my background, and it tells me 2.8:1, fail. No guessing. I keep a small text file with every approved pair and its ratio so I never re-litigate a color I already cleared.

Layer three is a plain-language sanity pass. I open the page at 50 percent brightness on my phone. Screens lie in a bright studio. Real customers scroll in bed, on trains, in cafes with glare. If body text is uncomfortable at half brightness, the number was technically fine but the experience was not.

The mistake I made early was checking colors in isolation. A color has no contrast by itself. It only has contrast against what sits behind it. So my accent might pass on the darkest background and fail on the card background two shades lighter. Every surface layer needs its own check. My dark UI has three background tones, which means one accent needs three separate ratios.

I automate the boring part. A short script reads my CSS variables and prints the ratio for each declared pair, flagging anything under 4.5:1 in red. That turns a 30 minute manual audit into a five second run every time I touch the stylesheet. I covered the automation habit in more depth at Claude Blueprint, because the pattern of scripting the tedious checks applies to far more than color.

Shift Lightness, Not Hue

The instinct when a color fails is to change the color. Do not. Change the lightness.

My brand accent is the recognizable thing. Shift the hue and it is a different brand. So when a pair failed, I kept the hue and saturation locked and only moved the lightness value in HSL. This is why I work in HSL and not hex for the source of truth. HSL lets me nudge one number and watch the ratio climb while the color stays unmistakably mine.

Here is the concrete move. My accent failed as text at 2.8:1. I lifted the lightness in steps of five percent and rechecked. At plus 15 percent lightness the ratio hit 4.6:1, a pass, and the color still looked like the same accent, just slightly brighter. Side by side, nobody could name what changed. The ratio jumped from fail to pass with a hue that stayed identical.

I now keep two versions of the accent. The original brand accent lives on large surfaces, buttons, and decorative shapes where it does not need to carry small text. A lightness-lifted variant handles any accent-colored text under 24px. Same hue, two lightness stops apart. The brand reads as one color because the difference is subtle, but the text passes.

For the body text problem, I went the other direction. Pure white was too hot on near-black, so I pulled the text lightness down from 100 to about 90 percent. That softened the halation and still cleared AAA at 15:1. Lowering lightness on the light element and raising it on the dark element are the same tool pointed at different ends.

This approach scales. When I built a second theme with a different accent, I did the same dance: lock hue and saturation, move lightness until the checker turns green, document both stops. No hue drift, no brand drift.

One more trick for stubborn cases. If lightness alone cannot get there without the color looking washed, I add a thin outline or a subtle darker shadow behind accent text. A one pixel dark stroke buys contrast against a busy background without touching the fill color at all. I use it sparingly because overused strokes look cheap, but on a hero image where the background varies pixel to pixel it saves the readability without repainting anything.

The Two Exceptions I Allow

I hold the 4.5:1 line almost everywhere. There are exactly two places I allow a documented exception, and documented is the key word. An exception you wrote down is a decision. An undocumented one is a bug you will forget about.

Exception one is purely decorative elements that carry no information. A glowing accent line under a section, a faint accent grid in the background, a thin divider. WCAG itself exempts decorative graphics and text that is part of an inactive element or pure decoration. If losing that element loses nothing a customer needs to read or act on, it does not need 4.5:1. My background accent grid sits at maybe 1.5:1 on purpose. It is texture, not text. I note it in my palette file as "decorative, exempt, intentional low contrast" so future me does not flag it and fix a non-problem.

Exception two is large display text at 3:1. The AA spec already allows 3:1 for large text, so this is not really breaking the rule, but I treat it as an exception because I have to be honest about the size. My big hero headline uses the original brand accent, which lands around 3.2:1. That passes for large text and fails for normal text. So the rule is: that exact accent shade is allowed only at display sizes, and my CSS enforces it by only applying that color to a heading class that is always 32px or larger. The moment someone tries to use it on a paragraph, it fails the audit script and I catch it.

What I never allow: body copy under 4.5:1, button labels under 4.5:1, form field text, error messages, or anything a customer needs to complete a task. Those are non-negotiable because they are the difference between a usable store and a pretty one.

The documentation habit matters more than the exceptions themselves. My palette file has a column called "exception reason." Most rows are blank. Two rows have a sentence. When I revisit the design in six months I do not wonder whether that low-contrast grid was a mistake. I read the reason and move on. If you schedule design posts and want them to go out consistently, I run mine through Buffer so the publish cadence never depends on me being at the desk.

Bottom Line

Accessible contrast and a strong brand are not enemies. They only feel that way because saturation fools your eyes into thinking a bright color is a readable color. The fix is boring and reliable: measure every pair with a real ratio, keep the hue locked, and move lightness until the number clears 4.5:1. My accent still looks like my accent. It just has a slightly brighter twin for small text, and pure white got dialed back to 90 percent so it stops buzzing.

Write your exceptions down. The two I allow, decorative elements and large display text at 3:1, are only defensible because they live in a file with a reason next to them. Everything else holds the line.

If you want the fuller system behind how I document decisions like this and script the checks so they run themselves, Claude Blueprint is the place I keep the whole approach. Start with your five worst-failing pairs. That is usually the entire problem.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Feature Flags Without a Vendor: The Minimal Setup I Ship

RAXXO Studios — Thu, 09 Jul 2026 00:11:37 +0000

Boolean flags in env vars cover 80% of what vendors sell
Gradual rollout by hashing user IDs into 100 buckets
Instant rollback in under 60 seconds with no deploy
Full kill-switch table lives in one edge config file

I ship products alone. When I priced a feature flag vendor last year, the smallest paid tier wanted 40 EUR a month for things I already had access to for free. So I built my own setup in an afternoon. It has run three products through dozens of releases without a single incident I could blame on it.

Here is the whole thing: environment variables, one edge config file, and a small hash function. No SDK, no dashboard, no vendor.

What a Flag Vendor Actually Sells You

Before you copy anyone's setup, it helps to name what you are actually paying for. Feature flag vendors bundle five things into one bill. First, a place to store on/off switches. Second, a way to flip them without redeploying code. Third, targeting rules (show this to 10% of users, or only users in Germany). Fourth, an audit log of who changed what. Fifth, a fancy dashboard.

For a team of thirty engineers pushing forty times a day, that bundle is worth real money. For a solo product, most of it is overhead you will never touch. I have never once needed to know "who changed the flag" because the answer is always me.

So I reduced the list to what I genuinely use. I need switches. I need to flip them without a deploy. I need to roll a feature out to a slice of users and widen it slowly. That is three things, not five. And all three exist inside tools I already pay for as part of hosting.

The trap is thinking flags are complicated because vendors have made a whole category out of them. A boolean is not complicated. A boolean stored somewhere your app can read at request time is not complicated either. The only genuinely tricky part is gradual rollout, and even that is one function.

I keep a running rule for solo tooling: if a service charges monthly for something I can express in under 50 lines of code, I write the 50 lines. Flags cleared that bar easily. The 40 EUR a month I did not spend is 480 EUR a year, and the setup has needed zero maintenance since I shipped it.

If you want the wider thinking on building instead of buying, Claude Blueprint walks through how I decide what to keep in-house versus outsource. Flags land firmly in the keep column.

Boolean Flags Live in Env Vars

The simplest flags are the ones you never plan to change while the app is running. Is the new checkout live? Is the beta search bar visible? These are settings, and settings belong in environment variables.

I name them with a strict prefix so they are easy to scan. Every flag starts with FLAG_. So I have FLAG_NEW_CHECKOUT, FLAG_BETA_SEARCH, FLAG_AI_SUGGESTIONS. The value is the string "on" or "off". I read them through one helper that treats anything except "on" as off, so a typo fails safe instead of accidentally enabling something.


function flag(name) {
  return process.env[`FLAG_${name}`] === "on";
}

That is the entire read path for static flags. In the code I write if (flag("NEW_CHECKOUT")) and move on. There is no SDK to initialize, no network call, no latency. The value is baked in at boot.

The catch with env vars is that changing one usually means a redeploy. On most hosts, editing an environment variable triggers a rebuild that takes two to five minutes. That is fine for flags I flip a few times during a launch. It is not fine for an emergency where a feature is actively breaking and I need it off in seconds. That case needs the edge config, which I cover next.

I keep a plain text list of every active flag at the top of one file, with a one-line note on what each controls and when I can delete it. Flags rot fast. A flag that has been "on" for everyone for two months is not a flag anymore, it is dead code wrapped in a condition. Every few weeks I delete the ones that graduated and clean up the branches. This single habit has kept my codebase from turning into a maze of nested toggles, which is the real long-term cost people forget when they adopt flags at all.

For the deployment side of this, I run everything on Shopify hosting for the storefront pieces and a small edge platform for the app logic, so my env vars sit in two clearly separated places.

Instant Rollback With an Edge Config Table

The env var approach fails the one test that matters most: the 3am kill switch. When something is on fire, waiting five minutes for a rebuild is unacceptable. So the flags I might need to flip fast do not live in env vars at all. They live in an edge config store.

Most edge platforms give you a tiny key-value store that reads in single-digit milliseconds at the edge and updates in seconds with no deploy. Vercel calls it Edge Config. Cloudflare has KV. The idea is the same everywhere: a small JSON blob your app reads on each request without a rebuild.

My kill-switch table is one JSON object:


{
  "new_checkout": { "enabled": true, "rollout": 100 },
  "ai_suggestions": { "enabled": true, "rollout": 25 },
  "beta_search": { "enabled": false, "rollout": 0 }
}

To kill a feature I set enabled to false and save. The change is live at the edge in under 60 seconds. No deploy, no rebuild, no waiting. I have used this exactly twice in production, and both times the difference between 60 seconds and five minutes was the difference between a shrug and a bad morning.

The read helper checks the edge table first and treats a missing key as disabled, so again the failure mode is safe. If the edge store is unreachable for any reason, every gated feature turns off rather than throwing errors at users. Off is almost always safer than broken.

I keep the whole table in version control as a committed default too. That way I always have a record of the intended state, and if I ever migrate platforms I can seed the new store from the file. This gives me the audit trail a vendor would sell me, without paying for it. The git history shows every change, timestamped, with a commit message I can make as descriptive as I want.

One rule I follow: the edge table only holds flags I might flip in an emergency. Everything else stays in env vars. Mixing them makes the table cluttered and slow to reason about at 3am, which is the exact moment I need it to be obvious.

Gradual Rollout With a Hash Function

The last piece vendors charge for is percentage rollout. Show a feature to 10% of users, watch the error logs, then widen to 50%, then 100%. This sounds like it needs a targeting engine. It needs one function.

The problem to solve is stickiness. If I roll out to 10% by flipping a coin on each request, a user sees the feature on one page and gone on the next. That is worse than not shipping. So the assignment has to be deterministic per user: the same user always lands in the same bucket.

I hash the user ID into a number from 0 to 99, then compare it against the rollout percentage.


function inRollout(userId, percent) {
  let h = 0;
  for (const c of userId) h = (h * 31 + c.charCodeAt(0)) % 100;
  return h < percent;
}

A user hashed to bucket 7 is inside any rollout of 8% or higher, and always will be, because the hash is stable. When I widen from 10% to 25%, the original 10% keep the feature and a fresh 15% join them. Nobody loses access mid-rollout. That property, stable assignment as you widen, is the whole game, and it is four lines.

I combine this with the edge table. A flag is live for a user when enabled is true AND inRollout(userId, rollout) returns true. So I can ship at rollout: 5, watch logs for an hour, bump to 25, then 50, then 100, all by editing one number in the edge store. No deploy at any step.

For features I want to test more precisely, I log which bucket each user landed in alongside the metric I care about. That gives me a rough before/after without any analytics vendor. I ran my AI suggestions feature this way: 5% for a day, checked that error counts stayed flat and engagement held, then widened over four days to everyone. If the numbers had gone the wrong way I would have set rollout back to 0 in seconds.

For the AI features themselves I lean on tools like ElevenLabs for voice and Magnific for image work, and gating each new integration behind a slow rollout has saved me from shipping a broken third-party dependency to my whole userbase more than once.

Bottom Line

Feature flags are three small pieces, not a subscription. Boolean switches live in env vars for anything I change slowly. A tiny JSON table in edge config handles the emergency kill switch with rollback in under 60 seconds and no deploy. A four-line hash function gives me sticky percentage rollout that widens without ever revoking access. That covers what I used to price a vendor for at 40 EUR a month.

The real cost of flags is never the storage. It is the dead flags that pile up and turn your code into a maze. So the discipline that matters is deletion: retire every flag the moment it has graduated to permanent. I do a cleanup pass every few weeks and it keeps the whole thing honest.

If you are building solo and weighing what to keep in-house, this is a clear win. Start with the env var helper, add the edge table only for the flags you might panic-flip, and reach for the hash function when you want a slow rollout. For more on how I decide build versus buy across a whole product, Claude Blueprint has the full framework.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

The CSS color-mix Patterns I Use Across Every RAXXO Theme

RAXXO Studios — Tue, 07 Jul 2026 23:58:44 +0000

One brand variable feeds hover, disabled, surface, and text colors
5 color-mix patterns replaced a 40-line hand-curated palette
Accessible text picks itself from the background with color-mix
Deployed across raxxo.shop and 4 micro-sites with zero per-site tweaks

I deleted 40 lines of hand-picked hex codes from my theme and replaced them with one variable and five functions. Every hover state, disabled button, surface tint, and text color now derives from a single --brand value. Change one line and all four micro-sites plus raxxo.shop recolor in a way that stays readable.

Why One Brand Variable Beats a Hand-Curated Palette

I used to keep a palette file. Brand color, then a lighter tint, then a darker shade, then a hover shade, then a disabled gray, then a surface tint, then a border. Seven values per accent color, all chosen by eye in a color picker, all copied into every theme.

That approach broke every time I launched a new micro-site. I run five properties now, each with its own accent. Blue for one, warm orange for another, a muted green for a third. Every launch meant re-picking seven shades and hoping they held contrast against my dark surfaces. Some did not. I shipped a disabled button once that was completely invisible on the card background because I picked the gray against white and never tested it on the actual surface.

The fix was color-mix(). It takes two colors and a percentage and blends them in a chosen color space. That single function does everything my seven hand-picked shades did, except it computes them from one root value at runtime. I set --brand: #4f7cff once. Everything else mixes off it.

Here is the mental model. A hover state is the brand mixed with a little black. A disabled state is the brand mixed with a lot of gray. A surface tint is the brand mixed with a lot of background. A border is the brand mixed with the surface. Text on a colored button is white or near-black mixed toward the brand for warmth. Five patterns, five recipes, and none of them need a color picker.

The payoff is not just fewer lines. It is that a new site takes one variable. I paste --brand: #e08a3c into the orange site and every derived color recomputes correctly against that hue. No re-picking. No invisible buttons. If you want the deeper context on how I keep theme code portable across properties, see The Shared Theme Layer. The color system is the part I trust most now because it cannot drift out of sync.

The 5 color-mix Patterns I Reuse Everywhere

Here are the exact five. I keep them in a single CSS block that ships to every property unchanged.

Pattern one, hover darkening:


--brand-hover: color-mix(in oklch, var(--brand) 88%, black);

Mixing 88 percent brand with 12 percent black gives a hover state that reads as "pressed" without going muddy. I use oklch because it keeps perceived lightness even, so a bright yellow and a deep blue both darken by a similar visible amount.

Pattern two, active or pressed:


--brand-active: color-mix(in oklch, var(--brand) 78%, black);

Same idea, deeper. This is the mousedown state, 22 percent black.

Pattern three, disabled:


--brand-disabled: color-mix(in oklch, var(--brand) 30%, var(--surface));

The key here is mixing toward --surface, not toward gray. A disabled button on a dark card mixes toward that dark card. On a white card it mixes toward white. It always looks faded relative to its actual background, which is the whole point.

Pattern four, surface tint:


--brand-surface: color-mix(in oklch, var(--brand) 8%, var(--surface));

This is the tinted panel behind a callout or a selected row. Eight percent brand is barely there, just enough to feel colored. I use 12 percent for hover on list rows.

Pattern five, subtle border:


--brand-border: color-mix(in oklch, var(--brand) 40%, var(--surface));

A border that belongs to the brand but does not shout. Forty percent reads as a clear edge without competing with text.

That is the whole system. Five variables computed from --brand and --surface. I paste this block, set two roots, and the theme is colored. I covered the broader idea of computed design tokens in Design Tokens Without a Build Step, because the same "derive, do not hardcode" rule applies to spacing and radius too. Color was just the loudest win.

Picking Accessible Text Color Automatically

The pattern I am proudest of solves the invisible-text problem. When you put text on a colored button, the text has to be light on dark buttons and dark on light buttons. Most people hardcode white and hope.

I do this instead:


--brand-text: color-mix(
  in oklch,
  var(--brand),
  white 60%
);

Wait, that is wrong for the general case. Here is the honest version I actually ship, which uses the relative color and a contrast-aware fallback. For text placed on top of the brand color, I mix toward whichever pole gives contrast. On my dark-brand sites I use:


color: color-mix(in oklch, white 92%, var(--brand));

That keeps text nearly white but pulls a trace of the brand hue in, so a button label feels part of the color instead of a pure-white sticker. On light-brand accents like the warm orange site I flip to near-black:


color: color-mix(in oklch, black 88%, var(--brand));

The trick is knowing which one to reach for. I decide once per site based on the lightness of --brand, set a --on-brand variable, and every button, badge, and tag uses var(--on-brand). One decision per property instead of a decision per component.

I test the result against WCAG contrast ratios manually the first time, then trust the system. The reason it holds is that oklch mixing preserves lightness relationships, so a text color that passes on the base brand also passes on the hover and active states, because those only shift darkness by 12 to 22 percent. The text stays readable across the whole button state machine from one mix.

This matters more than it sounds. Accessibility failures on buttons are the kind of thing you do not notice until someone tells you. By deriving text color from the same root that drives the button, I removed a class of bug entirely. There is no scenario where I set the button color and forget to update the text, because the text is computed from the button. Background: The Contrast Checks I Automate goes through the tooling I run before each launch, and it now catches almost nothing because the color-mix system prevents the mistakes upstream.

Rolling It Across raxxo.shop and Four Micro-Sites

The real test was portability. Five properties, five different accents, one codebase for the color logic.

Each site has a tiny root block. That is the only file that differs between them:


:root {
  --brand: #4f7cff;
  --surface: #12141a;
  --on-brand: white;
}

The orange site changes those three lines and inherits every derived variable identically. When I launched the fourth micro-site I copied the shared block, set three values, and shipped. No palette tuning. The disabled states, surface tints, and borders all recomputed against the new hue and the new surface without a single hand-picked color.

The number that matters to me: across five sites I now maintain zero site-specific color overrides beyond those three root values. Before, each site had roughly 15 to 20 accent-related declarations I had to keep in sync when I tweaked anything. That is 75 to 100 declarations I no longer touch. When I decided the brand blue was slightly too cold, I changed one hex on raxxo.shop and every derived shade shifted with it in one commit.

Browser support is a non-issue now. color-mix() ships in every current browser I care about. I keep a static fallback hex before each mix declaration for old engines, so the worst case is a flat brand color instead of a computed shade. Nobody gets a broken layout.

One caveat I hit: mixing in srgb versus oklch gives visibly different results. Early on I mixed in srgb and my hover states went gray and lifeless because sRGB blending muddies saturated colors. Switching every mix to in oklch fixed it instantly. If you copy the patterns above, keep the in oklch part. It is doing more work than it looks.

The color-mix layer also plugs into how I generate the rest of the theme with an assistant. I keep the five patterns documented so Claude regenerates them consistently when I scaffold a new site. The full workflow lives in the Claude Blueprint, which is where I keep every repeatable system that survives across properties.

Bottom Line

One brand variable, five color-mix() patterns, and an automatically chosen text color replaced a palette file I used to hand-tune for every launch. The result is a color system that cannot drift out of sync, because every shade is computed from the same root at runtime instead of copied from a picker.

The five recipes are all here: hover mixes toward black, disabled mixes toward the actual surface, surface tint mixes 8 percent brand, border mixes 40 percent, and text mixes toward white or black for contrast. Keep everything in oklch so saturated colors stay alive. Set three root values per site and the rest follows.

If you run more than one property, this is the highest-use half hour you can spend on your CSS. Copy the block, set your brand, and delete the palette file. Then read the Claude Blueprint if you want the rest of the system that keeps five sites shipping from one codebase.

Local-First Architecture for Solo Apps When CRDTs Help and When They Hurt

RAXXO Studios — Tue, 07 Jul 2026 00:09:00 +0000

Local-first cut my note app's perceived latency to zero across 3 devices
Yjs and Automerge solve sync conflicts you may not actually have
ElectricSQL saved 6 weeks versus hand-rolling CRDT plumbing
Ship a plain server first, add local-first only when offline is the feature

I built two apps with local-first architecture and one without. The one that needed it feels instant on 3 devices with zero spinners. The one that did not need it cost me a lot of extra effort and gave users nothing. Here is where the line actually sits.

What Local-First Actually Buys You

Local-first means the app writes to a local store first, renders from that store, and syncs to the server in the background. The user never waits for the network. That is the whole pitch, and when it fits, it is genuinely magic.

I built a note-taking app this way. Every keystroke writes to IndexedDB. The UI renders from that copy. Sync happens on a queue behind the scenes. Perceived latency dropped to zero. On a train with no signal, the app still works. When the phone reconnects, changes merge and appear on my laptop within a second or two. Users noticed. The retention numbers on the offline-heavy cohort were roughly 40 percent higher than the online-only version I shipped first.

The three tools I reached for were Yjs, Automerge, and ElectricSQL. Yjs is a CRDT library optimized for text and shared documents. Automerge is a more general CRDT with a nicer data model for structured JSON. ElectricSQL sits on top of Postgres and syncs a local SQLite replica, which is a very different shape of solution.

The key idea across all three is the conflict-free replicated data type. A CRDT is a data structure where two devices can edit the same thing offline and merge later without a server picking a winner. No lock, no last-write-wins clobbering. The math guarantees both edits survive in a sensible order.

That guarantee is powerful for exactly one class of problem: multiple devices or people editing the same mutable state while sometimes offline. Collaborative notes. A multi-device dashboard where I toggle a filter on my phone and expect it on my desktop. A shared task list two people poke at on a bad hotel network.

If that is your app, local-first is not overhead. It is the feature. Users feel it as speed and reliability, which are the two things they actually pay attention to. If you want the wider decision framework I use for tooling like this, the Claude Blueprint walks through how I scope a build before writing a line of sync code.

When CRDTs Are Wasted Work For Nothing

The second app was a small commerce dashboard. One user, one device most of the time, data that lives on the server and is read far more than written. I reached for a CRDT because I had just finished the note app and it felt like the modern way. That was a mistake that cost me a lot of wasted effort.

CRDTs are not free. The document only grows unless you compact it. Automerge documents I built accumulated history, and a list of 5,000 items ballooned to several megabytes on disk. I had to add a snapshot-and-truncate routine that took real effort to get right without dropping edits. Yjs handles this better with its update encoding, but you still think about garbage collection more than you want to.

Then there is the mental tax. Every piece of state becomes a CRDT type. You stop writing items.push(x) and start writing into a shared array with its own API. Debugging a merge that produced a weird order means reading about tombstones and Lamport timestamps at 1am. For an app that had no concurrent editing, all of that solved a problem I did not have.

The honest test is one question: do two writers ever touch the same record while one is offline? For my dashboard the answer was no. A plain server with optimistic UI would have given the same feel for one percent of the effort. Optimistic UI means you render the expected result immediately and reconcile when the server responds. That covers the "feels instant" half of local-first without any of the merge machinery.

Here is my rule now. Reads dominate and writes are single-writer? Skip CRDTs. Offline is a nice-to-have but not a promise? Skip CRDTs. Data is server-owned and the server is the source of truth? Skip CRDTs, use a cache and a mutation queue.

The trap is that CRDTs are intellectually interesting, and interesting is not the same as needed. I burned real effort proving that to myself. Build the boring version first. If users hit a wall that only merging solves, you will know, and you can add it then with actual evidence instead of a hunch.

Picking Between Yjs, Automerge, and ElectricSQL

These three get lumped together but they solve different shapes of problem, and picking wrong is where the wasted effort comes from.

Yjs is the one I reach for when the core object is a text document or a shared editing surface. It is tiny, fast, and the ecosystem around it is mature. There are ready bindings for common editors and a provider for WebSocket sync you can run yourself. If I were building anything resembling a collaborative writing tool, Yjs would be the default. The update format is compact, so bandwidth stays low even with chatty editing. The tradeoff is that its data model is lower-level. You are working with shared maps, arrays, and text types, and you build your app model on top.

Automerge is the choice when your state is structured JSON and you want the CRDT to feel like editing a plain object. The developer experience is nicer for app data (settings, lists, records) rather than freeform text. The cost, as I mentioned, is document size and performance at scale. Automerge 2 improved this a lot, but I still watch the byte count on anything with thousands of entries.

ElectricSQL is the odd one out and often the smartest pick for a solo builder. Instead of making you model everything as a CRDT, it syncs a local SQLite database against a Postgres server. You write normal SQL locally, it replicates in the background, and conflict resolution happens under the hood. For the note app, moving the structured metadata (folders, tags, timestamps) to ElectricSQL and keeping only the note body in Yjs cut my sync code roughly in half. That combination saved me about 6 weeks versus hand-rolling a CRDT layer for everything.

My decision tree is simple. Freeform collaborative text? Yjs. Structured app state that needs offline merge and you want an object model? Automerge. Relational data that is mostly server-owned but should work offline? ElectricSQL. Mixing two of them is normal and often correct. I do not treat this as a single-winner choice.

Whatever you pick, prototype the sync path on day one with two real devices and a flaky network. The happy path always looks fine. The reconnect path is where you learn whether you chose right.

The UX Details That Actually Matter

Once sync works, the app still lives or dies on a handful of UX details that have nothing to do with CRDT theory.

The first is the sync indicator. Users need to trust that their data is safe without being nagged. I settled on a quiet dot that goes from grey (syncing) to solid (synced) and only shows a real warning after 30 seconds of failed sync. Early on I showed a spinner on every write, which made the app feel slower than the online version it replaced. That was the opposite of the point.

The second is conflict presentation. CRDTs merge automatically, but automatic is not always what a human wants. If two devices edit the same note title offline, Yjs will interleave the characters and produce garbage nobody typed. For fields where interleaving is wrong (a title, a price, a single choice), I treat the field as last-write-wins with a timestamp rather than a CRDT text type. Use character-level merging only where character-level merging makes sense, which is prose and code, not form fields.

The third is initial load. A local-first app has to hydrate from the local store before it can render. On a cold start with a large document, that can be a visible pause. I split the initial sync so the visible viewport loads first and history streams in after. Time to interactive dropped from about 1.8 seconds to under 400 milliseconds on the note app.

The fourth is the multi-device story you actually promise. Cross-device sync is where local-first shines, and it is also where users file the angriest reports when it lags. I schedule my own status posts about updates through Buffer so I can tell users exactly when a sync fix ships, which cut the "is it broken" messages noticeably. And if you sell the app itself, running the storefront on Shopify kept my checkout out of the local-first codebase entirely, which is one less thing to sync.

None of these are hard. They are just easy to skip while you are deep in merge logic, and they are what users judge.

Bottom Line

Local-first is not a badge you earn by using CRDTs. It is a tradeoff. When your app has real offline needs or multiple devices editing shared state, the right stack (Yjs for text, Automerge for structured state, ElectricSQL for relational data) makes the app feel instant and cuts your sync code dramatically. When it does not, CRDTs are a pile of clever plumbing that users never notice, and you would have been faster with a plain server plus optimistic UI.

My advice after building both ways: ship the boring server version first. Add local-first only when you can name the specific offline or multi-device moment it fixes. Prototype the reconnect path on two real devices before you commit, because the happy path lies to you.

If you want the full framework I use to scope builds like this before writing code, the Claude Blueprint is where I keep it. Build the thing users feel, not the thing that reads well in an architecture diagram.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Shopify Metafields Done Right Three Patterns From Production

RAXXO Studios — Mon, 06 Jul 2026 00:07:45 +0000

Typed metafield definitions catch bad data before it reaches your theme
List-of-references replaces fragile comma-separated strings for product relations
One idempotent resync script beats hand-editing metafields in admin
Three patterns that scaled raxxo.shop to 200+ products without cleanup debt

I treated metafields like extra product attributes for about three weeks. Then a theme section broke on 40 products at once because one field held a string where the code expected a list. Here are the three patterns I use now on raxxo.shop, and why each one saved me from a specific mess.

Pattern One: Typed Definitions, Never Freeform

The first version of my store used metafields as loose key-value pairs. I would type product.metafields.custom.material in a theme section and hope the value looked right. It did not look right. Some products had "Cotton", some had "100% cotton", some had an empty string, and one had a full paragraph because I pasted the wrong thing at 1am.

The fix is metafield definitions with a strict type. In the Shopify admin under Settings, Custom Data, you define a metafield once with a namespace, a key, and a type. The type is the part people skip. You get single line text, integer, decimal, boolean, dimension, rating, JSON, date, and reference types. Pick the narrowest one that fits.

For a material field I use single line text with a validation regex. For a "featured" flag I use boolean, not a text field holding "yes". That one change means my theme can write {% if product.metafields.custom.featured %} and trust it. Before, "false" as a string was truthy, so every product showed as featured. Classic footgun.

Numbers matter here. I have 14 metafield definitions across products and collections. Every single one has an explicit type. When I import a batch of 30 products through the Admin API, Shopify rejects any value that fails the type. That rejection happens at the door, not three screens deep in a broken theme render. I would rather get a 422 in my import log than debug a blank section on a live page.

The other benefit is the admin UI. A typed definition gives editors a proper input. A boolean shows a toggle. A date shows a date picker. A rating shows stars. When you leave metafields untyped, the admin gives you a plain textbox and every human fills it differently. Types are documentation that the software enforces.

If you are on Shopify and still using untyped metafields, converting is a one-time job. Create the definition with the type, and existing values that already match keep working. Values that do not match show a validation warning so you can find and fix them. Do this before you have 200 products, not after.

Pattern Two: List Of References For Relations

My second big mistake was storing relationships as text. I wanted each product to link to related products, so I put comma-separated handles in a text field: hoodie-black,tee-white,cap-grey. It worked until a handle changed. Then the link pointed at nothing, and I had no way to know which products referenced the dead handle.

The right tool is a list-of-references metafield. Shopify has reference types for product, variant, collection, page, file, and metaobject. Pick the "list of" version and you get an ordered list of real object references, not strings. When I set a product's related products to a list-of-product-references, Shopify stores actual product IDs. If I delete a product, the reference resolves to nothing gracefully, and I can query which products still point at it.

In the theme this is much cleaner. Instead of splitting a string and looking up each handle, I iterate the reference list directly:


{% for related in product.metafields.custom.related.value %}
  {{ related.title }}
{% endfor %}

Every item in .value is a full product object. Title, price, featured image, URL, all available with no second lookup. No string parsing, no dead handles, no guessing whether the separator was a comma or a pipe.

I use this pattern for three relations on raxxo.shop. Related products (list of product references), a size guide page (single page reference), and downloadable files attached to a product (list of file references). The file reference one is the sleeper hit. I attach a PDF or a zip as a file reference and the theme renders a real download link with the correct CDN URL, even after I replace the file.

References also survive rename operations. When I renamed a collection last month, every metafield pointing to it kept working because it stored the ID, not the handle. Under the string approach I would have had to grep every product for the old handle and hand-edit each one.

The one gotcha: list-of-references metafields need the .value accessor in Liquid to resolve the objects. If you forget it you get IDs, not objects, and you waste 20 minutes wondering why titles are blank. I have wondered exactly that.

Pattern Three: One Idempotent Resync Script

Editing metafields by hand in the admin does not scale past about 10 products. I learned this by editing 40 products by hand and getting 3 of them wrong. So now I have a single resync script that owns all metafield writes, and the admin is read-only for metafields in my head.

The script reads a source of truth (a JSON file in my repo), then writes each metafield through the Admin API using metafieldsSet. The important word is idempotent. Running it once and running it ten times produce the same result. It does not create duplicates, it does not append, it overwrites the exact namespace and key with the value from my JSON. If the value already matches, the API call is a no-op and nothing changes.

Here is why idempotency matters in practice. Last week I added a new metafield to 60 products. I ran the script, it timed out on product 41 because of a rate limit. Under a non-idempotent design I would have half-written data and no clean way to resume. Instead I just ran it again. Products 1 through 40 were already correct so those calls did nothing, and it picked up 41 through 60. No manual reconciliation.

The script also handles the rate limit properly. Shopify's Admin API uses a leaky bucket, so I check the cost header on each response and back off when I get close to the limit. In practice I write about 2 metafields per second sustained, which clears 200 products in under two minutes. Slow enough to respect the limit, fast enough that I run it without thinking.

Everything lives in the same JSON source. When I want to change every product's shipping note, I edit one file and run one script. No clicking through 200 admin pages. This is the same philosophy I apply to the rest of the store: one command, repeatable, version controlled. If you want the deeper context on how I structure these repeatable jobs, the Claude Blueprint walks through the whole setup that generates scripts like this.

When something looks wrong on a product page, my first move is to run the resync and see if the page fixes itself. Nine times out of ten it does, which tells me a manual edit drifted from the source of truth. That signal alone is worth the whole pattern.

Where Metafields Go Wrong And How To Test

Most metafield pain comes from one root cause: treating them as a place to dump data instead of a typed contract between your data and your theme. Every problem I have hit traces back to a missing type, a string standing in for a relation, or a hand-edit that drifted.

Testing metafields is underrated because Shopify does not give you a native test use. My approach is a small verification step at the end of the resync script. After writing, it reads back a sample of products and checks that each expected metafield exists and has a non-empty value of the right shape. If a product is missing the related list, the script prints the product handle and exits non-zero. I see the failure in my terminal, not on a customer's screen.

I also keep a single "canary" product that carries every metafield I use. Before I push a theme change that touches metafields, I load the canary product page and confirm all sections render. It is a manual check that takes 30 seconds and has caught at least four broken sections before they went live. One product with full coverage beats guessing across 200 partial ones.

A few concrete rules I follow now. Never read a metafield in the theme without a fallback, because a new product will not have it yet. Always use .value for references. Never store IDs or handles as text when a reference type exists. Never edit a metafield in the admin if the script owns it, because the next resync will overwrite you anyway.

The payoff is real. On raxxo.shop I now add a product and its metafields populate from templates, the theme renders every section, and I never touch the admin metafield UI. What used to be 15 minutes of careful clicking per product is now zero. The store carries 200+ products with no metafield cleanup debt, and the reason is these three patterns doing the boring work every time.

If you schedule social posts that pull product data, the same discipline helps there too. I feed clean metafield values into my Buffer queue so captions never show a blank material or a broken related link.

Bottom Line

Metafields are a contract, not a junk drawer. Type every definition so bad data gets rejected at the door. Use list-of-references for anything relational so renames and deletes stay safe. Own all writes with one idempotent resync script so you never hand-edit past 10 products, and so a timeout is a re-run instead of a mess.

I got all three patterns wrong first. I typed strings where I needed booleans, stored handles where I needed references, and edited 40 products by hand until I got 3 wrong. Each fix was a one-time job that paid back every week after.

If you run a Shopify store and your metafields feel fragile, start with types today. It is the smallest change with the biggest safety gain, and existing matching values keep working. Then move relations to references, then write the resync script. The full toolchain I use to generate these scripts is in the Claude Blueprint if you want to see how the pieces fit together. Build the boring machine once and the store stops fighting you.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Pricing a Digital Product as a Solo Studio

RAXXO Studios — Sun, 05 Jul 2026 00:02:24 +0000

Three-question framework: floor, ceiling, anchor before any product ships
First three products were priced 40% too low, all three
The anchor question fixed pricing faster than any market research
Round numbers and a decoy tier beat clever fractions every time

I priced my first three RAXXO products by guessing. All three sat too low, and low pricing did not sell more copies, it just made the same number of buyers pay less. Here is the three-question framework I use now before anything gets a price tag.

Question One: What Is The Floor?

The floor is the number below which a sale actually costs me something. Not in a spreadsheet sense, but in a sanity sense. Every product I ship carries hidden weight: the support emails, the file hosting, the update I will eventually write when someone asks for a Windows version, the payment processing fees that skim a slice off every order.

My first product, a pack of 60 stylized textures, I priced at 7 EUR. That felt friendly. It also meant that after payment fees and the two support messages the average buyer sent, the actual take-home was so thin that a single request for a custom format wiped out three sales. I did not do that math up front. I picked 7 because it looked approachable.

The floor question forces the math. I now write down every recurring cost the product creates over its life, not just the moment of sale. For a digital download, the biggest ones are support time and platform fees. Shopify takes its cut, the payment processor takes its cut, and if the product needs any updates, that is future me working for free unless the price covered it.

The floor is almost never the price. It is the line that tells me how much room I have to move. For the texture pack, my real floor was closer to 12 EUR once I counted support. Pricing at 7 meant I had negative room. Every sale below the true floor is a slow leak.

A practical rule I use: the floor is at least three times the per-sale processing and support cost. That multiple gives me a cushion for the buyers who need extra help and the occasional payment dispute. If I cannot comfortably clear three times my per-sale friction, the product is either priced wrong or built wrong. Usually it is priced wrong, because I anchored on "friendly" instead of "sustainable." Friendly does not pay the hosting bill in month eight when the launch buzz is long gone and the product is still quietly generating three support tickets a week.

Question Two: What Is The Ceiling?

The ceiling is the highest number a buyer will pay before they stop and think "do I actually need this." That threshold is not about the file. It is about the outcome the buyer imagines.

My second product was a set of Blender lighting presets. I priced it at 14 EUR because it was "bigger" than the texture pack. Wrong logic. The lighting presets saved a working 3D artist maybe two hours per project. Two hours of a freelancer's time is worth far more than 14 EUR. I had priced the file, not the outcome. The ceiling for that product was easily 35 EUR, and the buyers who wanted it would not have blinked.

I find the ceiling by asking what the buyer is replacing. If my product replaces four hours of manual work, the ceiling sits somewhere near what four hours of that person's time costs them. If it replaces a 90 EUR tool subscription, the ceiling is anchored to that subscription. If it replaces nothing and just adds a nice-to-have, the ceiling drops fast, because desire without necessity has a short reach.

The mistake I keep watching solo creators make, myself included, is confusing effort with value. I spent a long time building those presets. That effort does not raise the ceiling. The buyer does not care how hard it was. They care what it does for them in the next 20 minutes. A product that took me an afternoon can carry a higher ceiling than one that took me a month, if the afternoon product removes a sharper pain.

The ceiling is also where scheduling and reach start to matter, because a higher ceiling means fewer buyers per hundred visitors, which means I need consistent traffic rather than a single launch spike. I run my social posts through Buffer so the product keeps getting seen for weeks, not just on launch day. A ceiling-priced product dies without steady visibility. If you want the deeper context on building that steady pipeline, see Claude Blueprint, which walks through how I keep output flowing without burning out. The ceiling gives me permission to charge what the outcome is worth. Steady reach gives that price enough shots to land.

Question Three: What Is The Anchor?

The anchor is the number the buyer sees first that makes my price feel reasonable. This is the question that fixed my pricing faster than any research, and it is the one most solo creators skip entirely.

When someone lands on a product with a single price and no context, that price has to defend itself alone. 24 EUR sitting by itself feels like a lot. 24 EUR sitting next to a 49 EUR "studio" tier feels like the sensible choice. The 49 EUR tier does not have to sell in volume. Its job is to make the middle option look obvious.

My third product launched with one price, 19 EUR, and no anchor. It converted poorly, and I assumed the price was too high. So I dropped it to 12. Sales barely moved. The problem was never the number. The problem was that 19 had nothing to sit against. When I later relaunched it with three tiers (a 12 EUR lite, a 24 EUR standard, and a 45 EUR pro bundle), the 24 EUR standard outsold everything, and the average order came in higher than the original 19 had ever managed.

Anchoring is not a trick to squeeze people. It is context. Buyers cannot judge value in a vacuum. They judge by comparison. If I do not give them a comparison, they invent one, and the one they invent is usually "free stuff I found elsewhere." That is the worst possible anchor for a paid product.

I now build the anchor before I build the price. The high tier can be the same product with a commercial license, a bundle with a past release, or a version with priority support. It does not need heavy work. It needs to exist so the main offer has something to lean against. I generate the extra preview assets for these tiers fast using Magnific so a bigger tier does not become a bigger production headache. The anchor earns its place by making the decision easier, not by being the thing most people buy.

What I Would Do Differently On The First Three

If I relaunched those first three products today, the changes are boring and effective. That is usually how it goes with pricing. The dramatic experiments rarely beat the discipline of asking three questions in order.

The texture pack would go from 7 EUR to 15 EUR with a 29 EUR extended-license anchor above it. Same files. The floor question would have caught the support leak before launch, and the anchor would have carried the standard price without a fight. I would also add a short video preview with narration, because a product that shows its outcome sells better than one that lists its contents. I use ElevenLabs to voice those previews so I am not re-recording every time I tweak a line.

The lighting presets would jump from 14 EUR to 32 EUR, priced against the hours they save rather than the size of the download. That single change would have roughly doubled what each buyer contributed without needing a single extra sale. The ceiling was always there. I just refused to look at it because 32 felt "greedy" for a file. It is not greedy to charge for the time you give back to someone.

The third product taught me the anchor lesson the expensive way, by watching me discount into a hole. I would never again ship a solo price with no tier structure around it. One price is a question with no reference point, and buyers answer "no" when they are unsure.

The through-line across all three: I priced from my own discomfort, not from the buyer's math. Solo creators tend to underprice because they feel every price personally, as if charging more is asking for a favor. It is not. The buyer is trading money for a result. My job is to make that trade clear and fair, and the three questions do exactly that.

Bottom Line

Floor, ceiling, anchor. I run every paid product through those three questions in that order before it ships, and it has stopped me from repeating the three mistakes that cost me the most: pricing below my true costs, pricing the file instead of the outcome, and shipping a lonely price with nothing to compare it against.

None of this requires market surveys or fancy tooling. It requires being honest about what a product actually costs me to keep alive, brave enough to price the outcome, and structured enough to give the buyer a reference point. The whole framework takes about 20 minutes per product now.

If you are building and selling your own work as a studio of one, the pricing decision is not the last step before launch. It is a design decision that shapes everything after. Start with the floor, find the ceiling honestly, and never ship without an anchor. For the wider system I use to keep shipping products at a steady pace, Claude Blueprint lays out the full workflow.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Why I Stopped Reaching for Redis on Solo Projects

RAXXO Studios — Sat, 04 Jul 2026 00:05:35 +0000

Six Redis use cases replaced with SQLite, Postgres, and Edge KV
Rate limiting fits in one SQLite table with 40 lines
Postgres LISTEN handles pubsub without a second service
One place Redis still wins: high-throughput shared queues

I ran Redis on every solo project for three years out of habit. Then I audited what it actually did on one app, and five of the six jobs moved to tools I was already paying for. Here is where each one landed and the single case where I kept Redis.

The Habit I Never Questioned

Redis was the first thing I added to a new project. Before I had users, before I had a schema, I spun up a Redis instance because that is what the tutorials did. It felt like infrastructure hygiene. It was actually cargo culting.

The problem showed up on the bill and in the ops load. A managed Redis instance ran me around 15 EUR a month per project, and I had six projects. That is 90 EUR a month for something most of those apps barely touched. Worse, Redis was a second stateful service to monitor, back up, and reason about. When it fell over at 2am, I got paged for a cache that could have been rebuilt in 200 milliseconds.

So I made a list of every reason I reached for Redis. Six things came up: rate limiting, sessions, background queues, caching, presence tracking, and pubsub. Then I asked a blunter question for each one. Does this app have enough traffic to justify a dedicated in-memory store, or am I using a jackhammer to hang a picture frame?

For every solo project I run, the honest answer was the jackhammer. My busiest app peaks at maybe 40 requests per second. Redis is built for tens of thousands. I was provisioning for a scale I would celebrate reaching.

The mindset shift was treating Redis as an optimization, not a default. You do not start with the optimization. You start with the boring tool that is already in your stack, measure, and only add Redis when a real number tells you to. I run everything on Shopify for storefronts and small Node apps for the rest, and none of them were near the ceiling. If you want the fuller philosophy on picking boring tools first, Claude Blueprint covers how I make these calls before writing a line of code.

Rate Limiting And Sessions On SQLite

Rate limiting was the scariest one to move because everyone tells you it needs Redis. The classic pattern is INCR with an expiry, atomic and fast. I assumed SQLite could not touch it.

It can. A single table with a key, a count, and a window-start timestamp handles it fine at my traffic. On each request I upsert the row, check if the window expired, and reset or increment. The whole thing is about 40 lines. SQLite handles the atomic write because writes are serialized anyway. On a solo app doing dozens of requests per second, the write lock is never the bottleneck.

Here is the shape of it. A rate_limits table keyed by identifier (IP or user ID) plus endpoint. One column for hits, one for window_start. On request, I read the row, and if now - window_start is over 60 seconds I reset both fields, otherwise I increment hits and reject if it crosses the threshold. No expiry daemon, no eviction policy, no second service.

Sessions moved the same way. I used to store sessions in Redis because the docs said session stores should be fast and ephemeral. But my sessions live for days, not milliseconds. That is not ephemeral, that is durable state, which is exactly what a database is for. A sessions table with a token, a user reference, and an expiry timestamp does everything Redis did, and it survives a restart without me thinking about persistence config.

The bonus I did not expect: I can query sessions with SQL. "Show me every active session for this user" is one line. In Redis that meant maintaining a separate index set and keeping it in sync. Two things that can drift out of sync became one thing that cannot.

I wrote more about how far SQLite stretches before you need anything heavier in SQLite Is Enough, which walks through the services I moved off heavier databases entirely. The short version is that most solo apps never generate enough concurrent writes to hit SQLite's real limits, and the ones that do usually have a specific hot table you can peel off rather than a general scale problem.

Queues, Caching, And Edge KV

Background jobs were my second-most-common Redis reason. Send an email, resize an image, hit a webhook. The reflex is a Redis-backed queue with workers pulling tasks.

For a solo app, a jobs table in Postgres does this cleanly. Insert a row with a status of pending. A worker polls for pending rows using SELECT FOR UPDATE SKIP LOCKED, marks them running, does the work, marks them done. The SKIP LOCKED clause is the trick that lets multiple workers pull without stepping on each other, and Postgres has had it since version 9.5. I run one worker per app and it clears hundreds of jobs a minute without breaking a sweat.

The failure story is better than Redis too. A crashed job stays in the table with its error logged. I can query failed jobs, retry them, or inspect them weeks later. A Redis queue that loses a job to a crash just loses it unless you built an acknowledgment layer, which is more code than the whole Postgres approach.

Caching split into two answers. For per-instance caching, an in-process cache in Node memory beats a network round trip to Redis every time. Reading a value from a local Map is nanoseconds. Reading from Redis is a network hop of a millisecond or more. If the data fits in memory and one instance can serve it, keep it in the instance.

For caching that needs to be shared across edge locations, I use Edge KV (Cloudflare's key-value store or the equivalent on my host). This is where the story flips: for globally distributed reads, Edge KV genuinely beats a single Redis box because the data sits near the user. A config blob or a feature flag read from KV at the edge is faster than a request traveling back to my central Redis. I cache rendered fragments and API responses this way, with a TTL, and the origin only sees a request when the cache misses.

The honest tradeoff with Edge KV is write latency and eventual consistency. Writes propagate over seconds, not instantly. For caches and flags that is fine. For anything that needs a read-your-own-write guarantee, it is not, and that pushed me toward Postgres for those cases.

Presence, Pubsub, And The One Redis Still Wins

Presence tracking (who is online, who is typing) was my flashiest Redis use. Sorted sets with timestamps, expiring old entries, the works. On a solo app with a few hundred concurrent users, a presence table with a last_seen timestamp and a query for rows updated in the last 30 seconds does the identical job. I update last_seen on a heartbeat and treat anyone stale as offline. No sorted set gymnastics.

Pubsub was the one I was sure needed Redis. Turns out Postgres has LISTEN and NOTIFY built in. One connection issues LISTEN channel_name, another issues NOTIFY channel_name, 'payload', and the message arrives. I use this to push updates to connected clients over server-sent events. When a job finishes, the worker fires a NOTIFY, my web process is listening, and it forwards the event to the browser. Zero extra infrastructure.

The payload size limit on NOTIFY is 8000 bytes, which is plenty for an event ID that the client uses to fetch the full record. I never push large payloads through pubsub anyway, so this has not bitten me once.

Now the honest part. There is one place Redis still wins on my projects: a high-throughput shared queue where many producers and many consumers hammer the same stream and Postgres polling becomes the bottleneck. I hit this on one app that ingests webhook events in bursts, thousands in a few seconds. Postgres SKIP LOCKED polling started showing lock contention and the poll interval added latency. Redis Streams handled the same burst with lower latency and no polling, because consumers block on new entries instead of asking repeatedly.

That is the rule I landed on. Redis earns its place when you have genuine high-frequency contention on a shared structure that database polling cannot keep up with. That is a measurable condition, not a hunch. For that one app I run a single small Redis instance and nothing else touches it. The other five projects run zero Redis. I covered the broader "measure before you add infrastructure" idea in SQLite Is Enough, and it applies here exactly.

Bottom Line

I removed Redis from five of six projects and nothing broke. Rate limiting and sessions went to SQLite tables. Queues and presence went to Postgres. Pubsub uses Postgres LISTEN/NOTIFY. Shared caching went to Edge KV, which is genuinely faster at the edge than a central Redis box. Redis stayed on exactly one app, where real burst traffic made polling the bottleneck.

The saving was around 75 EUR a month and one fewer stateful service to page me at night. But the bigger win was mental. Every service you add is something to monitor, back up, and reason about when it fails. Fewer moving parts means more time building the thing people actually pay for.

None of this means Redis is bad. It means Redis is an optimization, and optimizations need a number that justifies them. Start with the boring tool in your stack, measure your real traffic, and add the fast in-memory store only when a metric tells you to. If you want the framework I use to make these build-versus-add decisions before writing code, Claude Blueprint lays out the whole process. Audit your own stack this week. You might find a jackhammer hanging a picture frame too.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

The Stripe Webhook Patterns I Use to Avoid Lost Events

RAXXO Studios — Fri, 03 Jul 2026 00:07:28 +0000

Signature verification on the edge blocks forged payloads before they hit my logic
Idempotency keys stop duplicate order creation from Stripe retries
A dead-letter table catches the 0.3 percent of events that fail processing
Manual replay from the Stripe dashboard recovers stuck webhooks in under 5 minutes

I lost 3 paid orders in my first month selling digital products because a webhook silently failed and I never knew. No error, no alert, just a customer email asking where their download link was. After that I rebuilt my Stripe handling around 4 patterns, and I have not lost an event since. Here is exactly what runs on every paid product I ship.

Pattern 1: Verify the Signature at the Edge

The first thing any Stripe webhook endpoint does is prove the request actually came from Stripe. Without this, anyone who finds your endpoint URL can POST fake payment events and trigger free downloads. I have seen unprotected endpoints get hit within hours of going live.

Stripe signs every webhook with a secret. The signature lives in the Stripe-Signature header. My handler reads the raw request body (not the parsed JSON, this matters), then calls the verification function with the raw body, the header, and my signing secret. If it fails, I return a 400 immediately and log nothing beyond a counter.

The detail that trips people up: you have to verify against the raw bytes. If your framework parses the body into JSON before your handler runs, the signature check fails every time because the byte order changed. On my edge functions I disable body parsing for that one route and grab the raw stream myself. About 15 minutes of setup, and it closes the biggest hole.

I run this check at the edge, meaning the verification happens in the function closest to the request before any database call. A forged payload never touches my order logic, never opens a connection, never costs me a compute cycle beyond the rejection. In practice this means a bot spraying my endpoint hits a wall and gives up.

One more thing I learned the hard way: keep separate signing secrets for test mode and live mode. I once deployed the test secret to production and every real payment webhook bounced with a signature error for 40 minutes. I only caught it because I had a dashboard counter (more on that later). Now the secret is an environment variable that gets swapped per environment, and I have a startup log line that prints which mode the key belongs to so a mismatch is obvious.

If signature verification passes, I do exactly one thing next: return a 200 fast and hand the work to the next pattern. Stripe expects a response inside a few seconds, and slow handlers cause retries you do not want.

Pattern 2: Idempotency Keys Against Duplicate Delivery

Stripe does not promise a webhook arrives exactly once. It promises at-least-once. That means the same checkout.session.completed event can land on your endpoint twice, sometimes three times, especially if your first response was slow. Without protection, one purchase becomes two order records, two download emails, two of everything.

Every Stripe event carries a unique id that looks like evt_1abc.... I treat that id as an idempotency key. Before I process anything, I try to insert that event id into a processed_events table with a unique constraint on the id column. If the insert succeeds, this is the first time I have seen it and I process normally. If the insert fails on the unique constraint, I have already handled it, so I return 200 and stop.

The insert-first approach beats a check-then-insert because it avoids a race. If two copies of the same event arrive within milliseconds (it happens), a read-then-write pattern lets both pass the check before either writes. The unique constraint at the database level makes the race impossible. Only one insert wins.

I store the event id, a timestamp, and the event type. Nothing else. The table stays small and fast. I prune rows older than 30 days with a scheduled job because Stripe will not retry an event that old anyway. My table sits around 4,000 rows on a steady week and the lookup is instant on the indexed id.

This one pattern eliminated the double-email complaints that made up most of my early support load. If you want the deeper context on wiring these patterns into a working store, see Claude Blueprint, which walks through the whole paid-product setup I run.

The subtle payoff: idempotency also protects you when you replay events manually during a bug fix. You can safely re-send 200 events at your endpoint knowing the already-processed ones will be skipped. That safety net is what makes Pattern 4 usable without fear.

Pattern 3: Dead-Letter Handling for the Events That Fail

Roughly 0.3 percent of my events fail on the first try. A database timeout, a third-party API being down, a bug I shipped that afternoon. The wrong move is to return a 500 and pray Stripe retries. Stripe does retry, but its schedule spreads over hours and eventually gives up. If your bug lasts longer than the retry window, that event is gone.

My fix is a dead-letter table. When processing throws an error, I catch it, write the full event payload plus the error message and a retry count into a failed_events table, and then return 200 to Stripe. Returning 200 tells Stripe the event was received so it stops retrying on its own schedule. I now own the retry, not Stripe.

A scheduled job runs every 10 minutes and picks up any row in failed_events with a retry count under 5. It reprocesses the stored payload through the same handler. Because Pattern 2 uses idempotency keys, a reprocess that partially succeeded the first time will not duplicate anything. If it succeeds, I mark the row resolved. If it fails 5 times, I flag it for manual review and send myself an alert.

The alert matters more than the automation. When something lands in the dead-letter table and cannot self-heal, I want to know within minutes, not from a customer email 2 days later. I pipe the alert to a private channel and to my phone. Last month one event stuck because a download-hosting provider had an outage. My job retried, the provider came back after 22 minutes, and the next retry cleared it. The customer never noticed a thing.

I also log every dead-letter write with a counter. A sudden spike from 2 per day to 50 tells me I broke something in a deploy before any customer complains. That counter has saved me twice. Background: the same alerting habit carries over to how I monitor everything else, and I covered this in more depth at Claude Blueprint.

The mindset shift is simple. Assume events will fail. Build the recovery path first.

Pattern 4: Manual Replay When a Webhook Gets Stuck

Even with the first 3 patterns, sometimes an event needs a human. Maybe I deployed broken code and 12 events failed all 5 automatic retries. Maybe I added a new product type my handler did not recognize. When that happens, I have two recovery routes, and both take under 5 minutes.

Route one is the Stripe dashboard. Every webhook endpoint in Stripe shows a log of recent deliveries with their response codes. I filter to the failed ones, click into a specific event, and hit "Resend". Stripe fires the exact same payload at my endpoint again. Since my signature verification and idempotency both handle re-delivery cleanly, this is safe to do dozens of times. I once resent 30 events in a row after fixing a bug and every one processed correctly on the resend.

Route two is my own dead-letter table. If Stripe already gave up and the event only lives in my failed_events rows, I do not need Stripe at all. I have a small admin action that reprocesses a single row on demand. I fix the underlying code, deploy, then click reprocess. The stored payload runs through the fixed handler.

The trick to making replay painless is deciding it early. Do not bolt on replay after your first outage. Store the raw payload from day one. A failed event you did not store is a failed event you cannot recover, and Stripe only keeps its own copy for a limited window. Storing the full JSON costs almost nothing and turns a 2 am panic into a calm click.

I also keep a short runbook in plain text next to my code. Three steps: check the dead-letter table, decide dashboard-resend or admin-reprocess, verify the counter dropped to zero. Having the steps written down means I do not think under pressure, I just follow the list. When I sat down to write my scheduling and syndication flow I used the same runbook habit, and Buffer handling the social posting side kept that whole pipeline off my plate so I could focus on payment reliability.

Bottom Line

These 4 patterns are not clever. Signature verification blocks forged requests, idempotency keys kill duplicates, a dead-letter table catches failures, and manual replay recovers the rest. Together they turned lost orders from a recurring headache into a problem I have not seen in over a year. The whole setup fits in maybe 150 lines of handler code plus two small tables.

If you sell anything through Stripe, build the recovery path before you launch, not after your first outage. Store the raw payload, add the unique constraint, wire an alert to your phone. The 0.3 percent of events that fail are the ones customers remember, so make those the ones you handle best.

If you want to see how this fits into a full solo product stack, from payments to hosting to the store itself on Shopify, the Claude Blueprint lays out the whole system I run day to day. Start with signature verification this week. It is the fastest win and closes the biggest hole.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Form UX in 2026 Native HTML Validation Is Finally Enough

RAXXO Studios — Wed, 01 Jul 2026 00:05:49 +0000

Removed a 12 KB validation library across 3 surfaces using native HTML
:user-valid and :user-invalid fire only after interaction, killing premature error noise
accent-color styles checkboxes and radios in one line, no SVG hacks
Form-associated custom elements let web components join native validation

I deleted a 12 KB form validation library last month and the forms got better, not worse. Three RAXXO surfaces now run on native HTML validation alone, and the error timing feels more polished than the JavaScript version it replaced. Here are the 5 patterns that made it possible.

The Constraint Validation API Does The Heavy Lifting

Every input element already carries a validity object. You do not import it. You do not configure it. It is sitting on input.validity right now, tracking eight separate states: valueMissing, typeMismatch, patternMismatch, tooLong, tooShort, rangeUnderflow, rangeOverflow, and stepMismatch. The browser computes these on every keystroke for free.

My old setup had a rule engine. Required fields, email format, minimum length, all of it lived in a config object that I hand-fed to the library on page load. That config was 140 lines across the checkout form, the contact form, and the newsletter signup. I replaced almost all of it with attributes the browser has understood for over a decade.

The required attribute handles valueMissing. The type="email" handles typeMismatch. The pattern handles patternMismatch with a regex. No library parses these. The HTML parser does.

When I do need custom logic, like checking that a discount code matches a format the regex cannot express, I call setCustomValidity(). Pass it a string and the field becomes invalid with that message. Pass it an empty string and the field becomes valid again. That is the entire API surface for custom rules.


input.addEventListener('input', () => {
  const ok = /^RAXXO-\d{4}$/.test(input.value);
  input.setCustomValidity(ok || !input.value ? '' : 'Code format is RAXXO-1234');
});

The form's own checkValidity() method walks every field and returns true or false. The reportValidity() method does the same but also shows the native error bubble on the first bad field. Two method calls replaced a submit handler that was 60 lines long. If you want the full reasoning behind why I keep cutting dependencies like this, see Why I Delete Libraries First. The pattern repeats across every surface I touch.

:user-valid And :user-invalid Fixed My Worst UX Problem

The classic complaint about native validation is timing. The plain :invalid pseudo-class matches an empty required field the instant the page loads. So every form lights up red before the visitor has typed a single character. That is hostile, and it is why most people reached for a library in the first place. The library tracked a "touched" state per field so errors only appeared after you interacted.

The browser does that now. :user-invalid only matches after the user has interacted with the field and then left it in a bad state. :user-valid is the mirror. No touched state to track. No blur listeners. The browser owns the interaction history.


input:user-invalid {
  border-color: #d4183d;
}
input:user-valid {
  border-color: #1a7f46;
}
input:user-invalid + .error-text {
  display: block;
}

This single change removed the largest chunk of my old library's job. The touched-state machinery was roughly a third of its code. I checked the support tables before committing: :user-valid and :user-invalid ship in every current browser engine, and the fallback is graceful. Older browsers just do not show the green or red until submit, which is acceptable.

The error text trick above is worth calling out. I put a hidden .error-text span after each input and reveal it with the sibling combinator only when the field is in a :user-invalid state. The browser decides when. I just decide how it looks. No JavaScript runs to show or hide a single error message anymore.

On the checkout surface this mattered most. Visitors fill in eight fields. Under the old system, a stray re-render could flash all eight red. Under :user-invalid, a field stays neutral until you have actually touched it and moved on. The form feels calmer. I did not write a line of code to make it calmer. I deleted the lines that were making it loud. For the broader thinking on shipping less and getting more, The Subtraction Habit covers the mindset that led me here.

accent-color And :has() Killed My Custom Control CSS

Checkboxes and radio buttons used to be the reason people built entire form kits. The native ones were ugly and unstylable, so every library shipped its own SVG-based replacements with hidden inputs and pseudo-elements. That replacement code is a liability. It breaks keyboard focus, it confuses screen readers, and it adds weight.

accent-color ended that for me with one line.


:root {
  accent-color: #6c3df4;
}

That recolors every checkbox, radio, range slider, and progress bar on the page to match my brand purple. The controls stay native. Keyboard navigation works because I never replaced the real element. Screen readers announce them correctly because they are still real inputs. I deleted maybe 200 lines of SVG checkbox markup and CSS across the three surfaces and replaced it with that one declaration plus a per-form override where I needed a different shade.

Then :has() cleaned up the layout logic. I used to toggle a class on the label wrapper when a checkbox was checked, which meant a change listener and a classList.toggle. Now the CSS reads the state directly.


label:has(input:checked) {
  background: #f3effe;
  font-weight: 600;
}
.shipping-options:has(:checked) .next-button {
  opacity: 1;
}

The parent reacts to a child's checked state with no JavaScript at all. That second rule enables a button only once a shipping option is selected, purely in CSS. I tested this against the same flows I run for product visuals, where I lean on tools like Magnific for upscaling, and the form felt as crisp as the imagery around it.

The combined effect: the visual customization that justified a form library is now four CSS declarations. accent-color for the controls, :has() for the reactive states, :user-invalid for the errors, and a sibling combinator for the messages. I keep finding that the platform shipped the feature while I was busy importing a workaround for it. If you want the deeper context on building UI without frameworks, I covered this in more depth at Vanilla UI That Scales.

Form-Associated Custom Elements Closed The Last Gap

There was one thing native validation could not do, and it was the reason I kept a sliver of the old library around. I have a custom rating widget, a five-star control built as a web component. It is not a real input. So it could not participate in the form's validity. It could not be required. It could not show in checkValidity(). It sat outside the system.

Form-associated custom elements fixed that. By setting static formAssociated = true and grabbing an ElementInternals object, a web component becomes a first-class form participant. It submits a value. It joins constraint validation. It can mark itself invalid with a message and the form will refuse to submit, exactly like a native input.


class StarRating extends HTMLElement {
  static formAssociated = true;
  #internals;
  constructor() {
    super();
    this.#internals = this.attachInternals();
  }
  set value(v) {
    this.#internals.setFormValue(v);
    this.#internals.setValidity(
      v ? {} : { valueMissing: true },
      'Please pick a rating'
    );
  }
}

The setFormValue call puts the rating into the form data on submit. The setValidity call wires it into the same validity machinery every native input uses. Now form.checkValidity() includes my custom widget. The :user-invalid styling applies to it. The submit gets blocked if no star is chosen. I deleted the bridge code that used to glue my widget into the JavaScript validation library, because the widget now talks to the browser directly.

This was the last 12 KB to go. The library survived as long as it did purely because of this one widget, and once ElementInternals covered it, the whole dependency had no reason to exist. I removed the import, ran the three forms through every failure case I could think of, and shipped. Nothing broke.

If you build custom controls and assume they cannot join native validation, check again. The capability is in every current engine. The same principle drives the architecture I document in the Claude Blueprint, where I lay out how I keep my whole stack lean enough for one person to maintain. Less glue code means fewer things that can rot.

Bottom Line

Native HTML validation in 2026 is not a partial solution you grudgingly accept. It is the better one. The Constraint Validation API handles rules. :user-valid and :user-invalid handle timing, which was the only real reason libraries existed. accent-color and :has() handle styling without replacing real controls. Form-associated custom elements pull your web components into the same system. Five patterns, zero dependencies, 12 KB lighter across three surfaces.

The forms are faster to load, easier to maintain, and more accessible, because I stopped reinventing controls the browser already ships correctly. I write less code now and the code I keep does more, because the platform absorbed the work.

If you are still importing a validation library, open your form and try deleting it. Wire the attributes back to native, add the four CSS rules, and see what actually breaks. For me, almost nothing did. If you want the full picture of how I keep a solo studio shipping with this little overhead, the Claude Blueprint walks through the whole approach end to end.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Managing Design Tokens Across 14 Projects Without a Tool

RAXXO Studios — Tue, 30 Jun 2026 00:05:31 +0000

One tokens.json source feeds 14 projects with zero infrastructure
A 30-line Node script outputs CSS, JS, and JSON
Style Dictionary adds config overhead a solo studio never recovers
The pattern breaks the day a second team needs to negotiate

I run 14 projects from one machine and they all share the same color, spacing, and type scale. There is no design tool involved, no platform, no plugin. One JSON file and a 30-line build script do the whole job, and I have never once wished for more.

Why I Skipped Style Dictionary Entirely

Style Dictionary is the standard answer when someone asks how to manage design tokens. It is a good tool. It is also built for a problem I do not have. The whole point of Style Dictionary is to let many people, on many platforms, agree on a shared token format and transform it into iOS, Android, web, and Figma outputs without arguing. That negotiation layer is the value. When you are one person, there is nobody to negotiate with.

I tried it anyway, early on. I set up the config, the transforms, the platform definitions. Within an afternoon I had a folder of config files that were longer than the tokens they described. I was maintaining the machine that maintained the tokens. For a solo studio that is backwards. The tool earns its keep when the coordination cost it removes is larger than the setup cost it adds. With one builder and one set of opinions, the coordination cost is zero, so any setup cost is pure loss.

So I deleted it. What I replaced it with is a single file called tokens.json and a script that reads it. The file has maybe 80 entries across colors, spacing, radii, font sizes, and a few motion values. The script outputs three formats: a CSS file with custom properties, a JS module with the same values as exported constants, and a flat JSON copy for anything that wants raw data. Three outputs, one source, no config.

The honest version of this story is that most token tooling is sized for teams of 20. If you are below five people, the math flips. You spend more time learning the tool's idea of a "transform" than you would spend writing the transform yourself. I would rather own 30 lines I fully understand than import 30,000 I will never read. If you want the broader reasoning behind building small tools instead of adopting big ones, Claude Blueprint walks through how I make that call across the studio.

The Single tokens.json That Feeds Everything

The source file is boring on purpose. It is a nested object grouped by category, and every leaf is a value. Colors live under color, spacing under space, and so on. I use a simple rule: the key path becomes the token name. So color.brand.primary becomes --color-brand-primary in CSS and colorBrandPrimary in JS. No aliases, no references, no themes baked into the file itself. When I want a dark theme I add a second top-level key called dark and the build script knows to emit it as a scoped block.

Here is the part that makes this survive across 14 projects: the file is copied, not shared. Each project has its own tokens.json. That sounds wrong. The whole appeal of tokens is a single source of truth, and I just told you I have 14 sources. But a shared package would force every project to upgrade in lockstep, and my projects do not move in lockstep. One is a storefront on Shopify, one is a video pipeline, one is a static marketing page. They have different rhythms.

What they share is the shape of the file and the build script, not the values. I keep a canonical tokens.json as a template. When I start a project I copy it, then drift the values to fit. When I make a structural improvement to the script, I copy that across by hand, which takes two minutes per project and happens maybe four times a year. The cost of manual propagation is real but tiny, and in exchange I never break a live project by changing a shared dependency.

The other thing the JSON does is double as documentation. Because the keys are human readable and grouped, opening the file tells you the entire design language in one screen. No Storybook, no token explorer, no hosted reference. A new collaborator (or me, six months later) reads one file and understands every available value. I keep comments out of the JSON itself, since JSON does not allow them, and instead keep a short tokens.md next to it explaining the intent behind the scale choices.

The 30-Line Build Script, Line By Line

The script is plain Node, no dependencies. It reads tokens.json, walks the object recursively, and flattens every leaf into a name and value pair. The recursion is the only clever part, and it is about eight lines: if a value is an object, recurse and prefix the key; if it is a string or number, push it onto the flat list. That is the entire transform engine that Style Dictionary charges you a config file for.

Once flattened, the rest is formatting. For CSS I join each pair into --name: value; and wrap it in a :root block. For the dark theme I wrap the same in a [data-theme="dark"] selector. For JS I emit export const name = value; for each pair. For JSON I just write the flattened object back out. The whole thing runs in well under a second and I wire it into the project's build step, so any change to tokens.json regenerates all three outputs before the app compiles.

The discipline that makes this work is naming. Because token names are derived mechanically from key paths, I cannot rename a token without renaming the key, and renaming the key updates every output at once. There is no place for a name to drift out of sync, because there is only one place names exist. This is the quiet superpower of generating instead of hand-writing: consistency is not a rule I follow, it is a property of the system.

I also added one validation pass. Before emitting, the script checks that no two flattened keys collide and that every color value is a valid hex or rgb string. Maybe six lines. It has caught real mistakes, mostly me fat-fingering a nested key so two paths flattened to the same name. Catching that at build time instead of in production is worth the six lines twice over.

Motion values live in the same file. Durations and easings are tokens like anything else, and treating them as first-class members of the system kept my animations consistent across projects. I went deep on that idea in Motion Design Tokens That Actually Compose, because timing values reward the same single-source treatment that colors do. If you can build the script in an afternoon, you understand every line, and that understanding is the actual asset, not the file.

Where This Pattern Breaks If You Scale

I want to be honest about the ceiling, because copying my setup blindly will hurt you the day you outgrow it. This approach assumes one person holds the whole design language in their head and makes every change. The moment a second team needs to add tokens, the manual propagation I described becomes a liability instead of a feature. Two people copying script changes by hand will drift, miss updates, and eventually ship two incompatible versions of the same token set.

The second break point is platforms. I output CSS, JS, and JSON because that covers everything I ship, which is all web. The day I need native iOS values, Android XML, and a Figma sync, my 30-line script becomes 300 lines of platform transforms, and at that length you are rebuilding Style Dictionary badly. That is exactly the threshold where the real tool starts paying for itself. The setup cost it charges is finally smaller than the coordination cost it removes.

The third is themes at scale. My dark-theme-as-second-key trick works for two themes. It does not work for a dozen brand variants, each with overrides and inheritance rules. Real theming engines exist for a reason, and the reason shows up around theme number four.

So the rule is simple. Solo, web only, two or three themes: my pattern wins by a wide margin and I would recommend it without hesitation. Add a second independent team, a native platform, or a real theming matrix, and you should adopt the heavier tool before the pain arrives, not after. The mistake is not picking the small tool. The mistake is keeping the small tool past the point where the assumptions behind it stopped being true.

For scheduling the social posts that announce a design refresh across projects, I lean on Buffer so a single token update can ship visibly without me touching 14 dashboards by hand. That same instinct, one source feeding many outputs, is the thread running through everything I build.

Bottom Line

Design token tooling is sized for teams, and most advice online assumes you are one. If you run solo, the honest move is to skip the platform and own a tiny system you fully understand. One tokens.json per project, a 30-line Node script that emits CSS, JS, and JSON, and a copy-not-share rule that lets every project move at its own pace. No dependencies, no config files longer than the data they describe, no machine to maintain the machine.

It scales to exactly the size of one person, and that is the point. Know the three break points (a second team, a native platform, a real theming matrix) and switch to the heavier tool the moment any of them shows up, not a day sooner. I have run this across 14 projects without regret, and the day it stops fitting I will graduate without drama.

If you want the studio-wide thinking behind building small instead of adopting big, Claude Blueprint lays out the whole approach. Steal the script, change the values, ship.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Edge Functions vs Serverless for Solo Projects A Practical Comparison

RAXXO Studios — Mon, 29 Jun 2026 00:10:58 +0000

Edge wins for cookie gating, redirects, AB tests at sub-20ms cold starts
Serverless wins for DB queries, heavy deps, long-running jobs
6 months of Vercel bills came to roughly 38 EUR total
Run both: edge at the front door, serverless for the heavy lifting

I run every site I own on a split setup: edge functions handle the fast stuff at the front door, serverless handles anything that touches a database or a fat dependency. After six months of real traffic and real bills, here is exactly where each one earns its place and where it falls apart.

Where Edge Functions Actually Win For Me

Edge functions run close to the visitor. Instead of one server in Frankfurt, the code runs at whatever location is nearest to the request. For me that means three jobs they do better than anything else.

First, cookie gating. I check a cookie before a page renders to decide whether someone has already seen a banner, accepted a region notice, or unlocked a gated post. On serverless this took 120ms to 300ms because of the cold start plus the round trip. On the edge it runs in 8ms to 18ms. The visitor never feels it. The page just appears already personalized.

Second, redirects. I have a few hundred old URLs that map to new handles. Doing this in the edge means the redirect fires before the request ever reaches my main app. I measured the difference: a serverless redirect added about 180ms on a cold path. The edge version sat at 11ms consistently. Multiply that across a launch day with 40,000 redirects and the saved time stops being theoretical.

Third, AB testing. I split traffic 50/50 on a headline and a hero image. The edge function reads a hashed visitor ID, assigns a bucket, sets a cookie, and rewrites the request. No flicker, no client-side flash of the wrong version. The assignment happens before the HTML leaves the network. Client-side AB tools always gave me that ugly flash where the original loads, then swaps. The edge version killed it entirely.

The common thread: these are all small, stateless, fast decisions that need to happen at the very start of a request. No database. No big libraries. Just read a header, do some math, rewrite or redirect. That is the exact shape the edge is built for.

I keep these functions tiny on purpose. The largest edge function I run is 140 lines. If a function starts wanting a database client or a date-parsing library that pulls in 40 dependencies, that is my signal it does not belong here. If you are wiring up a new project from scratch, the Claude Blueprint walks through how I decide what lives where before I write a line.

Where Edge Functions Lose Badly

The edge is fast because it is limited. Those limits hurt the moment your code needs to do real work.

Database access is the big one. Most edge runtimes do not support raw TCP connections, which is how Postgres and MySQL traditionally talk. So your normal database driver will not run there. You either use an HTTP-based database proxy, a serverless driver built for the edge, or you give up. I tried routing edge functions to my Postgres through a connection pooler and the latency advantage evaporated. The function ran in 12ms but then waited 90ms for the database because the edge location was nowhere near my database region. Fast code, slow data, no point.

Long-running tasks are the second wall. Edge functions have tight time and memory budgets. I have jobs that generate a sitemap, hit three external APIs, and stitch the results. That takes 4 to 9 seconds. The edge will kill it long before that. Serverless lets it run to completion without complaining.

Heavy dependencies are the third problem. The edge runtime is not full Node. Plenty of npm packages assume Node built-ins that simply do not exist there. I had a function that used a PDF library and an image processing tool. Both broke immediately on the edge with cryptic errors about missing modules. Moving them to serverless fixed it in one deploy. For anything involving image generation I lean on a hosted tool like Magnific instead of bundling a giant library into my own function anyway.

There is also a debugging cost people skip over. Edge logs are thinner. Stack traces are vaguer. When a serverless function throws, I get a clean trace pointing at line 34. When an edge function throws, I sometimes get a generic runtime error and have to bisect the code by commenting things out. For fast trivial functions that is fine. For anything with branching logic it gets old.

My rule after six months: if the function needs my database, runs longer than two seconds, or imports anything heavier than a small utility, it goes to serverless. No exceptions. The minute I bent that rule I ended up with a function that worked locally and died in production.

The Actual Cost Numbers From Six Months

Here is the part nobody shows you. I pulled every Vercel bill from the last six months and added them up.

Total across six months: roughly 38 EUR. That covers a personal-tier plan for two of the months when I was running heavier experiments, and the free tier for the rest. The traffic was not huge but it was not nothing either. Across those six months the sites served around 1.9 million edge function executions and about 240,000 serverless function executions.

The split tells the real story. Edge functions are dramatically cheaper per execution and they bill in a way that rewards small fast work. My 1.9 million edge calls cost almost nothing because each one finished in under 20ms and used trivial memory. The serverless calls cost more per execution because they ran longer and held more memory open while waiting on databases and APIs.

So the cheapest architecture was also the fastest one: push as much as possible to the edge, keep serverless calls rare and deliberate. Every time I moved a redirect or a cookie check off serverless and onto the edge, my bill went down and my page got faster at the same time. That almost never happens in infrastructure. Usually faster costs more.

One number surprised me. The single most expensive thing I ran was a serverless function that polled an external API every few minutes on a schedule. It was not user-facing, it just ran in the background. That one cron-style job quietly accounted for a meaningful chunk of my serverless execution time because it ran whether anyone visited or not. I moved it to a less frequent schedule and the cost dropped by more than half. The lesson: user-triggered functions scale with your traffic, but scheduled functions cost money even at 3am with zero visitors. Audit your crons first.

If you are deciding whether a hosted platform is even worth it versus rolling your own, the math at this scale is clear. 38 EUR over six months is less than I would pay for a single small always-on server, and I never touched an operating system update once.

My Practical Split For Every New Project

When I start a project now I do not debate edge versus serverless. I run both, and I sort each function the moment I write it.

Front door gets the edge. That means anything that runs on every request before the page renders: auth cookie checks, geographic redirects, AB bucket assignment, bot filtering, and header rewrites. These functions stay under 150 lines, import nothing heavy, and never touch my database. They run in single-digit to low-double-digit milliseconds and they are basically free at my volume.

Back room gets serverless. That means form handlers, database reads and writes, API stitching, file processing, scheduled jobs, and anything that calls a third-party service and waits. These tolerate a cold start because they are not in the critical path of a page render. A 200ms cold start on a form submission is invisible. A 200ms cold start on every redirect is a disaster.

The handoff matters. My edge function makes the fast decision, then forwards to serverless only when real work is needed. So a request might hit the edge, get bucketed for an AB test in 10ms, then forward to a serverless function that pulls the right content from the database in 120ms. The visitor experiences the fast part instantly and only waits for the slow part when there is genuinely slow work to do.

For social scheduling and the bits that live outside my own code, I keep those off my functions entirely and use a dedicated tool like Buffer so I am not paying serverless time to post things on a timer. And when I build on a storefront, Shopify already handles a lot of the front-door logic, so my custom functions get even smaller.

The mental model that finally clicked: the edge is a bouncer and serverless is the kitchen. The bouncer is fast, checks your ID, points you to the right room. The kitchen is where the actual cooking happens, and it is fine if it takes a minute. Trying to cook at the front door is how I broke production. Trying to check IDs in the kitchen is how I made pages slow.

Bottom Line

After six months and 38 EUR of bills, my takeaway is boring and reliable: use both, and sort by job. Edge functions are unbeatable for the fast stateless decisions that happen on every request, cookie gating, redirects, and AB tests. They are also the cheapest thing I run. Serverless is where the real work lives, database queries, heavy dependencies, and anything that takes more than a couple of seconds. The two are not competitors. They are different rooms in the same house.

If you only remember one rule, make it this: if a function needs your database, runs long, or imports something heavy, it is serverless. Everything else belongs on the edge. That single test has saved me from every production surprise since I started following it.

If you want the full picture of how I wire a project together from the first commit, the Claude Blueprint lays out the decisions in order. Start small, measure your own bills, and let the numbers tell you where each function should live.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

The Liquid Patterns That Cut My Theme Build Time in Half

RAXXO Studios — Sun, 28 Jun 2026 00:04:08 +0000

Schema fragments cut section files by 40 lines each
Conditional snippets replaced 12 near-duplicate blocks
asset_url helpers ended broken image paths for good
settings inheritance and content_for_index hooks compose like LEGO

I rebuilt my Shopify theme last month and finished in roughly half the hours the previous one took. The difference was not speed of typing. It was five Liquid patterns that turned every section file from a wall of copy-paste into something I could compose from parts. Here is exactly what they are and how I use them.

Schema Fragments Stop The Copy-Paste Spiral

The first thing that ate my time on old builds was schema. Every section needed a heading setting, a subheading, a button label, a button link, a color picker. I would copy 40 lines of JSON from another section, rename half the IDs, miss two of them, and spend ten minutes hunting a typo that broke the editor.

Now I keep a folder of schema fragments as snippets. Not the full {% schema %} block (Liquid does not let you render schema from a snippet), but the JSON text itself stored as reference files I paste from. I have a fragment for a heading group (heading, subheading, alignment), one for a button group (label, link, style), and one for a section spacing group (padding top, padding bottom in a range slider).

Each fragment uses a consistent ID prefix. The heading fragment always uses heading, subheading, heading_alignment. Because the IDs never change between sections, my Liquid markup that reads them never changes either. I can drop the same {{ section.settings.heading }} block into any section and it works.

The result is concrete. A typical section schema used to run 90 to 110 lines. With fragments composed from three or four reusable groups, I am at 50 to 60 lines, and the IDs are correct on the first try because I am not renaming anything. I built a small index file that lists every fragment with its setting IDs so I never guess.

If you want a wider reference on how sections and schema fit together, I keep notes in Shopify Liquid Sections. The schema is where most beginners lose an afternoon, and it is the easiest part to systematize.

One caution. Keep your fragment IDs short and stable. The moment you start naming things heading_2_new_final, the whole point collapses. Pick a naming rule on day one and never break it. Mine is simple: object name, then property, lowercase, underscores. That is the entire convention and it has held up across four themes.

Conditional Snippets Replace Twelve Near-Duplicate Blocks

The second pattern saved me the most raw lines. I used to have separate sections for things that were 90 percent identical: image-left, image-right, image-full. Three files. Three schemas. Three places to fix a bug.

Now I have one section and one snippet that takes parameters. The snippet handles the layout variation through a passed-in setting. I render it like this:

{% render 'media-block', layout: section.settings.layout, image: section.settings.image, heading: section.settings.heading %}

Inside the snippet, a single case statement on layout decides the markup. Image-left, image-right, image-full all live in one file. When I fix the alt-text handling or the lazy loading, I fix it once. That single change used to mean editing twelve blocks across the theme.

The render tag matters here over the old include. With render, the snippet only sees the variables I explicitly pass. No surprise leakage from parent scope. That isolation is what makes the snippet safe to reuse everywhere. I know its inputs and I know its outputs.

I count my snippet inputs the same way I count function arguments. If a snippet needs more than six, it is doing too much and I split it. My media block takes five: layout, image, heading, body, and a button group object. That is the ceiling.

The payoff is measurable. My old theme had 28 section files. The rebuild has 17, and it does more. Eleven sections collapsed into reusable snippets called with different parameters. Less code is less surface for bugs, and the editor loads faster because there are fewer files to parse.

I covered the broader philosophy of building small composable pieces in Claude Blueprint, which is how I plan any system before writing a line. The same logic applies to Liquid: define the smallest reusable unit, then compose up from there instead of copying down.

If you run a store and want a clean place to test these on, Shopify gives you a development theme you can break freely without touching the live one. I do all my snippet refactoring there first.

asset_url Helpers End The Broken Image Path Era

The third pattern is small but it killed an entire class of bug. Hardcoded asset paths. I used to write /assets/icon-cart.svg directly in markup, and it would work locally and break the moment the theme was on a CDN or in a different environment.

Now every asset goes through a filter, always. {{ 'icon-cart.svg' | asset_url }} for files, {{ 'icon-cart.svg' | asset_url | img_tag }} when I want a full tag. For stylesheets it is {{ 'section-hero.css' | asset_url | stylesheet_tag }}. The filter resolves the correct CDN path every time, so the same code works in every environment.

I went one step further and built a tiny icon snippet. It takes a name and returns the inline SVG or a referenced one with the proper URL. I render {% render 'icon', name: 'cart' %} and never think about the path again. When I added a new icon set, I dropped the files in assets and added cases to the snippet. No markup anywhere else changed.

The same discipline applies to images uploaded through settings. I always pipe them through image_url with an explicit width, like {{ section.settings.image | image_url: width: 1200 }}, then let image_tag handle the responsive srcset. Hardcoding a width of the original upload meant shipping a 4000 pixel hero image to a phone. Now every image is sized to its container and the page weight dropped noticeably.

I will not pretend the path filters are exciting. They are plumbing. But plumbing that I never touch again is exactly what cuts build time, because the time you save is the time you do not spend debugging something that should have worked the first time.

For the heavy image work that feeds these themes, I generate and upscale source art in Magnific before it ever reaches Shopify, so the assets going through these filters are already at the resolution I want. Clean inputs, clean filters, no surprises in production. That whole chain, from generated art to filtered output, is what keeps the asset layer boring in the best way.

Settings Inheritance And content_for_index Hooks

The last two patterns are what make a theme feel composed rather than assembled.

Settings inheritance means I define defaults once in settings_schema.json and read them anywhere with {{ settings.brand_color }}. Section-level settings only exist when a section truly needs to override the global value. My old themes had a color picker on every single section, which meant changing the brand color was 28 edits. Now it is one. Sections fall back to the global setting unless explicitly told otherwise.

The pattern in Liquid is a default filter. {{ section.settings.button_color | default: settings.brand_color }}. If the merchant set a section override, it wins. If not, the global brand color flows down. The whole theme stays consistent for free, and merchants can still override one section when they want to.

The second pattern is content_for_index hooks, the engine behind dynamic sections on the homepage. Instead of hardcoding a fixed homepage layout, the index template just calls {{ content_for_index }} and merchants drag sections in the editor. I used to hand-build homepages. Now I build sections that work anywhere and let the merchant compose the page.

The trick that saved time was making every section index-safe from the start. That means no assumptions about position, no hardcoded references to other sections, and a sensible default when a setting is empty. Each section is a self-contained block that renders correctly whether it is first, last, or duplicated three times. I write a quick checklist for each: does it work alone, does it work duplicated, does it work with no image set. Three checks, every section, no exceptions.

When a section passes those three, it goes anywhere on the site with zero rework. That portability is the real time saver, because a section I build for the homepage also works on a landing page or a collection page untouched.

When the theme is done, I schedule the launch posts through Buffer so the build and the announcement run on the same calendar. The development discipline and the publishing discipline are the same idea: define the reusable unit once, then reuse it.

Bottom Line

These five patterns are not clever. Schema fragments, parameterized snippets, asset filters, settings inheritance, and index-safe sections are all boring on their own. Stacked together they changed how I work. I stopped copying and started composing. The build that used to mean editing a dozen near-identical files now means writing one snippet and calling it with different parameters.

The numbers held up across the full rebuild: 28 sections became 17, schema files dropped from 100 lines to 55, and the bugs I used to chase (broken paths, mismatched IDs, inconsistent colors) mostly stopped happening because the patterns made them impossible.

If you are starting a theme, pick one pattern and apply it everywhere before adding the next. Inconsistency is what kills these. Half-applied conventions are worse than none.

For the planning side of any build like this, I lean on Claude Blueprint, which is where I map the reusable units before I write Liquid. And for the section reference itself, Shopify Liquid Sections covers the structure underneath all of this. Build the parts once. Compose forever.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)