DEV Community: Pushpendra Yadav

TanStack Redact: Ship Less React Without Touching Your React Code

Pushpendra Yadav — Fri, 30 Oct 2026 15:07:25 +0000

I've been doing frontend for about twelve years, and a big part of that has been fighting bundle size. Code splitting. Lazy routes. Swapping heavy date libraries for lighter ones. Hunting down that one dependency that pulls in all of lodash. A Webpack 4 to 5 migration done with codemods because doing it by hand across a big codebase wasn't realistic.

But there was always one chunk of the bundle nobody touched: React and React DOM themselves. You just accepted that cost. It was the floor.

TanStack Redact just lowered the floor. And the reason I think it matters isn't the clever engineering behind it (though there's plenty of that). It's how useful it is on day one.

What Redact actually is

Redact is a smaller, React-compatible runtime for the browser. You add one plugin to your build config, and your existing React imports, components, hooks and third-party libraries run on Redact in the browser instead of React DOM.

That's the whole pitch. No new API to learn. No import { h } from 'somewhere-else'. No rewriting components. Your app code stays exactly the same.

It started as Tanner Linsley's experiment on his personal site and tanstack.com, where it's been running in production since April 2026. It stuck, other people started using it in production too, and on October 26 it shipped as 0.2.0 with stable integrations for TanStack Start, Vite, Vinext and Next.js (both App Router and Pages Router).

The usefulness is the headline

Most performance wins come with a migration cost. Move to a new framework, adopt a new rendering model, rewrite your state layer, retrain the team. The win is real, but you pay for it in weeks.

Redact flips that. Here's a plain Vite + React app:

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { redact } from '@tanstack/redact/vite'

export default defineConfig({
  plugins: [react(), redact()],
})

And TanStack Start:

// vite.config.ts
import { defineConfig } from 'vite'
import { tanstackStart } from '@tanstack/react-start/plugin/vite'
import react from '@vitejs/plugin-react'
import { redact } from '@tanstack/redact/vite'

export default defineConfig({
  ssr: { noExternal: true },
  plugins: [tanstackStart(), react(), redact()],
})

For Next.js there's a withRedact wrapper from @tanstack/redact/next (the docs have the exact setup).

That's it. Install, add a line, build, measure.

Think about what this means in a real team:

No refactor PR. Your diff is a config file and a package.json line. Easy to review, easy to reason about.
Rollback is trivial. Remove the plugin and you're back on React. That makes it a low-risk experiment instead of a bet-the-quarter decision.
Your ecosystem comes with you. Component libraries, form libraries, query libraries — they keep importing react and just get Redact in the browser.
Nobody has to learn anything. New hires still write React. Your docs, your Storybook, your patterns all stay valid.

I've led teams where the right performance move was blocked purely because it meant touching hundreds of components. A tool that gives you the win without that cost is the kind of thing that actually gets adopted.

The numbers

The TanStack team built the same small app with React and with Redact in each framework, then added up the gzip size of all emitted client JS and CSS:

Framework	React	Redact	Saved
TanStack Start	109.3 KB	62.3 KB	47.0 KB (43.0%)
Vite	68.3 KB	20.1 KB	48.1 KB (70.5%)
Vinext	138.1 KB	98.8 KB	39.3 KB (28.5%)
Next.js	175.6 KB	139.9 KB	35.7 KB (20.4%)

Those are the default builds. If you turn off optional features your app doesn't use, Start drops to 59.8 KB and a client-only Vite app goes down to 12.6 KB.

The team is upfront that these are whole-build totals for a small sample app, so your percentages will vary. The benchmark source is public if you want to reproduce it. I appreciate that honesty — it's rare in launch posts.

Why do 35–48 KB of gzip matter? Because that's JavaScript every user downloads, parses and executes before your app becomes interactive. On a fast laptop on fiber, sure, you won't notice. On a mid-range Android phone on a patchy mobile connection — which is a huge share of real users in markets like India — that's a noticeable chunk of your load budget, and it's coming out of the one dependency you thought you couldn't shrink.

It's not a toy React

My first worry with any "React but smaller" project is: what breaks? A counter demo working proves nothing. Real apps lean on hydration, Suspense, transitions, forms, error boundaries, and a pile of framework internals.

Redact supports JSX, hooks, context, refs, memo, lazy, portals, error boundaries, streaming SSR and hydration. Pending transitions, form actions and optimistic state are covered too.

What gave me more confidence is how they test it. The compatibility suite runs real browser journeys in Chromium, Firefox and WebKit: retained layouts, back/forward navigation, redirects, canceled navigation, Server Actions, pending forms, optimistic updates, uploads, streamed Suspense, and Fast Refresh that keeps state across edits. That's the stuff that actually breaks in production.

And you don't lose your tooling: React DevTools still works for inspection, editing and commit profiling in development.

Server Components stay with React

This is a really smart design call. With Next.js and Vinext, Redact doesn't try to replace everything. React still does server rendering and Server Components. The framework still owns routing, caching and Server Action transport. Redact picks up in the browser, hydrates the HTML, and runs your client components.

So you're not swapping out your framework's server story. You're only swapping the part that ships to your users' devices. That keeps the blast radius small, and it's exactly where the bytes matter.

Go smaller if you want to

For Start and Vite you can tune what's included:

// Start: keep hydration and router features, drop what you don't use
redact({
  features: {
    activity: false,
    fragmentRefs: false,
    portal: false,
  },
})

// Vite: a client-only app with no optional features
redact({ preset: 'nano' })

The default is a sensible "full" preset, and the docs recommend starting there and only disabling features after checking what your app (and its dependencies) actually use. Next.js and Vinext use the full runtime so framework features keep working.

"Why not just use Preact?"

Fair question, and the Redact team answers it directly: Preact is smaller. But Redact keeps more of the modern React behavior your app may depend on, like pending transitions, deferred results and form actions. If you're on a modern React stack and you don't want to discover compatibility gaps one bug report at a time, that matters more than the last few kilobytes.

The honest tradeoff

Redact renders synchronously. No time slicing, no interruptible renders. Suspended transitions, pending forms and optimistic state still work, but a genuinely heavy render can block input while it runs.

For a lot of apps, that's fine. Marketing and content sites, docs, ecommerce storefronts, typical CRUD dashboards, embedded widgets — most of their renders are small, and the bundle savings are pure win.

Where I'd be careful: screens that render huge trees in one go, or code that relies on useTransition to keep typing responsive during an expensive update. The TanStack team says the same thing: try it against your busiest screens first. Their compatibility guide spells out the boundaries clearly.

That's not a knock on Redact. It's a clear, documented choice, and it's the reason the runtime can be this small.

Why I'm a fan

What I like most is the attitude behind it. This isn't "React is bad, switch to X." Tanner is explicit that he still believes in React and wants it to keep growing. Redact is just another runtime option inside the React ecosystem for people who want to keep their components and ship less.

That's the kind of tool I want more of: respects the code you already have, gives you a real win, tells you the tradeoff upfront, and lets you walk back with one line if it doesn't fit.

If you have a React app on Vite, TanStack Start or Next.js, the cheapest experiment you'll run this month is:

pnpm add @tanstack/redact
Add redact() (or withRedact) to your config
Build, compare your bundle, click through your heaviest screens

Worst case you learn something about your app. Best case you delete tens of kilobytes from every page load without changing a single component.

Links

Launch post: https://tanstack.com/blog/introducing-tanstack-redact
Docs: https://tanstack.com/redact/latest
Compatibility guide: https://tanstack.com/redact/latest/docs/compatibility
GitHub: https://github.com/TanStack/redact

Google's crawler ran up my AI bill

Pushpendra Yadav — Tue, 27 Oct 2026 19:19:04 +0000

Because I liked asks what you loved and why, then finds films, shows, books and games that match the why. Part 1 was how it works; part 2 was measuring it.

This one is about money. Last week Anthropic charged my card $10, then $10 again, on days when almost nobody was using the site. My analytics showed a handful of searches. My model bill showed thousands.

Daily Haiku cost had been cents to about $2 a day. Then ~$7 on Oct 22 and ~$14 on Oct 23: two-thirds of the month's $34 in two days. Nobody had come. Something had.

The short version: the URLs that cost money were my own fault, and four of the five fixes only half worked.

🧾 How a search URL costs money

