DEV Community: hb lai

Where indie web tools actually get their backlinks (it isn't the directories)

hb lai — Sun, 09 Aug 2026 07:30:58 +0000

Every "launch your side project" checklist has the same list on it. Product Hunt. AlternativeTo. BetaList. There's An AI For That. Toolify. Futurepedia. G2 if you're feeling corporate.

I run a small free photo-filter tool. Before spending a weekend submitting to all of them, I did something I should have done first: I pulled the backlink profiles of the competitors who are beating me, and looked at where their links actually come from.

Not one of those directories showed up. Not one.

Here's what I found instead, and how I checked it.

The setup

Four domains, all in the same niche (browser-based retro/glitch photo effects):

site	total backlinks	what I sampled
competitor A (direct rival)	417	333 (80%)
competitor B (much bigger, older)	~13,000	top 356 follow links by page authority
competitor C (new, same idea)	57	46
my own site	38	36

I pulled these from Semrush's backlink report, paginating the table and scraping each row into a flat list: source URL, page authority, follow/nofollow, first seen. Then I grouped by domain and sorted.

Sampling caveat up front, because it matters for how much you should trust this: for competitor B I only looked at 356 of its ~7,100 follow links, about 5%. That's not a random 5%. It's the highest-authority 5%. Directory listings tend to be high-authority pages, so if they existed I'd expect them near the top. Their absence there is meaningful, but it's an inference, not a census. For competitor A I have 80% of the profile, which is solid.

What was actually there

I grepped both profiles for every directory name from the standard checklist: altern, producthunt, saashub, toolify, futurepedia, theresanaiforthat, betalist, slant, capterra, g2., stackshare.

Zero hits.

What I got instead, dominating everything:

204 links from 185 different personal websites, nearly all dofollow. Mostly Neocities and Nekoweb sites: the free-static-hosting corner of the web where people still hand-write HTML and keep a page called /links or /resources or /cool-sites.

One single Neocities site linked competitor B 168 times (it's a big personal directory, one link per tool it catalogues).

The striking part: those 185 sites barely overlap. Exactly one of them turned up in more than one competitor's profile. These aren't a network. They're 185 individual people who each found a tool and added it to their own list.

There's a second tier that's smaller but real: Substack newsletters doing "18 free tools for X" roundups, niche wikis, a couple of .edu pages where a lecturer keeps a digital-art tool list, and, in competitor B's case, a cluster of Chinese design-navigation sites that accept submissions.

The part I got wrong before I looked

My assumption was that "free web tool" is a category that lives in tool directories. For SaaS, maybe. For a thing you use once in a browser and never sign up for, the people who link to you are the people who collect things like that. And the people who collect things like that, in this niche, keep personal homepages.

That's not a growth hack. It's just: your links come from wherever your actual audience hangs out, and that's a different place for every niche. The generic checklist encodes someone else's niche.

A warning about the noise

Something else fell out of the data that's worth flagging if you ever run this check.

Competitor A's profile contains 122 links from a network of near-identical junk domains: beer-brand names, .xyz TLDs, all serving the same template. That's a third of the 333 links I pulled. My own tiny profile has the same shape: of 38 backlinks, 36 are auto-generated "Boost your Google rankings!" scraper pages that also point at everyone else in the niche.

I want to be careful here, because it's easy to read that as an accusation. You cannot tell from a backlink report who put a link there. Nobody asks permission to link to you. Scraper networks and spam farms hoover up domains and link at them automatically; showing up in one says approximately nothing about the site being linked. I'd assume mine arrived exactly the way theirs did. By robot.

The practical takeaway is just: when you read a profile, filter the junk before you count anything. Competitor A looks like a 417-link site. Strip the template spam out of what I sampled and roughly 210 links are left. And don't panic-disavow. A handful of obvious template spam is noise every site accumulates.

What I'm doing with this

Two things.

First, I stopped planning the directory sprint. Not because directories are bad, but because in this niche the evidence says they pay nothing.

Second, I made an actual site in that community: a small hand-written page about why old digital camera photos look the way they do, with the slider values I use, hosted on Nekoweb like everyone else there. Not a landing page. That crowd can smell a landing page from orbit.

And I made an 88×31 button, because that turns out to be the actual unit of exchange. That's how those 185 links happened: someone put your button on their links page. There's no form. There's no submission. You make a thing, you make a button, and you participate.

If you want to run this on your own niche

Pick 2–3 competitors who are genuinely ahead of you, not aspirational giants. Their links should be links you could plausibly also get.
Pull the backlink profile and export or scrape the whole table, not the summary.
Filter out the spam networks first. Look for many near-identical domains sharing a URL path pattern.
Group by registrable domain, but keep subdomains separate if the host is a platform (every Neocities user is a subdomain; collapsing them would have hidden this entire finding).
Ignore the totals. Read the shape. Ask "who is this person and why did they link this," and the pattern shows up fast.

The answer for me was "people who keep link pages." It'll be something else for you. But it's a couple of hours of scraping to find out, and it's cheaper than a weekend of directory submissions that go nowhere.

I build digicamfilter.online, a free in-browser retro photo filter. It runs as a WebGL shader in your own tab, so nothing gets uploaded anywhere. The community site from this post is dead pixels club.

MARVEL Tōkon: Fighting Souls — a fan database that admits what it doesn't know

hb lai — Sun, 09 Aug 2026 07:03:35 +0000

Most coverage of a brand-new fighting game falls into two piles: aggregators that paywall the basics, and blogs that state guesses as fact. When MARVEL Tōkon: Fighting Souls launched, I wanted the opposite, so I built one.

The idea is simple: document every launch fighter, all 169 recorded moves, the five teams and every stage, and put a source on each page. Where a fact hasn't been published, the page says so instead of inventing a number. There's still no public frame data for this game, so any site handing you startup and recovery values right now is making them up. This one leaves the column empty and says why.

The same honesty rule covers the questions everyone asks first. Take crossplay: PS5 and PC matchmaking is confirmed, but cross-progression isn't, and the page keeps those two apart instead of blurring them into one confident-sounding answer.

Two things on the site are tools, not documentation. The 4v4 team builder drafts a point character and three assists from the whole roster, then hands you a link that rebuilds the exact squad — paste it into Discord and your teammate sees the same team. The tier-list maker lets you rank the roster into S through D and share that too; the opinion is yours, because a real tier list needs match data nobody has yet.

The one piece of genuine data the site has is the open beta. A snapshot of the Vibranium+ leaderboard, taken just before the servers closed, shows which fighters high-rank players actually picked — split by whether they were fielded as the point character or as an assist. Magik led on raw picks, but most were as an assist; Blade was the most-called assist. That split is the closest thing to hard data before the retail meta settles, and this breakdown is the only place that transcribed the numbers rather than the ordering.

No official art, no account, no paywall.

Twelve retro photo effects in one WebGL fragment shader (and why the photo never leaves the browser)

hb lai — Tue, 04 Aug 2026 16:02:03 +0000

Every "make my photo look like film" tool I looked at wanted me to upload the photo first. That is a server bill, a privacy promise I would have to keep, and a round trip before the user sees anything.

None of it is necessary. Grain, bloom, chromatic aberration, color grading: these are per-pixel math. The GPU in the phone that took the photo can do all of it, in real time, while the file stays in memory.

Here is how the shader is built, including several things I got wrong and had to correct.

The setup: one pass

No framebuffer ping-pong, no multi-pass pipeline. One fragment shader with twelve effect uniforms, each mapped to a slider, plus the image, resolution, and time:

uniform sampler2D u_image;
uniform vec2 u_resolution;
uniform float u_grain;
uniform float u_softness;
uniform float u_contrast;
// ... u_saturation, u_warmth, u_tint, u_highlights,
//     u_shadows, u_vignette, u_aberration, u_fade, u_bloom
uniform float u_time;

Worth being precise about what "single pass" means here: the texture-sampling effects (aberration, softness, bloom) all read from u_image, the original. Everything after that is arithmetic on an accumulated color variable, applied in sequence. So it is not "every effect reads the original" and it is not a clean chain either. It is both, split at the point where sampling stops.

Chromatic aberration: displace radially

The first version shifted the red and blue channels by a fixed pixel offset. It looked like a 3D movie poster.

For the lateral fringing a real lens produces, the offset needs to grow with distance from the image center and point outward. Center stays corrected, corners get the color separation:

float aberrationAmount = u_aberration * 0.003;
vec2 center = uv - 0.5;
float dist = length(center);
vec2 dir = normalize(center);

float r = texture2D(u_image, uv + dir * dist * aberrationAmount).r;
float g = texture2D(u_image, uv).g;
float b = texture2D(u_image, uv - dir * dist * aberrationAmount).b;
color = vec3(r, g, b);

Green is the unshifted reference. Note the direction carefully, because it is the opposite of what it looks like: sampling red at uv + offset pulls in red from further out, so red features end up displaced inward, and blue outward.

One cleanup I have not shipped yet: normalize(center) is undefined exactly at the center pixel. Since dir * dist is just center, the safe equivalent is vec2 offset = center * aberrationAmount;.

This models lateral chromatic aberration specifically. Longitudinal CA is a different phenomenon, and a fixed offset is still a perfectly good stylistic choice if that is the look you want.

Bloom: gate on luminance, ramp on the excess

Bloom is what makes an image read as "old sensor." Bright areas bleed outward instead of clipping flat. Blurring the whole frame and mixing it back just produces mud.

Gate it on luminance instead, and let the mix strength grow with how far past the threshold a pixel sits:

vec3 blurred = blur(u_image, uv, u_bloom * 5.0);
float luminance = dot(blurred, vec3(0.299, 0.587, 0.114));
if (luminance > 0.5) {
  color = mix(color, blurred, u_bloom * 0.4 * (luminance - 0.5) * 2.0);
}

Two details worth stealing.

The luminance comes from blurred, the softened sampling of the original, not from the sharp pixel. That is what lets the glow spread past the actual edge of a highlight. Measure luminance on the sharp image and the glow stops dead at the boundary.

(luminance - 0.5) * 2.0 remaps 0.5..1.0 back to 0..1, so a pixel barely over the threshold gets almost nothing and a blown-out one gets the maximum. There is still a hard branch at 0.5, but the weight rises continuously from zero, so no visible seam.

Grain: hash noise, animated by time

A widely circulated sine-dot pseudo-random hash, plus u_time so the pattern changes per frame instead of freezing into a static overlay:

float hash(vec2 p) {
  return fract(sin(dot(p, vec2(127.1, 311.7))) * 43758.5453);
}

float grain(vec2 uv, float intensity) {
  float noise = hash(uv * u_resolution + u_time);
  return (noise - 0.5) * intensity;
}

Multiplying uv by u_resolution before hashing is the part people miss. It makes the noise vary at roughly one sample per output pixel. Hash the raw normalized UV instead and the pattern's feature count stays tied to normalized coordinates, so its apparent size in pixels changes with the output resolution: enormous blobs on a large canvas, fine dust on a small one.

Saturation: HSL because the control is legible

The cheap alternative, which this shader does not use, is to lerp away from luminance:

// not repo code, shown for contrast
color = mix(vec3(lum), color, 1.0 + u_saturation);

I originally wanted to claim this method drags hues toward the primaries. That is not right: scaling RGB distance from neutral gray preserves RGB hue right up until values clip.

The actual reason I went with an HSL round trip is more boring: saturation is an explicit component, so the slider maps to one number and the code says what it does.

vec3 hsl = rgb2hsl(color);
hsl.y *= (1.0 + u_saturation);
color = hsl2rgb(hsl);

Neither approach guarantees perceptually exact hue once out-of-gamut values get clamped, and this shader does not clamp hsl.y before converting back. On a single full-screen pass the round trip has not been a bottleneck on anything I have tested, including a five-year-old midrange Android.

Fade: just add a constant

The washed, lifted-blacks look of old prints is the least sophisticated line in the shader:

color = mix(color, color + vec3(0.08), u_fade);

Raise the floor so nothing is truly black. I spent an embarrassing amount of time on tone curves before landing here. It reads correctly because lifted blacks are exactly what faded prints and cheap film scans do.

Order

The sequence runs optical, then tonal, then color, then texture:

Chromatic aberration
Softness
Bloom
Contrast, highlights, shadows
Warmth, tint, saturation
Fade, vignette
Grain
Clamp

The useful property is that vignette and grain land on the final graded color rather than being pushed through the color stage. Move grain before softness and the softness mix attenuates it. It would not get convolved away, since blur() always samples u_image and never the accumulated color, which is a subtlety of the single-pass design that took me a re-read of my own shader to state correctly.

The export bug that cost me an afternoon

Everything looked right on screen. canvas.toDataURL() returned blank.

WebGL is allowed to discard the drawing buffer after compositing. If you serialize synchronously right after drawing you can get away with it, but an editor that exports on a button click, some frames later, will not. The options are to rerender immediately before export, render into an offscreen framebuffer, or ask the context to keep the buffer around:

const gl = canvas.getContext('webgl', {
  preserveDrawingBuffer: true,
  premultipliedAlpha: false,
});

I took the third. There is a cost, but for an editor that renders on slider input rather than in a 60fps loop it is invisible. Context attributes cannot be changed after creation, so this has to be decided up front.

What the blur actually is

Calling this a "5x5 box blur" undersells how approximate it is:

for (float x = -2.0; x <= 2.0; x += 1.0) {
  for (float y = -2.0; y <= 2.0; y += 1.0) {
    vec2 offset = vec2(x, y) * texelSize * radius;
    result += texture2D(tex, uv + offset).rgb;
    total += 1.0;
  }
}
return result / total;

25 equally weighted samples on a 5x5 grid, but the spacing scales with radius. At maximum softness the taps sit 3 pixels apart and span 13 pixels; at maximum bloom, 5 apart spanning 21. That is a sparse box-style approximation, not a contiguous convolution and definitely not a gaussian. A separable or downsampled blur would cover the same radius with better quality per sample, and if you are doing anything precision-sensitive you should use one.

For glow and softness at these radii I have not found it worth the extra complexity. That is a judgment call, not a benchmark.

Where it runs

The pipeline runs on the user's device. No upload, no server-side image processing cost, and the photo is never transmitted or persisted. (Analytics and the rest of the site still need their own disclosure; local processing is not a blanket exemption from writing a privacy policy.)

JPG, PNG, and WebP go through the same path everywhere. HEIC works only where the browser decodes it natively, since there is no bundled decoder. There is a Canvas 2D fallback for contexts where WebGL is unavailable, but it is honestly a reduced one: contrast, warmth, saturation, fade, grain, and vignette only. Softness, bloom, aberration, tint, highlights, and shadows are WebGL-only.

If you want to see the output, the tool is at digicamfilter.online (free, no signup). Each look documents its exact twelve slider values, so you can read the numbers off and reproduce any of it in your own shader.

The bloom luminance-from-blurred trick and the grain resolution scaling are the two I would prioritize if you are building something similar. Happy to answer questions on any of it.

Building a 100-question Rice Purity Test with Next.js: persona theming + a canvas share card

hb lai — Tue, 23 Jun 2026 16:48:48 +0000

I shipped a small side project last week, a Rice Purity Test, and a couple of the build details turned out more interesting than the quiz itself. Two in particular: making the result screen recolor itself based on your score, and exporting a share card to PNG entirely in the browser. Notes below in case they save someone an hour.

The setup

It's a Next.js 16 app on the App Router, deployed to Cloudflare Workers via OpenNext. The quiz is one client component (an "island") sitting inside otherwise static, server-rendered pages, so the SEO content stays fast and only the interactive part hydrates. 100 checkbox questions; your score is 100 minus whatever you tick.

Persona-adaptive theming

This was the fun part. Instead of one result screen, the page picks a colour identity from your score band and drives everything off a single CSS custom property.

:root { --persona: var(--sage); }      /* high score, reserved */
[data-band="wild"] { --persona: var(--crimson); }  /* low score */

The result component sets a data-band attribute plus the accent colour, and the card background, the borders, even the shadow tint all follow from --persona. No conditional class soup. Ten bands, one variable.

const band = bandForScore(score);   // 0..9
return <section data-band={band.key} style={{ "--persona": band.color }}>...</section>;

Setting a CSS var inline in React like that is underused. You compute a theme value in JS and hand it straight to plain CSS, no styled-components, no re-render storm.

Exporting the share card as a PNG

People want to post their score, so the card has to become an image. I used html-to-image and dynamic-imported it so it never touches the initial bundle:

async function savePng(node) {
  await document.fonts.ready;                 // gotcha #1
  const { toPng } = await import("html-to-image");
  const url = await toPng(node, { pixelRatio: 2, cacheBust: true });  // gotcha #2
  const a = document.createElement("a");
  a.href = url; a.download = "rice-purity-score.png"; a.click();
}

Two things ate that hour. Web fonts must be fully loaded before you rasterize or the card renders in a fallback font, hence await document.fonts.ready. And the default export looks soft on retina, so pixelRatio: 2.

i18n without moving indexed URLs

I added five languages after launch. English stays at the root (unprefixed) so nothing already indexed moves; other locales get a prefix (/es, /pt, and so on). One dictionary file per locale, all matching the same TypeScript Dict shape, and the client quiz reads the dict as plain serializable data. hreflang and canonical both generate from a single LOCALES array, so adding a language is basically: write the dict, append the code, deploy.

If you want to poke at the finished thing, it's live at ricepuritytest.art, and the score-meaning breakdown is where those band colours come from. Happy to get into any of the build details in the comments.

Building a paint-to-hide browser minigame with Next.js and SVG

hb lai — Tue, 16 Jun 2026 03:58:42 +0000

There's a PC party game called Meccha Chameleon where hiders paint their body to match a wall or a crate and freeze, while seekers try to spot them. I got a bit obsessed with the camouflage idea and built two small things around it.

The first is a camo "lab": pick a surface and it hands you the exact colours, a pattern, and a pose. Under the hood it's one inline SVG chameleon whose fills are driven by a per-surface palette. Recolouring an inline SVG with a few variables turned out far simpler than generating images, and each surface is a tiny data object (three hex colours, a pattern, a blend score), so adding one is a one-line change.

The second is an actual playable minigame: a grid of tiles, a few of them hiding a chameleon painted to match its tile, and you tap to find them before the timer runs out. It's all React state, no canvas and no engine, which kept it tiny and instant to load.

It runs as a Next.js app on Cloudflare Workers via OpenNext, a nice combo for a mostly-static site with a couple of client tools: static pages cache at the edge while the interactive bits hydrate on the client.

If you want to poke at it, the Camo Lab is here and the browser game is here. Happy to answer anything about the SVG recolour or the OpenNext setup.

I built a free toolbox for Threads (no login, no watermark)

hb lai — Mon, 08 Jun 2026 03:04:41 +0000

I post on Threads a fair bit, and I kept hitting the same small walls: no way to save a video, no clean screenshot, and reposting from X meant retyping everything. The sites that promised to help were buried in ads or wanted a login for a five-second job.

So I built ThreadsTools, a set of small, single-purpose tools for Threads. Free, no login, no watermark.

What's in it

Download the video, photos, GIF, or audio from any public Threads post
A Threads to MP3 converter that pulls just the audio
A screenshot maker, plus quote-card and mockup generators
Converters that turn an X tweet or a LinkedIn post into a Threads draft

A couple of build notes

The media downloads stream straight from the CDN to the browser, because Meta's CDN blocks server-side fetches anyway. The MP4-to-GIF and MP4-to-MP3 conversions run client-side with ffmpeg.wasm, so nothing gets uploaded. The whole thing runs on Cloudflare Workers, mostly because there are no egress fees, which is what makes a free downloader that streams video affordable to run.

Code and notes: https://github.com/Nora4844/threadstools

Full set of tools: threadstools.app/tools

The 'bad photo' look is back — here's the engineering behind it

hb lai — Sat, 06 Jun 2026 16:46:56 +0000

Every few years a visual style comes back, but this one is funny: it's literally old engineering bugs becoming features. The "2000s digicam" / CCD / disposable-camera look that's everywhere right now is just a stack of old hardware limitations — and you can recreate every one of them in code.

Here's what actually made those photos look "wrong," and how each maps to something you can fake today.

1. Tiny sensors → noise

Early compacts and phone cameras had minuscule sensors. Less light per pixel means more noise — that fine speckled grain in the shadows. Engineers spent ~15 years killing it with bigger sensors and computational denoising. To fake it: add per-pixel luminance noise, weighted toward the shadows.

2. Aggressive compression → blocky softness

Storage was tiny and expensive, so cameras compressed hard. Low-quality JPEG smears fine detail and leaves 8×8 block artifacts. Re-encoding at low quality (or simulating DCT block quantization) gives you that soft, slightly-mushy texture.

3. On-board flash → the flat night look

A bright bulb right next to the lens gives flat, head-on lighting: bright faces, hard shadows, a background that falls to black. Approximate it with a radial highlight near the subject and a steep falloff.

4. Narrow dynamic range → clipped highlights

Old sensors couldn't hold bright and dark at once, so skies blew to white and shadows crushed to black. A tone curve that clips both ends reproduces it.

5. CCD color science → the cool cast

CCD sensors leaned cool, sometimes slightly green. A small channel-mixer / white-balance shift toward cyan-green nails the "CCD" feeling people are nostalgic for.

The fun part: do all five at once and you don't get "a filter" — you get a photo that looks like it remembers something. It reads as a real moment instead of a product shot.

I've been poking at a free in-browser version that does these as one-click presets (iPhone 4, CCD, disposable, Y2K). Everything runs locally on a canvas, nothing uploads: digicamfilter.online. Useful for seeing each effect in isolation before wiring up your own.

Anyway — half of "retro" aesthetics are just old constraints we worked hard to remove, switched back on by choice. Kind of poetic.