A search on the site is a few calls to Claude Haiku: one to understand the query (what medium, what era, what the person actually loved), one to write a line on why each top pick fits, one for picks in other media. Results are cached, so a search someone already ran is free. A new search is not.

Every title page also has "why chips": one-tap reasons like "shows like Breaking Bad: a decent man slowly turning bad". They were plain links:

<a href="/?q=shows+like+breaking+bad%3A+a+decent+man+slowly+turning+bad">

Now do the maths. About 13,850 title pages, several chips each, every chip a distinct search URL that nobody had run yet. I had built tens of thousands of uncached, paid, crawlable links, and listed every title page in my sitemap so crawlers would find them faster.

Crawlers did exactly what crawlers do. Each link they followed was a few Haiku calls.

🕷️ Fix 1: robots.txt is a request, not a wall

Google Search Console's crawl stats showed Googlebot fetching search URLs by the thousand. My search pages already carried noindex, and that doesn't help here: Google has to fetch the page to see the noindex, and the fetch is the part that costs money.

So search URLs went into robots.txt:

// src/app/robots.ts
disallow: [
  // Each new search is a few uncached Haiku calls, and the title pages'
  // why chips link to tens of thousands of them. They carry noindex
  // anyway, so nothing is lost in search.
  '/*?q=',
  // ...
],

Googlebot respects it. The bill didn't go to zero, because not everything that crawls is Googlebot.

🧱 Fix 2: firewalls stop the honest bots

What was left came in two kinds: a crawler on AWS IP addresses, and later something on rotating home IPs that ignored robots.txt entirely.

I added Vercel firewall rules (by user agent, and by AS number for the AWS traffic), then turned on Bot Protection, which challenges anything that doesn't behave like a browser. Each step cut the traffic. None got it to zero.

That's the limit of identifying bots by what they are. A scraper on rotating home IPs looks exactly like your users, because it's using the same kind of connection your users have.

(I also decided not to block bots in general. Search engines bring visitors, and link previews on X, Slack and WhatsApp come from bots too. Your /api/og route has to stay reachable or every shared link turns into a bare URL.)

🧯 Fix 3: a cost ceiling has to fail closed

Next, a ceiling: a site-wide daily cap on search-path model calls, counted in Redis.

// src/lib/daily-cap.ts
export async function takeSearchCall(): Promise<void> {
  if (!redis) return
  const key = `cap:search-llm:${new Date().toISOString().slice(0, 10)}`
  let used: number
  try {
    used = await Promise.race([
      redis.incr(key),
      new Promise<never>((_, reject) => setTimeout(() => reject(new Error('timeout')), 1_000)),
    ])
    if (used === 1) void redis.expire(key, 60 * 60 * 48)
  } catch (err) {
    throw new DailyCapReached('counter unavailable')
  }
  if (used > DAILY_CALLS) throw new DailyCapReached('cap reached')
}

Every model call on the search path takes from this allowance first. When it throws, the caller falls back: plain text search instead of understood search, posters without the "why it fits" line.

The interesting decision is in the catch. My per-IP rate limiter fails open: if Redis is down, let people search, because a broken rate limiter shouldn't take the site down. The cap fails closed: if the counter can't be read, skip the model call. A cost ceiling that disappears whenever Redis has a bad day isn't a ceiling.

And then Redis had a bad day. On launch day, my Upstash free tier hit its monthly command limit. Part of the reason was my own debugging: I'd scanned tens of thousands of cache keys while investigating all this. The cap did exactly what I designed it to do. It failed closed, and every search quietly fell back to plain text matching. Someone searched for something like The Sixth Sense and The Sixth Sense wasn't in the results.

Two lessons in one:

Fail closed is right for a cost ceiling, but it's only safe if you watch it. A fallback that's quiet enough to be a good user experience is also quiet enough to miss.
A cap can't tell a person from a bot. On a heavy scraper day, the bots spend the budget and the real users get the fallback. The cap limits the damage. It doesn't fix the cause.

🎟️ Fix 4: spend only on a person's action

The fix that actually worked came from changing the question. Not "who is this request from?", which I'd already lost, but "did a person just do something?"

A request may ask the model for something new only if:

it's from a signed-in user (an account is a person), or
it carries a valid search pass.

Otherwise the page is cache-only: anything already written is shown in full, and nothing new is asked of the model.

// src/lib/search-pass.ts
export async function modelCallsAllowed(signedIn: boolean): Promise<boolean> {
  if ((await headers()).get('next-router-prefetch')) return false
  if (signedIn) return true
  return validPass((await cookies()).get(PASS_COOKIE)?.value)
}

Router prefetches never spend money, pass or not. Next.js prefetches links in view, and a prefetch isn't a person.

The pass is a cookie: an expiry time and an HMAC signature over it, HttpOnly, valid for 30 minutes.

export function newPass(): string | null {
  const key = passKey()
  if (!key) return null
  const exp = String(Math.floor(Date.now() / 1000) + PASS_SECONDS)
  return `${exp}.${sign(key, exp)}`
}

export function validPass(value: string | undefined): boolean {
  const key = passKey()
  if (!key || !value) return false
  const [exp, sig] = value.split('.')
  if (!exp || !sig || !/^\d+$/.test(exp) || Number(exp) < Date.now() / 1000) return false
  const want = Buffer.from(sign(key, exp))
  const got = Buffer.from(sig)
  return want.length === got.length && timingSafeEqual(want, got)
}

No database, no session table. The signature means a client can't forge a pass or extend its expiry. timingSafeEqual means it can't guess one byte by byte either.

Only a Server Action sets the cookie, and the page calls it only on a person's action: submitting the search box, tapping a why chip, or the first tap or key press of a visit. The chips stopped being links:

<button
  type="button"
  onClick={() =>
    startTransition(async () => {
      await ensureSearchPass()
      router.push(href)
    })
  }
>

To a person, nothing changed: tap a chip, get a search. To anything that only follows links, the searches no longer exist.

A bot that loads a search URL directly now gets a "Ready when you are" page with a Show picks button, and it costs nothing. Searches that are already cached still render in full, so the pages search engines index lose nothing.

Is it a fortress? No. Someone could write a scraper for this site that calls the Server Action first. But that raises the bar from "fetch a URL" to "drive the page like a person", and the daily cap is still there as a backstop.

The result: it shipped on Oct 24. Oct 25 cost cents. I'm not counting the days after, because that's when Redis was out of commands and the cap was blocking everything, so they prove nothing. I'll update this post with a clean week.

📋 If you're putting an LLM behind a URL

Any GET that calls a model is a cost endpoint. If anything links to it, assume something will crawl it.
Make links to expensive pages buttons, or gate them behind a gesture. Crawlers follow hrefs. They don't click.
Separate "can read answers" from "can create new ones". Cache-only mode gave me both: full pages for search engines, no spend for bots.
Rate limiters fail open, cost ceilings fail closed. And alert on the one that fails closed, because it will be quiet.
Your diagnostics cost money too. Scanning cache keys used up a real slice of my Redis free tier.

The irony of this post: everything that went wrong here, I designed myself, including the clever chip links that made the product better for people and a feast for crawlers.

The site is Because I liked: describe what you loved and why, and get films, shows, books and games matched on the why. Try a search. You're a person, so this one's allowed to cost me money 🙂

AI Made Everything Look the Same. That’s the Frontend’s Best News in a Decade.

Pushpendra Yadav — Wed, 21 Oct 2026 09:34:23 +0000

You can spot it in two seconds

Open any landing page launched in the last year and give yourself two seconds. You already know whether a person made it.

The gradient hero. The three feature cards in a row, each with a tiny icon in a tinted circle. Everything rounded exactly the same amount. A "Get started" button, a "See how it works" button next to it in ghost style. Inter, or whatever Inter is wearing this month. A purple that fades into a blue. Scroll and there's a logo wall of companies that have never heard of the product.

None of this is wrong. That's the uncomfortable part. Every one of those choices is defensible on its own. Together they produce a page that could belong to any of ten thousand companies, and your brain files it under "nobody was here" before you've read a word.

People started calling this AI slop somewhere around 2024 and it stuck, because it names a feeling we all had and couldn't explain. Same thing happened with AI images a year earlier. The hands got fixed. The skin got fixed. And still, you can tell.

Everyone got the order wrong

When the image models landed, the joke was that designers were first in line. Then Copilot and Cursor and the rest showed up and the joke moved to frontend. Backend was supposed to be safe. Distributed systems, consistency guarantees, all that hard stuff. The real engineering.

I've spent twelve years on the frontend side of that line and I think it's backwards.

Here is the claim, and the rest of this post is me trying to earn it: the more AI makes everything look the same, the more the interface becomes the only part of a product that can still be different. Backend converging on sameness is a feature. Frontend converging on sameness is a funeral.

Backend is the easier target, and nobody minds

Think about what makes a task easy for a model. It wants a well-documented problem, a known good shape for the answer, and a way to check whether it got it right.

Backend has all three.

The patterns are written down. Not just written down, written down by the people who scaled them. Every big tech engineering blog is a free textbook on queues, caches, sharding, idempotency, retries. The reasoning behind each decision is public. There's a word for the ideal backend and it is "boring". Boring is a compliment. Nobody opens a status page and thinks "I wish this Postgres felt more personal".

Correctness is checkable. Tests pass or they don't. p99 is under the budget or it isn't. The contract is the OpenAPI spec and the model can read it.

And the user never sees it. This is the big one. If your API is shaped like Stripe's and your queue is shaped like everyone's queue, your customer will never know and would not care if they did. Sameness costs you nothing here. It is literally best practice.

Someone will say "try vibe-coding a consensus protocol". Fair. The hard five percent of backend stays hard. It also lives in maybe fifty companies on earth. The median backend is a CRUD app with a job runner and a cache, and that shape has been solved so many times the model has seen it from every angle.

What I saw when I built the pipeline myself

I'm not arguing from the sidelines. I built a Figma-to-code pipeline on top of MCP. Designer finishes a frame, the pipeline reads it, maps it onto our existing component library, and hands back a working React screen that uses our buttons and our inputs and our spacing tokens instead of inventing new ones.

It worked. Better than I expected. Settings pages, forms, tables, modals, the whole middle of the app came out usable on the first pass most of the time. The kind of screen a mid-level engineer would have spent a day and a half on became a twenty-minute review.

Here's what it never did well, and I watched it try for months.

It could not decide what was worth being different. Hand it a frame where the designer had done something slightly odd on purpose, a card that breaks the grid, a transition that lingers a beat longer than it should, and it would quietly regularise it. Snap the card back to the grid. Use the default easing. Not because it was wrong, because the odd thing didn't match anything in the library and the safest move was to pick the nearest known shape.

That is the exact behaviour that produces slop. Not errors. Safety. A thousand locally reasonable choices that add up to a page with no fingerprints on it.

The human in the loop wasn't there to fix bugs. The human was there to say "no, leave that weird, it's the point".

Taste has no spec

Now run the backend checklist against the frontend.

Well-documented problem? Sort of. There are design systems and WCAG and a hundred "best practices" posts. But none of them tell you what your product should feel like. There is no engineering blog that explains why Linear feels like Linear.

Known good shape? That's the trap. There is a known good shape. It's the one from the first section. Following it is how you end up looking like everyone.

A way to check? A user looks at the screen for two hundred milliseconds and decides whether they trust you. There's no test for that. There's no p99 for "this looks like somebody cared".

And this is the part that holds up even as the models get better. Being distinctive is relative. The moment a style is learnable and common, it stops being distinctive by definition. Whatever the model converges on becomes the new default, and the new default is exactly what people learn to see through. The target moves every time it's hit. A model that nails today's taste is producing tomorrow's tell.

Meanwhile features have become table stakes. Anyone can clone your feature list over a weekend now. Nobody is choosing you for having a dashboard. What's left to choose on is how it feels to use the thing, and that is the surface.

Imperfect is not the same as bad

I keep hearing "people want human imperfection in UI now" and I want to be careful with it, because it's half right and the wrong half is dangerous.

Nobody wants a misaligned button. Nobody misses the 2009 web.

What people respond to is intention. A choice that a template would never make, made on purpose, and then committed to. Linear's keyboard-first everything. Arc's sidebar that refused to look like a browser. Raycast's little animations that nobody asked for. These are not imperfect products. They're extremely polished. They're just polished in a direction nobody else picked.

The tell for slop isn't ugliness. It's the absence of a decision. You look at a page and can't find a single spot where someone chose the harder option because they liked it better.

So if you're a frontend person reading this and feeling relieved, don't get the wrong idea. The job isn't to add quirks. The job is to have opinions and ship them. That was always the job. It's just that for a while, shipping fast could cover for not having any. It can't anymore, because fast is free now.

"The future has no UI"

There's a camp that says all of this is moot because the interface is going away. You'll talk to an agent, it'll call the APIs, work gets done, no screens. Who needs a frontend when you can just ask.

I'd buy it if I knew what I wanted every time I opened an app. I don't. Most people don't.

Think about how you actually use the big consumer products. You open Spotify without a song in mind. You open YouTube without a query. You open a shopping site to see what's there. You scroll Instagram to be shown things. Half the money in consumer software comes from people who arrived with no intent and left having found something. That's discovery, and discovery is a browsing problem.

Agents are great at retrieval. "Book me the 7am flight." "Find the invoice from March." Clear ask, clear answer, no screen needed, fine. But a chat box is a terrible place to not know what you want. A blank input with a blinking cursor is the least helpful interface ever designed for someone who hasn't decided yet. A good grid of options beats it every time.

So yes, a chunk of the interface will disappear, the chunk that was only ever a form in front of an API. That chunk was already the boring part. What's left is the part where someone has to be shown something they didn't ask for and be glad about it. That part gets more important, not less.

Where the value goes

When building something is free, the value moves to whatever isn't. I count three things: distribution, trust, and the way the product feels in your hands. Two of those three live in the interface. A page that looks generated now reads as "we didn't care enough to be here", and that's a trust problem before it's a design problem.

I'll put a prediction down so you have something to argue with. Within two years, "must not look AI-generated" shows up as a line item in design briefs, written down, the way "must be mobile responsive" did ten years ago. And somewhere right now, someone is building a product whose entire edge is that it looks like a person made it. I'd bet on them.

Backend engineers, you're fine. Boring was always the goal, and you're about to get very good at it very cheaply.

Frontend people, the bar just moved. Not down. Up, and sideways, to a place the models can't follow because the moment they get there it stops being the place.

My semantic search recommended Sharktopus to Jaws fans

Pushpendra Yadav — Tue, 20 Oct 2026 12:58:45 +0000

I run a recommendation site. You type something you loved and why, and it finds films, shows, books and games that match. Under the hood it's the standard 2026 stack: an LLM reads the query, an embedding model turns it into a vector, Postgres with pgvector finds the nearest titles.

Last week I opened the page for Jaws. Under "More films like Jaws":

Sand Sharks. Toxic Shark. Sharktopus.

Nobody who loved Jaws wants Sharktopus. Well, almost nobody.

The embeddings weren't broken. They were doing exactly what embeddings do, which isn't quite what the word "semantic" promises. Here are five ways my search matched words instead of meaning, how each one showed up, and what fixed it.

1. The name is in the vector

Hollow Knight is a hard, lonely, beautiful game about exploring a ruined kingdom. Its nearest neighbours included Knights in the Nightmare and The Knight Witch. Kal Ho Naa Ho, a Bollywood weepie, sat next to Kuch Naa Kaho and Kaho Naa… Pyaar Hai.

None of those are alike. They share words in the title.

I did this to myself. Every item is embedded from a text that starts with its name:

// so that queries naming a work ("like Arrival") land near it
return `${item.title} (${item.year}). ${item.medium}. ${item.description}`

That line made sense at the time, and it does help a query that names a title. But a title is a few heavily weighted tokens at the very start of the text, and two works that share them get pulled together no matter what the rest says.

The fix I shipped (the root fix is re-embedding without titles, which means recomputing everything): when a search starts from a title, demote results whose only tie to it is a shared word.

const titleWords = (t: string) =>
  t.toLowerCase().split(/[^\p{L}\p{N}]+/u)
    .filter((w) => w.length >= 4 && !SMALL_WORDS.has(w))
    .map((w) => w.replace(/s$/, '')) // "Knights" → "knight"

const echoes = (item) => titleWords(item.title).some((w) => anchorWords.has(w))
return [...results.filter((r) => !echoes(r)), ...results.filter(echoes)]

Demote, don't drop: sometimes a shared word is a real connection. The four-letter minimum is a deliberate trade-off. It catches "knight", but not "naa", because a rule loose enough to catch "naa" would also catch "man" and "war".

Check yours: take ten items and look at their nearest neighbours. If the neighbours share words in the name more often than they should, your names are in your vectors.

2. The nearest neighbour of anything is its sequel

"Movies like Jaws" returned Jaws 2, Jaws 3-D and Jaws: The Revenge in the top five. "Games like Hollow Knight" returned its own DLC.

Of course it did. A sequel shares the setting, the tone, the characters, half the description and the name. It's the most similar thing in the catalog, and the least useful recommendation: anyone asking for "movies like Jaws" already knows Jaws 2 exists.

The fix: a blunt franchise key (the first two meaningful words of the title, minus subtitle and trailing number), so that a search starting from a title leaves out the title's own franchise and keeps one result per franchise:

franchiseKey('Jaws: The Revenge')  // "jaws"
franchiseKey('The Witcher 3: Wild Hunt - Hearts of Stone')  // "witcher"
franchiseKey('Jaws 3-D')  // "jaws 3"  ← my first version. The "-D" broke the number rule.

That last line is real. The test I added after finding it is two lines long. Write the test.

3. The LLM rewrote the user's intent away

This one took me the longest to see, because the results looked fine.

Search "movies like Interstellar" and you get 2001, Ad Astra, Gravity, Arrival. Good.

Search "movies like Interstellar: the ache of leaving children behind" and you get… 2001, Ad Astra, Gravity, Arrival. The same list, in nearly the same order. The part the user actually cared about changed nothing.

My pipeline has an LLM step that rewrites the query into a richer description before embedding it. Here's what it produced:

"Vast, awe-filled space drama with a melancholy ache about leaving children behind; sweeping, emotionally weighted, a father's sacrifice… set against cosmic scale, somber and contemplative with a big orchestral score."

The user wrote eight words of why. The rewrite buried them in forty words describing Interstellar. Then my code blended the query vector 50/50 with Interstellar's own vector on top. The why was drowned twice.

My first instinct was the wrong one: turn down the blend. At 25% and at 15%, the results barely moved. I was tuning a knob that wasn't the cause.

My second instinct was also wrong: fix the prompt ("when a title is named, describe only the why"). The Interstellar results improved, and my eval score fell from 37% to 34%. A prompt change shifts how the model reads every query, including the 28 that never named a title.

The fix that worked was in code, not the prompt. When a query names a title and says why, embed the why in the user's own words and let the title's vector supply the rest:

const why = whyBeyondTitles(query, references.map((r) => r.title))
// "Movies like Interstellar: the ache…" → "the ache of leaving children behind"
const base = why ? await embedQuery(why) : await embedQuery(understoodText)
queryEmbedding = blend(base, titleVector, 0.5)

Now the same search leads with Leave the World Behind, Children of Men and E.T. And every eval case scored exactly what it scored before, because a query that doesn't name a title never reaches this code path.

The lesson: an LLM rewrite step is a lossy step. Print what it produces for your hardest queries, not your typical ones.

4. The average said fine. The cases said otherwise.

My database was too small to keep the vectors in memory, so I tested shrinking them. OpenAI's text-embedding-3-small is trained so you can keep only the first N dimensions, and 768 instead of 1,536 halves the size. Half precision (2 bytes a number instead of 4) halves it too.

My eval (28 real-style queries, recall@12) said:

Variant	Mean recall@12
Full vectors	38%
768 dimensions, half precision	35%

Three points. Probably noise, right?

Then I read the individual cases. The post-apocalyptic story game search lost both Last of Us games. The political fantasy search went from 75% to 25%, losing House of the Dragon and The Witcher. Those aren't reshuffles near the cutoff. Those are the answers.

Half precision at full length (halfvec(1536) in pgvector), by contrast, changed zero of 28 cases.

The lesson: report "up / down / flat" per case next to the mean, and read the downs. My eval script now prints this on every run:

vs last run on the same 28 cases: 38% → 35% · 4 up, 5 down, 19 flat

A mean can hide one disaster behind three small wins. A list of the five worse cases can't.

5. "Nearest" isn't "good"

I wanted a row under each search: "the same feeling, in other media". Searched for a TV show? Here's the book and the game that give you the same thing. Nobody else does this, and it's a great demo.

Searched "shows like Breaking Bad: a decent man slowly turning bad". Nearest film: Breakdown. Nearest game: Downfall.

A shared syllable and a vibe of things going badly. Across media it gets worse, because books, films and games are described in different vocabularies, so the nearest item from another medium is often the one that shares a word with the query rather than a meaning.

I tried a similarity floor: only show an item if it's at least X% as close as the main results. At 88%, the junk got through. At 90%, the junk still got through, and good picks started dropping out. Similarity scores across domains just aren't calibrated against each other.

The fix: retrieval proposes, an LLM disposes. The three nearest items from each medium go to a small model with one job, and it's explicitly allowed to say no:

Keep only candidates that genuinely give the user the same thing they
asked for... Sharing a word, a setting or a genre is not enough. Be
strict: keeping none is fine, and better than keeping a stretch.

Breaking Bad now gets The Iceman ("a seemingly ordinary family man living a double life") and Darkly Dreaming Dexter ("a respectable professional hiding a dark nature"). A courtroom drama gets Phoenix Wright: Ace Attorney. A heist film gets Six of Crows and Hitman 3. It costs about $0.0002 a search, and when nothing fits, the row just doesn't render.

The line that matters is "keeping none is fine". Without it, the model fills every slot, because you asked for slots.

The pattern

All five failures look the same from the outside: results that are close and wrong. And all five came from the same assumption, that vector similarity measures the thing you care about. It measures overlap in the text you embedded. Sometimes that's meaning. Often it's names, sequels, the LLM's paraphrase, or vocabulary.

What actually caught these:

Looking at neighbours by hand, for the items you know best. Every one of these I found by looking at a page, not at a metric.
A small eval with per-case diffs, run on every change. Mine is 30 queries. It doesn't need to be big. It needs to be read.
Printing the intermediate text. The rewrite step was the bug, and it was invisible until I printed it.
Letting a model say "none". Retrieval is good at candidates and bad at refusing.

And keep your sense of humour: it really did recommend Sharktopus.

The site is Because I liked: describe what you loved and why, and get films, shows, books and games matched on the why. Try a title with a reason, "movies like Jaws: the dread of what's under the water", and tell me what it gets wrong. That's how I find these.

My database was too small for my search

Pushpendra Yadav — Sun, 18 Oct 2026 17:01:40 +0000

Because I liked asks what you loved and why, then finds films, shows, books and games that match the why. Under the hood it's OpenAI embeddings in Postgres with pgvector, on Supabase's paid instance. (Part 1 is how it works, part 2 is how I measure it. This one stands on its own.)

For a week, real searches kept failing with "Search is having trouble right now." This is how I found out why, the three fixes that didn't work, and the one that did, at no cost and with no loss in quality.

🐢 The symptom

The catalog has 13,826 titles, each with a 1,536-dimension embedding. A search is one SQL function call that finds the nearest vectors, optionally filtered ("films only", "books only").

Same four searches, run back to back against production:

Search	Run 1	Run 2	Run 3	Run 4
Films only	3.7 s	2.2 s	1.4 s	5.6 s
Books only	1.2 s	1.1 s	4.9 s	1.5 s
All media	2.3 s	0.6 s	0.4 s	1.2 s

Not consistently slow. Erratic. And the anonymous role's statement timeout is about 8 seconds, so the bad runs became errors.

❌ Fix 1: rebuild the index

The HNSW index was 192 MB. The instance's shared_buffers (Postgres's own cache) is 224 MB. After I deleted a batch of experimental vectors, the index was carrying a lot of dead weight, so:

reindex index concurrently item_embeddings_vector_idx;

192 MB → 108 MB. Searches were still slow.

That's when I re-read my own search function and remembered something: filtered searches don't use the index at all. Months ago, a filtered HNSW search ("books only" when the nearest neighbours are all films) walked thousands of rejects and timed out, so filtered calls switched to an exact scan:

if match_medium is not null then
  perform set_config('enable_indexscan', 'off', true);
end if;

At 14k rows an exact scan is a few million multiply-adds, which is nothing. The CPU wasn't the problem. Reading the rows was.

❌ Fix 2: move the vectors out of TOAST

A vector(1536) is about 6 KB. Postgres moves any value over about 2 KB out of the row into a side table (TOAST), so every row of my exact scan was a separate lookup into that side table. And it was bloated:

Relation	Size
`item_embeddings` (the rows)	1.9 MB
its TOAST table	171 MB

171 MB for about 85 MB of live vectors, because deleted rows leave space behind that autovacuum marks reusable but never gives back.

A 6 KB vector still fits in an 8 KB page, so you can tell Postgres to keep it inline:

alter table item_embeddings alter column embedding set storage plain;
vacuum full item_embeddings;  -- rewrites the table so existing rows move

A Supabase gotcha: run those as two separate executions. The SQL editor wraps a multi-statement run in a transaction, and you get VACUUM cannot run inside a transaction block.

Result: rows 108 MB, TOAST 0 bytes. A clean sequential scan. Searches: still erratic. Films-only timed out twice in a row.

❌ Fix 3: keep it warm

If the data falls out of cache, read it back in on a schedule: pg_prewarm every five minutes from pg_cron.

This made things worse, or at best did nothing. Here's the measurement that explained everything:

Read	Time
Fetch 1 row	75–230 ms
Walk 9,000 vector rows, first time	3.6 s
Same walk, immediately after	0.14 s

The database is fast when the data is in memory, and the data doesn't stay in memory. Search needs 108 MB of rows plus a 108 MB index, about 216 MB, on a machine where Postgres, the auth service, the API layer and the OS all share a small amount of RAM. Pages get evicted between searches. Prewarming a working set that doesn't fit just re-reads it from a throttled disk every five minutes, competing with the searches it was meant to help. I turned it off.

The honest fix is a bigger machine. I wanted to try the free one first: a smaller working set.

🧪 Two ways to shrink a vector

Fewer dimensions. text-embedding-3-small is trained so the leading dimensions carry most of the meaning; OpenAI's dimensions parameter is literally truncation. And cosine distance ignores length, so you don't even need to re-normalise. Keep the first 768 at half precision: ~1.5 KB per vector, ~50 MB all in.

Lower precision. pgvector's halfvec stores each number in 2 bytes instead of 4. Same 1,536 dimensions: ~3 KB per vector, ~110 MB all in.

Neither needs a single new API call. Both are a cast in SQL:

subvector(embedding, 1, 768)::halfvec(768)   -- fewer dimensions
embedding::halfvec(1536)                     -- lower precision

I didn't want to guess which one loses quality, so I ran my eval set on both. It has 28 real-style searches, each with titles that should come back, scored by recall@12 against the same pipeline the site runs.

Variant	Size	Mean recall@12	vs full vectors
Full (`vector(1536)`)	216 MB	38%
768 dims, half precision	~50 MB	35%	4 up, 5 down
1536 dims, half precision	~110 MB	38%	0 up, 0 down, 28 flat

The 768 version looked fine on average and wasn't fine when I read the cases. "A post-apocalyptic story game" lost both Last of Us games. "Political fantasy with dragons" went from 75% to 25%, dropping House of the Dragon and The Witcher. Those aren't reshuffles; they're the answers.

Half precision changed nothing on all 28 cases. Same hits, same ranks.

🔧 Shipping it without a migration

I didn't want to touch the table the embedding scripts write to. So the half-precision copy is a separate table, kept in sync by a trigger:

create table item_vectors (
  item_id           uuid not null references items(id) on delete cascade,
  embedding_version text not null,
  embedding         halfvec(1536) not null,
  primary key (item_id, embedding_version)
);
-- 3 KB is still over the TOAST threshold: inline from the start
alter table item_vectors alter column embedding set storage plain;

create trigger item_embeddings_sync_vector
  after insert or update of embedding or delete on item_embeddings
  for each row execute function sync_item_vector();

The search function is a copy of the old one with the same signature, reading the new table and casting the query vector the same way:

declare
  q halfvec(1536) := query_embedding::halfvec(1536);

The app picks the function by name, with an environment variable override, so rolling back is one setting in Vercel, not a deploy:

export const MATCH_ITEMS_FN = process.env.MATCH_ITEMS_FN || 'match_items_short'

The offline job that precomputes "More like this" lists still uses the full vectors. It runs at night and can afford the bytes.

📉 Result

Search	Before (warm)	After, cold	After, warm
Films only	1.4–5.6 s, some timeouts	5.3 s	0.3–0.5 s
Books only	1.0–4.9 s	0.9 s	0.1–0.4 s
TV only	1.0–4.8 s	1.8 s	0.1–0.2 s

Cost: $0, plus a few cents of eval runs. The first search after a long quiet spell is still slow, which is what a small machine does. But it's under the timeout now, and the retry path covers the rest.

📎 While I was in there: Vercel's free tier

The same week, Vercel's dashboard said I'd gone past two Hobby-plan limits. The one that mattered was ISR writes: 218K of 200K. Every regeneration of a cached page counts, and I had:

14,000 title pages regenerating daily, and crawlers visiting all of them;
a deploy after nearly every commit, each one throwing the cached pages away;
a "where to watch" lookup cached per title per day, called for every pick in every search.

Fixes: title pages regenerate weekly (they only change when "More like this" is recomputed), the watch-provider cache went to three days, AI training crawlers are disallowed in robots.txt (search crawlers stay allowed: they send people), and I now deploy from a staging branch in batches.

🔍 And: the slow users weren't the ones I tested for

Lighthouse simulates a mid-range phone, and put the home page's LCP at 3.4 s. Real phones agreed: PostHog's Web Vitals said 3.4 s at p75. Real desktops said 10.3 s, mostly Chrome on Windows. I'd never have looked there. The sample is small (about 170 page loads), but a blank page for that long is a lost visitor, whatever the sample size.

Two things were in the way:

The landing page waited for a database read before sending anything. It's rendered per request, and it fetched the curated poster shelf (the same for everyone) before streaming a byte. On a slow-database day, the heading and the search box waited too. Now the shelf is cached for a day and streamed behind its own Suspense boundary.
Too much JavaScript before the page could settle. PostHog (about 100 KB) loaded with the page; now it loads when the browser goes idle, and events sent before that are queued, not dropped. supabase-js (about 60 KB) loaded on every title page just to ask "is anyone signed in?". Signed-out visitors have no session cookie, so now they skip the download entirely.

Initial JavaScript, uncompressed: title page 1,381 → 850 KB, home 1,623 → 1,314 KB. I'll report the real-user numbers when there's a week of them, not before.

🧭 What I'd tell myself a month ago

Measure the read, not the query. "1 row in 100 ms, 9,000 rows in 3.6 s cold and 0.14 s warm" told me more than any EXPLAIN did.
Prewarming only helps if the working set fits. If it doesn't, it's a cron job that thrashes the cache on a schedule.
Shrinking embeddings is a quality decision, so treat it like one. Truncating dimensions looked harmless on the mean and dropped the right answer on two searches. Half precision didn't move a single case. I'd never have known without an eval set.
Lab scores aren't your users. Lighthouse matched my phone visitors exactly and said nothing about the desktop ones, who were three times slower.

🙏 Try it

Free, no sign-up to search, no ads: becauseiliked.com

Try "a post-apocalyptic story game where the relationship matters more than the combat", the search the 768-dimension version got wrong. If you run pgvector on a small instance, I'd love to hear what your working set looks like, and whether halfvec held up on your eval.

I took down my own search 🔥

Pushpendra Yadav — Fri, 16 Oct 2026 18:47:13 +0000

Because I liked asks what you loved and why, then finds films, shows, books and games that match the why. Part 1 was how it works; part 2 was measuring it.

This one is shorter on cleverness and longer on mistakes. In one week I broke search for real users, found the cause was an experiment I'd forgotten was still running, taught it that "animated" doesn't always mean cartoon, and added 1,810 films for 38 cents.

🔥 Lesson 1: background jobs share your database with your users

Every title page shows "More like this": its 12 nearest neighbours, precomputed into a table so a page view is one indexed read instead of a vector search. After adding a batch of films, I started a job to recompute those lists for all 14,000 titles. Six titles at a time, each one a vector search.

Then I tried the site:

Search is having trouble right now. Please try again.

The vector search behind every query was hitting Postgres's statement timeout; with retries, a search took 26 seconds to fail. The database is small, and my batch job was hammering it with the same kind of query users were waiting on. Stopping the job brought search back.

Two things went wrong at once, and the second one hid behind the first.

The job could stall forever. Before the outage, the job had already gone quiet: the process was alive, but nothing had been written for six minutes. One request to the database had never come back, and nothing told it to give up. Every call now gets a deadline:

// a hung request otherwise stalls the whole run
return await Promise.race([fn(), timeout(30_000)])

It couldn't resume. A full recompute rewrote everything, so killing it meant starting over. It now takes a --before <time> flag and skips titles already done since then, plus --concurrency so it can run gently. The rest runs overnight, when nobody's searching.

👻 Lesson 2: your experiment is in the same index as production

Even with the job stopped, "films only" searches took over 5 seconds. Unfiltered ones took 140 ms. The difference was in the table.

In part 2 I described giving every film and show a second vector, describing only its lead character, to fix searches like "the main character is a sarcastic stoic". It didn't pass the test set, so I parked it. The vectors stayed:

Vectors in `item_embeddings`	Count
Search (`v3`)	13,826
Parked experiment (`lead-v1`)	7,971

One HNSW index covered both. A filtered search walks the graph until it has collected enough rows that pass every filter (right version, right medium), and over a third of what it walked past could never match. Books, about 6% of the catalog, were worse.

The fix was to delete the parked vectors. The lines themselves are still stored on each title, so re-embedding them later costs about a cent. When the experiment comes back, its vectors go in a table and index of their own. Filtered searches dropped to 0.9–3.8 seconds cold, and about 0.3 seconds warm.

The lesson is boring and I keep relearning it: an experiment is only parked once it can't touch the production path. Keeping its data in the shared table wasn't parking it.

🎨 Lesson 3: "an animated girl" isn't a cartoon

Search for "an animated film that makes adults cry" and the results included Close, Wonder and Bridge to Terabithia. All good films, all live-action. "Animated" was just one more word in the mood being matched, and the mood ("makes adults cry") is what matters most.

The catalog already knows: TMDB tags films and shows with an Animation genre. So the model that reads each search got a new field, format, which search turns into a hard filter.

Then the obvious problem. My first prompt's rule was "animated → animated films only". I tested it on six phrasings and it got three wrong:

Search	First prompt	Right answer
An animated movie that can make a grown man cry	animated	animated
A chirpy young animated girl living her life to the fullest	animated	lively, no filter
A film about an animated, talkative old man	animated	lively, no filter
I loved Up because the old man slowly opens up	animated	no filter: describing a loved film, not asking

The fix was to say what the word is attached to: "animated" describing the work (film, series, anime, cartoon) is a format; describing a person means lively and stays part of the mood. The tightened prompt got all nine phrasings in the next round right, including "more animated films like Up" (yes) and "a cartoonish, over-the-top comedy" (no: that's a style).

When the filter is off, the word still shapes the search, so "a chirpy animated girl" still leans animated without shutting out live-action. When the meaning is unclear, that's the right default.

🦈 Lesson 4: your catalog is biased toward whatever you seeded it from

I've been answering recommendation threads on Reddit, and one asked for lighthearted horror with a retro vibe, like Fright Night and The Lost Boys. The crowd's answers were good. Then I checked them against my catalog: 9 of the 16 suggestions I checked weren't in it, including the top-voted one, The Frighteners.

The catalog was seeded from TMDB's "popular" lists, which skew to what's popular now. So I measured the gap against TMDB's full list, sorted by vote count:

TMDB films with…	Missing from my catalog
2,000+ votes	2 of 2,837
1,000+ votes	1,831 of 5,021

Nearly every big film was there; over a third of the next tier wasn't. That's where cult and retro films live: The Frighteners, Slither, Arachnophobia, Trick 'r Treat, Bonnie and Clyde.

I added 24 first and read their descriptions before running the rest, the habit from part 2. The full run, through Anthropic's Batch API:

Step	Cost
Seed 1,810 films (TMDB)	free
Describe them	$0.32
Embed them	$0.009
Lead-character lines	$0.05
Total	≈ $0.38

32 films still fail the description quality check, mostly by slipping into "a film I know well…". They stay out of search rather than in with a bad description.

🖼️ Lesson 5: small things that make a page feel finished

Colour before the image. Grids of grey loading tiles look broken on a slow connection, which is most connections in India. Each poster and still now carries its average colour, worked out by shrinking a thumbnail to a single pixel:

const { data } = await sharp(thumbnail).resize(1, 1, { fit: 'fill' }).raw().toBuffer({ resolveWithObject: true })
// → '#81b1d2' for Up's sky

That ran across 13,850 titles for nothing but bandwidth. Then I found my own bug: a poster that took over 2.5 seconds swapped its colour for a designed fallback cover, so on exactly the slow connections this was for, people saw the fallback. Now the colour stays until the image arrives, and the fallback is only for images that fail.

Not looking like a film database. A visitor clicked a poster on the home page and left two seconds later. People clicked "12,000+ titles, browse it all" and took the product for a film database. That link is gone. So is "Browse" in the footer, and "← The library" on title pages is now "← Back to search". The product is the question, why did you love it?, so the page now leads with the question.

🔎 What about Google?

Part 2 promised the answer to whether the "why each pick fits" text on title pages gets them indexed. Honest update: too early to tell. Search Console still shows 2 pages indexed and 8 not, and that report runs days behind. A brand-new domain gets crawled cautiously until other sites link to it. I'll report when there's data, not before.

🙏 Try it, break it

Free, no sign-up to search, no ads: becauseiliked.com

Try "an animated movie that can make a grown man cry", then "a chirpy animated girl living her life to the fullest", and tell me if it read them right. And if a film you love is missing, put it in the comments: the catalog has a cult-classic gap, and you're better at finding it than any charts or trends.

I measured my AI search. The numbers were humbling 📏

Pushpendra Yadav — Thu, 15 Oct 2026 18:17:46 +0000

In part 1 I built Because I liked: you describe something you loved and why, and it finds films, shows, books and games that match the why, then explains each pick.

Part 1 ended with "the misses are the most useful thing you can send me". People sent them, across several platforms. This post is about what I did with them: building a test set, a fix that worked, a fix that should have worked and didn't, and what real visitors typed that I never planned for.

📏 Lesson 1: stop judging search by looking at it

For weeks my process was: change something, type three searches I liked, squint at the results, ship. Every change "looked better". Some of them weren't.

So I wrote a test set. Each case is a search (some from real visitors, some written to mirror them) plus 3–5 titles a well-read friend would name:

{
  "id": "hard-but-fair",
  "query": "a hard but fair game where dying teaches you something",
  "expect": ["Dark Souls", "Hollow Knight", "Celeste", "Sekiro: Shadows Die Twice", "Hades"]
}

The score is recall@12: what fraction of the expected titles appear in the first 12 results. It's a blunt instrument. Five titles can't capture "good taste", and a great pick that isn't on the list scores zero. But it's the same blunt instrument every time, and that's the point.

The first honest number: 28%.

Change	Mean recall@12
Baseline	28%
Named works become anchors ("like Breaking Bad, but funnier")	30%
Eras become filters ("from the 90s")	30%
Acclaim as a tiebreaker	40%

🏆 Lesson 2: similarity can't tell a classic from its clone

Here's what "a hard but fair game where dying teaches you something" returned at baseline: White Knuckle, Causality, I Wanna Maker, Levelhead, NetHack, Celeste… Every one of them is hard, and plenty are fair. Celeste at #6 was the only title a person would actually name, and Dark Souls wasn't in the top 12 at all.

To an embedding, an obscure precision platformer and Dark Souls are close neighbours. They're described the same way. Only one of them is the one people mean.

The fix is to let audience opinion break ties. For each candidate:

score = similarity + ACCLAIM_WEIGHT * acclaim(medium, votes, rating) // acclaim is 0–1

acclaim combines the audience rating with how many people rated it, so a 9/10 with 40 votes doesn't beat a 9/10 with 40,000. It only re-sorts the top 50 by fit, so a famous title that doesn't fit can't sneak in.

The interesting part is the weight. I swept it:

Weight	Recall@12	What happened
0	30%
0.03	31%
0.06	36%
0.1	40%	Dark Souls #1 and Hollow Knight #6 for "hard but fair"; quiet films keep their quiet picks
0.15	42%	Her jumps to #2 for "a quiet film about ordinary rooms"

0.15 scored higher, and I didn't take it. Her is a fine film, but it isn't a quiet film about ordinary rooms. It's a famous film that's near one. That's the failure the whole app exists to avoid: fame over fit. The test set can't see that distinction, so I made the call by reading the results.

Not every case improved across these changes, either. "Time loop" dropped from 40% to 20%, and "90s romcom" went to zero. A mean that goes up can hide cases that go down, so the eval prints a delta per case, and I read all of them.

🎭 Lesson 3: the fix that worked offline and failed the test

A visitor from Reddit searched:

"An analytical drama where the main character is a sarcastic stoic who struggles with his own emotions."

That's House. Or Sherlock. Neither appeared. In a sample of 155 titles, House ranked 153rd.

The reason is a variant of part 1's lesson. Each title has one description, and a description of House talks about medicine, mysteries, a hospital, a team. The lead's personality is one sentence among many, and one sentence barely moves a vector.

So I tried giving every film and show a second fingerprint that is only about the lead:

"The lead is a brilliant, sharp-tongued diagnostician who treats patients as puzzles and colleagues with open contempt, while privately fighting chronic pain and an addiction to painkillers."

Offline, before spending anything:

	Description only	Appending the lead line to it	Lead line as its own vector
Lie to Me	#145	#136	#3
Monk	#151	#147	#18
Sherlock	#154	#154	#33
House	#153	#153	#80

Appending the line to the description did nothing, for the same reason as before: it gets averaged away. As its own vector it worked. Writing 7,971 lead lines through Anthropic's Batch API cost $0.22.

In the real pipeline, the model that reads the query writes a matching "The lead is…" sentence, embeds it, searches the lead vectors, and fuses that ranking with the normal one using reciprocal rank fusion:

// each list votes 1/(k + rank); titles in both lists add up
const add = 1 / (RRF_K + rank + 1)

Then I ran the test set. The case still scored 0%.

The results were better: Scorpion, Death Note, The Imitation Game, Good Will Hunting, all reasonable answers to that request. But not the five titles on the list. Digging in, the lead vector turned out to be very sensitive to wording. The sentence the model wrote put Sherlock at #35; a sentence I wrote by hand put it at #2. Tuning the prompt until one test case passes is how you overfit a test set of 28.

So it's parked. The 7,971 lines and their vectors are in the database, ready for a better idea, maybe several phrasings per query with the best match kept. I'm not editing the test case to say "Scorpion counts". Moving the goalposts after missing is exactly what a test set is supposed to stop you doing.

📋 Lesson 4: your users search in shapes you never designed for

My mental model of a search was a sentence with a why in it. Here's an actual search from this week:

"Dark, Severance, Black Mirror, Love, Death & Robots, MR. Robot, Lost, 1899, From, Alice in Borderlands, Squid game,"

No why at all, just a list. The results were decent (Silo first, which they clicked), but #3 was 1899 and #7 was FROM. I'd handed back two of their own shows.

The filter that drops titles you named skipped one-word titles on purpose, so that "dark thrillers" doesn't remove the show Dark. A comma-separated list of capitalised entries is a different thing, so now that counts too:

// "Dark, Severance, 1899, From" is a list; "dark, moody, slow thrillers" isn't
const titled = entries.filter((e) => /^[\p{Lu}\p{N}]/u.test(e)).length
return entries.length >= 3 && titled >= entries.length * 0.66 ? entries : []

The bigger question was product, not code. A list of titles can only be matched on the titles themselves, which is exactly the genre-shelf matching this app exists to avoid. Refusing the search would be worse, though. So the results stay, and above them the page now asks:

These match the shows themselves. Tell us what you love about them, and we'll match that instead.

The input comes with sentence starters (The mood, A character, A moment, How it felt) that drop "because the mood was…" into the box for them to finish. Whatever they write becomes the why the next search matches on.

🎮 Lesson 5: "More like GTA V" was GTA V, six times

Every title page lists its nearest neighbours. For games, the catalog has every edition: Special, Enhanced, Story Mode, DLC. They're all described almost identically, so they're each other's nearest neighbours. All six of GTA V's top picks were GTA V: the base game twice, then the Special, Enhanced, Premium Online and Story Mode editions.

The fix is a deliberately blunt franchise key: the first two meaningful words of the title, once the subtitle and any trailing number are stripped:

franchiseKey('Grand Theft Auto V: Special Edition') // "grand theft"
franchiseKey('Grand Theft Auto: San Andreas')       // "grand theft"
franchiseKey('The Lord of the Rings')               // "lord rings"
franchiseKey('Lord of War')                         // "lord war": stays separate

At most one title per franchise per list. I recomputed all 12,016 lists. That cost nothing, since it's database work only. Skyrim's page now suggests Enderal, The Witcher 3 and Dragon Age instead of a shelf of its own editions.

🔎 Lesson 6: Google doesn't care about your embeddings

I finally set up Google Search Console. Its first report: six of my title pages were "Crawled – currently not indexed". Google had read them and decided they weren't worth keeping.

It's hard to argue. A title page's synopsis comes from TMDB (or IGDB, for games), so it's the same blurb as on IMDb and a thousand other sites. The part only I have is the why, and the pages didn't really say it.

So the most popular title pages now open their "More like…" section with what people love about the title, and why each pick fits. The first draft was bad in an instructive way. My catalog descriptions are heavy on look and sound (part 1's "golden hour" work), so the model described Breaking Bad as "sun-bleached desert light set against fluorescent-lit rooms". "Sun-bleached" appeared 13 times across 20 drafts. Nobody searching "shows like Breaking Bad" means the lighting.

The second draft fed in the synopsis, themes and the lead lines from Lesson 3, and asked for story and character first:

People love Breaking Bad for its slow corruption of a decent, proud man, the tension between his family life and his criminal double life, and the dread that he will not stop before he destroys everyone around him.

The Americans: like Walter, a controlled person hides a second life from his family, and the strain between loyalty and deception drives the story.

It cost $0.009 for 20 pages. There was one factual slip in 16 pages: it gave Fear the Walking Dead a "protective father", when the lead is a mother. That slip, plus wanting proof the copy helps, is why it's on 25 pages so far, not 12,000. Those six rejected pages got the new copy, and I asked Google to look again. Whether it changes Google's mind is part 3.

While I was in there, I fixed the URLs. Title pages were /browse/3bd40852-97cc-4767-8584-388236de35cc. They're now /browse/forza-horizon-5-3bd40852. The trailing 8 hex characters are the start of the item's UUID, and the lookup is a range query, so it still uses the primary key index:

// ids are uuid-typed, so "starts with" is a range
.gte('id', `${prefix}-0000-0000-0000-000000000000`)
.lte('id', `${prefix}-ffff-ffff-ffff-ffffffffffff`)

Old links 308 to the new ones. The best time to change your URLs is before Google has indexed them, and for me that was this week.

💸 Lesson 7: cheap per call is not cheap per mistake

Part 1 said re-describing the catalog cost about $2.30. True. What it didn't say: when you're iterating, you run it again. My bill showed that $2.30 more than once in two days. It's not a lot of money, but it's the wrong habit, and it scales with the catalog. The rules now:

Sample first. 20 titles, read every one, then decide. Most of the fixes in this post started that way.
State the cost before running anything catalog-wide, and put a hard cost cap in the script.
Use the Batch API for anything that isn't interactive: half price.
Prefer database work. The franchise fix touched 12,016 rows for $0.

What things cost now:

Lead lines for 7,971 films and shows: $0.22
Page copy: about $0.0005 per page
A full test-set run: a few cents

🙏 Try it, break it

It's free, no sign-up needed to search, no ads: becauseiliked.com

Try a search with a why, then one without. And if you have a search it gets wrong, especially a "the main character is…" one, put it in the comments. It goes straight into the test set.

I built a recommender that asks why you loved something — here's what broke 🍿 Pt. 1

Pushpendra Yadav — Tue, 13 Oct 2026 16:33:41 +0000

Every recommendation engine I've used asks the wrong question. "Because you watched Interstellar" gets you more space epics. But maybe the space was never the point. Maybe it was the loneliness, and an ending that hit your heart instead of your brain.

So I built Because I liked: you describe something you loved and why, in your own words, and it finds films, shows, books and games that match the why. Every pick explains how it connects to what you said.

Type "a lonely, beautiful sci-fi where the twist is emotional, not clever" and you get Moon, Her, Contact, The Midnight Sky, and Finch, a gentle film about a dying man building a robot to look after his dog. No space operas, no heist-in-orbit thrillers. It matched the feeling, not the genre shelf.

It's a solo project. This post covers how it works, and the parts that broke in instructive ways.

🧱 The stack

Next.js 16 (App Router) on Vercel
Supabase: Postgres + pgvector for similarity search
OpenAI text-embedding-3-small for vectors
Claude Haiku for reading queries, describing titles and writing explanations
About 12,000 titles from TMDB (films, TV), IGDB (games) and Open Library (books)

🧠 How a search works

Read the request. An LLM splits what you typed into the part that describes a feeling and the parts that are constraints.
Embed the feeling and find the nearest titles in pgvector.
Apply the constraints the data can actually check.
Explain the top picks against your own words.

Step 1 exists because of the first big lesson.

💥 Lesson 1: embeddings encode topic, not instruction

Early on, "feel-good beach-town shows, dubbed in Hindi" returned… Indian TV. Not beach towns. The words "Hindi" and "India" dominated the vector, and the thing the person actually wanted (sun, sea, warmth) ranked below 300.

An embedding doesn't know "dubbed in Hindi" is a filter. It just sees a topic. So now a model reads the request first:

// what gets embedded vs what becomes a filter
{
  texture: "warm, sunny, low-stakes shows set in a beach town",
  language: { code: "hi", intent: "audio" },
  medium: "tv",
}

Only texture goes into the vector. Language, age suitability, availability and named people become filters or boosts, each checked against real data. And when we can't check something (dubs on a specific streaming service, say), the app says so instead of pretending.

Dubs are the honest gap. No catalog I can access says which shows are dubbed in Hindi on which service, so the app doesn't pretend. It says it can't check dubs yet, and offers titles originally made in Hindi instead, as a clearly labelled alternative rather than a quiet swap.

🎭 Lesson 2: names in a vector pull in look-alikes

Someone asked for comedies "which also star Kevin James" and got comedies… without Kevin James. The name was in the vector, and the vector found films that felt similar.

The fix was the same pattern again: pull the person out of the query, look them up in the stored cast and crew credits, and put every title crediting them first, ranked by how well each one fits the why. Searching "directed by David Fincher" now leads with all eleven Fincher films we have.

⚡ Lesson 3: my title pages took 10 seconds (it was geography)

Each title has its own page, which is the bulk of the SEO surface. They were taking 1–10 seconds. Three causes, three fixes:

Distance. My Vercel functions ran in Washington DC (the default) while the database sits in Mumbai. Every query crossed the planet, about five times per page. Pinning functions to Mumbai with a one-line vercel.json cut the base cost from about 1.2 s to about 50 ms.
Live vector search on every view. "More like this" ran a similarity search per page view. I precomputed the 12 nearest neighbours for every title into a table instead, which turned it into one indexed read.
Per-visitor rendering. The page checked who was signed in, so it couldn't be cached. I moved the signed-in bits to the client, and now the page is cached at the edge.

Result: about 0.1 s for a cached title page, down from up to 10 s.

👀 Lesson 4: your first real user will find your blind spot

I launched quietly and watched (anonymous, cookieless) analytics. One of the first real visitors typed something like:

"a quiet film where ordinary rooms, window light and careful framing make everyday life feel interesting. Gentle mood, little violence."

That's a beautiful, very film person request. Two of the results were serial-killer thrillers. The visitor refined once and left.

The catalog had Paterson and Perfect Days, close to perfect answers, and neither surfaced. Why? My per-title descriptions (written by an LLM, then embedded) talked about story and character arcs, and mentioned the look only in passing. People don't search for plots. They mood-watch. They ask for how something looks, sounds and feels to sit with.

So I rewrote the description prompt to lead with the experience. Here's Paterson, before and after:

Before: "…The look is spare and patient…"

After: "Soft, unhurried daylight through kitchen windows and bus glass, with static camera setups that let ordinary rooms and street corners sit in frame… Intensity is very low: no violence, no gore."

Every title now states its aesthetic (light, palette, framing, sound), its vibe and the occasions it suits ("a rainy Sunday"), and its intensity in plain words, so "little violence" finally has something to match against.

Re-describing all 12,000 titles through Anthropic's Batch API cost about $2.30. A quality gate rejected descriptions that slipped into the first person ("a film I know well…") and retried them.

The same search now leads with Paterson, followed by quiet, carefully framed films like The Quiet Girl, Close and Umberto D., and the three thrillers are gone. One real visitor, one honest miss, one catalog-wide fix.

🔍 What's next: making "golden hour" findable

A single paragraph per title averages detail away. Ask for "a film where most scenes are shot in golden hour" and that detail is maybe 2% of a title's description, and 2% barely moves a vector. Next up:

Real keywords from TMDB and IGDB ("small town", "rain", "road trip"): facts the model can't be trusted to remember
Structured facets (visual motifs, intensity scores, runtime), so some asks become filters instead of hopes
Hybrid search: vectors for the vibe, facets for the specifics

💸 What it costs to run

Picks for one search: about $0.002 in LLM usage
Re-describing the whole catalog: about $2.30
Embedding it: about $0.10

Cheap enough to iterate on every time a real query exposes a gap, which is the whole game.

🙏 Try it, break it

It's free, with no sign-up needed to search, and no ads. becauseiliked.com

Describe something you genuinely loved and why, then tell me in the comments whether the picks got the why or just the genre. The misses are the most useful thing you can send me.

DEV Community: Pushpendra Yadav

TanStack Redact: Ship Less React Without Touching Your React Code

What Redact actually is

The usefulness is the headline

The numbers

It's not a toy React

Server Components stay with React

Go smaller if you want to

"Why not just use Preact?"

The honest tradeoff

Why I'm a fan

Google's crawler ran up my AI bill

🧾 How a search URL costs money

🕷️ Fix 1: robots.txt is a request, not a wall

🧱 Fix 2: firewalls stop the honest bots

🧯 Fix 3: a cost ceiling has to fail closed

🎟️ Fix 4: spend only on a person's action

📋 If you're putting an LLM behind a URL

AI Made Everything Look the Same. That’s the Frontend’s Best News in a Decade.

You can spot it in two seconds

Everyone got the order wrong

Backend is the easier target, and nobody minds

What I saw when I built the pipeline myself

Taste has no spec

Imperfect is not the same as bad

"The future has no UI"

Where the value goes

My semantic search recommended Sharktopus to Jaws fans

1. The name is in the vector

2. The nearest neighbour of anything is its sequel

3. The LLM rewrote the user's intent away

4. The average said fine. The cases said otherwise.

5. "Nearest" isn't "good"

The pattern

My database was too small for my search

🐢 The symptom

❌ Fix 1: rebuild the index

❌ Fix 2: move the vectors out of TOAST

❌ Fix 3: keep it warm

🧪 Two ways to shrink a vector

🔧 Shipping it without a migration

📉 Result

📎 While I was in there: Vercel's free tier

🔍 And: the slow users weren't the ones I tested for

🧭 What I'd tell myself a month ago

🙏 Try it

I took down my own search 🔥

🔥 Lesson 1: background jobs share your database with your users

👻 Lesson 2: your experiment is in the same index as production

🎨 Lesson 3: "an animated girl" isn't a cartoon

🦈 Lesson 4: your catalog is biased toward whatever you seeded it from

🖼️ Lesson 5: small things that make a page feel finished

🔎 What about Google?

🙏 Try it, break it

I measured my AI search. The numbers were humbling 📏

📏 Lesson 1: stop judging search by looking at it

🏆 Lesson 2: similarity can't tell a classic from its clone

🎭 Lesson 3: the fix that worked offline and failed the test

📋 Lesson 4: your users search in shapes you never designed for

🎮 Lesson 5: "More like GTA V" was GTA V, six times

🔎 Lesson 6: Google doesn't care about your embeddings

💸 Lesson 7: cheap per call is not cheap per mistake

🙏 Try it, break it

I built a recommender that asks *why* you loved something — here's what broke 🍿 Pt. 1

🧱 The stack

🧠 How a search works

💥 Lesson 1: embeddings encode topic, not instruction

🎭 Lesson 2: names in a vector pull in look-alikes

⚡ Lesson 3: my title pages took 10 seconds (it was geography)

👀 Lesson 4: your first real user will find your blind spot

🔍 What's next: making "golden hour" findable

💸 What it costs to run

🙏 Try it, break it

I built a recommender that asks why you loved something — here's what broke 🍿 Pt. 1