DEV Community: Sathish

Cursor + Claude: a repeatable refactor workflow

Sathish — Thu, 16 Apr 2026 15:01:23 +0000

I refactor with Cursor + Claude using a strict, diff-first loop.
I add a “tripwire” test first, so AI can’t lie.
I use one script to block dead imports + circular deps.
I ship smaller PRs by slicing refactors into phases.

Context

I build small SaaS apps. Usually solo. Usually fast.

Refactors are where I lose time. Not feature work. Refactors.

The failure mode is always the same. I ask an AI to “clean up” a folder. It touches 23 files. Tests still pass. Then I hit runtime and get TypeError: Cannot read properties of undefined. Brutal.

So I stopped doing vibe refactors.

Now I do repeatable refactors. Boring ones. With tripwires. With diffs I can actually review. Cursor + Claude still helps a lot. But only inside a tight workflow.

1) I write a tripwire test first. Always.

If I can’t prove behavior, I can’t refactor.

I don’t mean “increase coverage.” I mean a single test that fails loudly if I break the contract.

Most of my refactors are around data-shape drift. Objects coming from APIs. DB rows. JSON blobs. The tripwire is usually “given input X, output must be Y.”

Here’s a tiny example. A toUserDTO() function. I’ve broken this exact thing by renaming fields during a refactor.

// user.mapper.ts
export type UserRow = {
  id: string;
  email: string;
  created_at: string; // ISO
};

export type UserDTO = {
  id: string;
  email: string;
  createdAt: string;
};

export function toUserDTO(row: UserRow): UserDTO {
  // Keep mapping explicit. Avoid spreading unknown fields.
  return {
    id: row.id,
    email: row.email,
    createdAt: row.created_at,
  };
}

// user.mapper.test.ts
import { describe, expect, it } from "vitest";
import { toUserDTO } from "./user.mapper";

describe("toUserDTO", () => {
  it("maps snake_case to camelCase without changing values", () => {
    const dto = toUserDTO({
      id: "u_123",
      email: "a@b.com",
      created_at: "2026-04-16T10:11:12.000Z",
    });

    expect(dto).toEqual({
      id: "u_123",
      email: "a@b.com",
      createdAt: "2026-04-16T10:11:12.000Z",
    });
  });
});

Now the AI can refactor structure. Rename files. Extract helpers.

But it can’t “accidentally” change behavior without me noticing. The test becomes a landmine.

One thing that bit me — I used to ask Claude to “improve the test” too. Don’t. The test is the contract. Lock it.

2) I force Cursor to work in small, named phases

Big refactors fail because the AI loses the plot.

Cursor will happily apply a sweeping edit across a repo. Then you’re stuck reviewing 600 lines of diff with your brain half off.

My fix is dumb. I name phases and I don’t let the AI cross them.

Phase examples:

Phase A: move files, keep exports identical
Phase B: replace barrel exports
Phase C: delete dead code

I also keep a “refactor plan” file in the repo while I’m working. Not forever. Just during the refactor. Cursor’s context gets better, and I stop re-explaining myself.

<!-- REFACTOR_PLAN.md -->
# Refactor: src/lib -> src/core

## Phase A (no behavior changes)
- Move files under src/core
- Keep public exports identical
- Add temp re-exports to avoid breaking imports

## Phase B
- Update internal imports to new paths
- Remove temp re-exports

## Phase C
- Delete dead files
- Run typecheck + tests

## Non-goals
- No renaming DTO fields
- No changing runtime behavior

Then I prompt like this (inside Cursor):

“Do Phase A only. Don’t touch behavior. Keep exports identical. Update REFACTOR_PLAN.md checkbox when done.”

It sounds silly.

It works because I can review Phase A diffs quickly. Mostly file moves and export shims. If it breaks, it breaks in a small surface area.

And yeah — I’ve spent 4 hours on a refactor where I skipped this. Most of it was wrong.

3) I block dead imports and circular deps with one script

The most common refactor breakage I ship is import rot.

Stuff like:

a file moved but an old path still compiles somewhere
a circular dependency introduced by a new index.ts
a barrel export that re-exports server-only code into the client bundle

TypeScript won’t always save you. Especially with path aliases, dynamic imports, or unused exports.

So I run a dependency check script locally before I even open a PR.

This uses dependency-cruiser. It’s not perfect. But it catches the dumb stuff.

# install
npm i -D dependency-cruiser

// scripts/depcheck.mjs
import { cruise } from "dependency-cruiser";

const result = await cruise(["src"], {
  // Keep it strict. Refactors are when this matters.
  ruleSet: {
    forbidden: [
      {
        name: "no-circular",
        severity: "error",
        from: {},
        to: { circular: true },
      },
      {
        name: "no-orphans",
        severity: "warn",
        from: { orphan: true },
        to: {},
      },
      {
        name: "no-deprecated-core",
        severity: "error",
        from: { path: "^src/" },
        to: { path: "^src/legacy/" },
      },
    ],
  },

  // Make output readable in CI logs.
  outputType: "err",
  validate: true,
});

if (result.output?.trim()) {
  console.error(result.output);
  process.exit(1);
}

console.log("depcheck: ok");

// package.json
{
  "scripts": {
    "depcheck": "node scripts/depcheck.mjs"
  }
}

This catches cycles like:

src/core/index.ts -> src/core/http.ts -> src/core/index.ts

And orphans like:

src/utils/oldThing.ts that nobody imports anymore

Cursor + Claude helps here too. When depcheck fails, I paste the exact error output and ask for the smallest fix.

Smallest. Fix.

Not “refactor the architecture.”

4) I do diff reviews like a paranoid person

AI makes code changes fast. Reviewing is the bottleneck.

So I changed how I review.

Rules I follow:

I don’t review by file tree. I review by diff chunks.
I search the diff for export * from and index.ts. Every time.
I grep for any and as unknown as. If those appear during a refactor, something’s off.

This is my local helper script. It’s basic. It saves me from myself.

# scripts/refactor-review.sh
set -euo pipefail

# 1) Show summary first.
git status --porcelain

echo "\n--- DIFF STATS ---"
git diff --stat

echo "\n--- BARRELS / RE-EXPORTS ---"
# Find new/changed barrel exports in the diff
# (works even if ripgrep isn't installed)
git diff | grep -E "^\+.*export \* from|^\+.*from \"\.\/index\"" || true

echo "\n--- TYPE ESCAPES ---"
# Catch common 'make TS shut up' edits
# These are sometimes legit. Often they're hiding a broken import.
git diff | grep -E "^\+.*\bany\b|^\+.*as unknown as" || true

echo "\n--- DONE ---"

Run it:

bash scripts/refactor-review.sh

When that script prints anything under “TYPE ESCAPES”, I stop. I go fix the root cause.

Because the root cause is usually: I moved a file, broke an import, and the AI patched it with a cast.

That’s not a fix. That’s debt.

Results

My refactors got smaller.

Before this workflow, a “cleanup” often turned into 20 to 40 files changed in one sitting, with at least 1 runtime-only bug that I’d catch after deploying to preview.

This week, I did 3 refactor batches. Each stayed under 12 files changed. I hit npm run depcheck 9 times total and it caught 2 circular dependencies and 6 orphan files before they hit git history.

The bigger win: review time. I went from staring at diffs for ~45 minutes per refactor to ~15 minutes, because the changes were phased and the tripwire test stayed stable.

Key takeaways

Write one tripwire test before touching structure.
Refactor in named phases. Cursor needs boundaries.
Add a dependency check script. Run it a lot.
Treat any and double-casts as refactor smoke.
Keep exports boring until the very end.

Closing

Cursor + Claude can refactor fast. That’s the easy part.

The hard part is keeping refactors reviewable and reversible, especially when you’re solo and nobody’s catching your mistakes.

What’s your current “tripwire” for refactors — a specific test, a script like depcheck, or something else you run every single time?

React Native offline-first: SQLite schema for speed

Sathish — Wed, 15 Apr 2026 15:00:47 +0000

I model workouts as “events”, not nested JSON.
I use SQLite indexes that match my screens.
I store local-only IDs + sync state cleanly.
I hit sub-100ms reads on a mid phone.

Context

My fitness app has one job.
Log a set in ~5 seconds.

Offline-first forced my hand.
I can’t rely on network.
I can’t rely on a giant in-memory object either.
I tried the “store the whole workout as JSON” approach first.
Brutal.
It made edits painful, queries slow, and sync a mess.

So I went boring.
SQLite.
Not as a cache.
As the source of truth.

This post is just one angle.
Schema.
Tables, indexes, and the queries that map to screens.

1) I store sets as append-only events

I stopped thinking in “workout objects”.
I started thinking in “things that happened”.

A set logged is an event.
Editing a set is another event.
Deleting is another event.
Later, I can compact.
But day-to-day? Append-only wins.

It fixed two annoying problems.
Undo becomes easy.
Sync conflicts get smaller.

Here’s the schema I’m using in Expo SQLite.
It’s not fancy.
But it’s stable.

-- 001_init.sql
PRAGMA foreign_keys = ON;

CREATE TABLE IF NOT EXISTS workouts (
  id TEXT PRIMARY KEY,              -- UUID (client-generated)
  started_at INTEGER NOT NULL,       -- epoch ms
  ended_at INTEGER,                 -- epoch ms
  title TEXT,
  note TEXT,
  created_at INTEGER NOT NULL,
  updated_at INTEGER NOT NULL
);

CREATE TABLE IF NOT EXISTS set_events (
  id TEXT PRIMARY KEY,              -- UUID
  workout_id TEXT NOT NULL,
  exercise_id TEXT NOT NULL,
  set_index INTEGER NOT NULL,        -- position within exercise in that workout
  kind TEXT NOT NULL,               -- 'LOG' | 'EDIT' | 'DELETE'
  reps INTEGER,
  weight_kg REAL,
  rir INTEGER,                       -- reps in reserve
  happened_at INTEGER NOT NULL,      -- epoch ms
  device_seq INTEGER NOT NULL,       -- monotonic per device
  dirty INTEGER NOT NULL DEFAULT 1,  -- 1 = needs sync
  server_rev INTEGER NOT NULL DEFAULT 0,
  FOREIGN KEY (workout_id) REFERENCES workouts(id) ON DELETE CASCADE
);

-- The screen query: "latest state per set" needs this.
CREATE INDEX IF NOT EXISTS idx_set_events_workout_exercise
  ON set_events(workout_id, exercise_id, set_index, happened_at DESC);

-- Sync query: "give me dirty events in order" needs this.
CREATE INDEX IF NOT EXISTS idx_set_events_dirty_seq
  ON set_events(dirty, device_seq);

I learned the hard way that device_seq matters.
I originally sorted by happened_at.
Two events in the same millisecond.
Same phone.
Same JS tick.
Order flipped once.
I stared at a “ghost delete” for 4 hours.
Most of it was wrong.

Now I do device_seq.
Just an integer I increment locally.

2) I index for the UI I actually have

SQLite is fast.
But “fast” disappears when you make it guess.

My app has three hot paths:
1) Today’s workout screen (list exercises + latest sets)
2) Exercise history screen (last 20 sets)
3) Sync (dirty events)

So I index for those.
Not for “normal forms”.
For screens.

This is the query behind “show me the latest sets for this exercise in this workout”.
It uses a window function.
Expo’s SQLite ships new enough SQLite for this.
If you’re on something ancient, you’ll need a different approach.

// db/queries.ts
import * as SQLite from "expo-sqlite";

export type LatestSetRow = {
  set_index: number;
  reps: number | null;
  weight_kg: number | null;
  rir: number | null;
  kind: "LOG" | "EDIT" | "DELETE";
  happened_at: number;
};

export async function getLatestSetsForExercise(
  db: SQLite.SQLiteDatabase,
  workoutId: string,
  exerciseId: string
): Promise {
  const sql = `
    WITH ranked AS (
      SELECT
        set_index, reps, weight_kg, rir, kind, happened_at,
        ROW_NUMBER() OVER (
          PARTITION BY set_index
          ORDER BY happened_at DESC
        ) AS rn
      FROM set_events
      WHERE workout_id = ? AND exercise_id = ?
    )
    SELECT set_index, reps, weight_kg, rir, kind, happened_at
    FROM ranked
    WHERE rn = 1 AND kind != 'DELETE'
    ORDER BY set_index ASC;
  `;

  const rows = await db.getAllAsync(sql, [workoutId, exerciseId]);
  return rows;
}

That idx_set_events_workout_exercise index is doing real work here.
Without it, my mid-tier Android (Pixel 6a) was spiking.
Not always.
Just enough to feel gross.

One thing that bit me — using TEXT IDs everywhere means indexes get bigger.
Still fine.
But don’t add random extra indexes “just in case”.
Each one costs writes.
And I’m writing a lot.

3) I keep sync state out of my domain fields

I don’t want “server stuff” leaking everywhere.
But offline-first means I need it.
So I isolate it.

My rule:

Domain fields: reps, weight, exercise_id
Sync fields: dirty, server_rev, device_seq

Then sync is just: “give me dirty events, ordered”.
No scanning.
No weird filters.

Here’s the exact query + a tiny “mark as synced” function.
This is intentionally boring.

// db/sync.ts
import * as SQLite from "expo-sqlite";

type DirtyEvent = {
  id: string;
  workout_id: string;
  exercise_id: string;
  set_index: number;
  kind: string;
  reps: number | null;
  weight_kg: number | null;
  rir: number | null;
  happened_at: number;
  device_seq: number;
  server_rev: number;
};

export async function getDirtyEvents(
  db: SQLite.SQLiteDatabase,
  limit = 200
): Promise {
  const sql = `
    SELECT id, workout_id, exercise_id, set_index, kind,
           reps, weight_kg, rir, happened_at, device_seq, server_rev
    FROM set_events
    WHERE dirty = 1
    ORDER BY device_seq ASC
    LIMIT ?;
  `;
  return db.getAllAsync(sql, [limit]);
}

export async function markEventsSynced(
  db: SQLite.SQLiteDatabase,
  eventIds: string[],
  newServerRev: number
) {
  if (eventIds.length === 0) return;

  const placeholders = eventIds.map(() => "?").join(",");
  const sql = `
    UPDATE set_events
    SET dirty = 0,
        server_rev = ?
    WHERE id IN (${placeholders});
  `;

  await db.runAsync(sql, [newServerRev, ...eventIds]);
}

I used to store “lastSyncedAt” on the workout.
Bad move.
One event fails.
Now the whole workout looks synced.
Congrats, you just lost data.

Event-level sync state is annoying.
But it’s correct.

4) I generate IDs and sequences locally. Every time.

Offline means no server IDs at write time.
So I generate UUIDs on device.
And I keep a monotonic sequence.

I’m on Expo.
So I use expo-crypto for UUID.
And I store the sequence in SQLite too.
No AsyncStorage.
One storage system.
Less weirdness.

// db/writeSet.ts
import * as Crypto from "expo-crypto";
import * as SQLite from "expo-sqlite";

async function nextDeviceSeq(db: SQLite.SQLiteDatabase): Promise {
  await db.execAsync(`
    CREATE TABLE IF NOT EXISTS kv (
      key TEXT PRIMARY KEY,
      value TEXT NOT NULL
    );
  `);

  await db.runAsync(
    `INSERT OR IGNORE INTO kv(key, value) VALUES('device_seq', '0');`
  );

  // Atomic increment in SQLite.
  await db.runAsync(
    `UPDATE kv SET value = CAST(value AS INTEGER) + 1 WHERE key = 'device_seq';`
  );

  const row = await db.getFirstAsync<{ value: string }>(
    `SELECT value FROM kv WHERE key = 'device_seq';`
  );

  return Number(row?.value ?? 0);
}

export async function logSetEvent(
  db: SQLite.SQLiteDatabase,
  input: {
    workoutId: string;
    exerciseId: string;
    setIndex: number;
    reps: number;
    weightKg: number;
    rir?: number | null;
  }
) {
  const id = Crypto.randomUUID();
  const deviceSeq = await nextDeviceSeq(db);
  const now = Date.now();

  await db.runAsync(
    `INSERT INTO set_events(
      id, workout_id, exercise_id, set_index,
      kind, reps, weight_kg, rir,
      happened_at, device_seq, dirty
    ) VALUES(?, ?, ?, ?, 'LOG', ?, ?, ?, ?, ?, 1);`,
    [
      id,
      input.workoutId,
      input.exerciseId,
      input.setIndex,
      input.reps,
      input.weightKg,
      input.rir ?? null,
      now,
      deviceSeq,
    ]
  );

  return { id, deviceSeq };
}

This fixed a nasty bug.
I had device_seq in memory.
Killed the app.
Restart.
Sequence reset.
Sync order broke.

Storing it in SQLite is dull.
Also bulletproof.

Results

After moving from “nested JSON per workout” to the event schema above, my heaviest screen stopped stuttering.
On my Pixel 6a, the “open workout” query went from ~280–450ms down to ~45–85ms for a workout with 9 exercises and 31 logged sets.
Set logging writes are ~6–12ms per event locally.
Sync became simpler too: I send 1–200 small rows instead of merging a big JSON blob.
The best part is debugging.
I can read the event table and know what happened.
No guessing.

Key takeaways

Model offline writes as events. Editing becomes another event.
Add indexes that match your screens. Not your ER diagram.
Keep sync fields (dirty, server_rev, device_seq) separate from domain fields.
Don’t sort by timestamps alone. A monotonic sequence saves you.
Store your sequence in SQLite, not memory. App restarts are real.

Closing

I’m still tuning this.
Next up is compaction: turning 40 events into 1 “current set” row without losing history.

If you’ve shipped offline-first on React Native: do you compact event logs on-device, or only on the server?

Next.js job board: stop indexing expired jobs

Sathish — Tue, 14 Apr 2026 15:00:50 +0000

I stopped Google indexing expired job pages. Without deleting them.
I used Next.js 14 + Supabase to return 410/404 correctly.
I added a tiny robots guardrail to prevent “helpful” bugs.
I shipped a sitemap that only includes active listings.

Context

I’m building a job board for Psychiatric Mental Health Nurse Practitioners.

It has 8,000+ active listings and ~2,000 companies. New jobs arrive daily (200+ scraped/day). Old jobs expire daily too.

My first version treated “expired” as a UI state. The route still returned 200 OK. Google loved that. Brutal.

I ended up with thousands of low-value pages indexed. Many were “Apply closed” pages. Some were thin because the source removed details.

The fix wasn’t “better SEO.” It was HTTP correctness. And a sitemap that doesn’t lie.

1) I model job lifecycle in Postgres. Not in UI

I needed a single truth: is this job indexable?

So I made it explicit in the table. Status. Timestamps. And an immutable first_seen_at so my scraper doesn’t rewrite history.

Here’s the migration I used (Supabase Postgres).

-- 001_jobs_lifecycle.sql

-- Jobs can be active, expired, or removed.
-- removed = source page is gone, or legal takedown, etc.
-- expired = time-based expiration or “closed” detected

create type job_status as enum ('active', 'expired', 'removed');

alter table public.jobs
  add column if not exists status job_status not null default 'active',
  add column if not exists first_seen_at timestamptz not null default now(),
  add column if not exists last_seen_at timestamptz not null default now(),
  add column if not exists expires_at timestamptz,
  add column if not exists removed_at timestamptz;

-- Helps query “what’s indexable” fast.
create index if not exists jobs_status_expires_at_idx
  on public.jobs (status, expires_at);

create index if not exists jobs_last_seen_at_idx
  on public.jobs (last_seen_at desc);

One thing that bit me — I originally used a boolean is_active.

Then I needed “removed” vs “expired” behavior. Different HTTP codes. Different sitemap behavior.

Enums saved me from the boolean mess.

2) I return 410 for expired. 404 for removed

This is the whole point.

If a job is expired, I want it to disappear from the index fast. 410 Gone is explicit.

If the job was removed (source vanished, or I removed it), I return 404.

Next.js notFound() always returns 404. That’s not enough.

So I return a NextResponse with the right status.

// app/jobs/[slug]/page.tsx
import { createClient } from "@supabase/supabase-js";
import { notFound } from "next/navigation";
import { NextResponse } from "next/server";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // server only
);

type JobRow = {
  id: string;
  slug: string;
  title: string;
  status: "active" | "expired" | "removed";
  expires_at: string | null;
};

export default async function JobPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;

  const { data: job, error } = await supabase
    .from("jobs")
    .select("id, slug, title, status, expires_at")
    .eq("slug", slug)
    .maybeSingle();

  if (error) throw error;
  if (!job) return notFound();

  // Removed: behave like a missing resource.
  if (job.status === "removed") return notFound();

  // Expired: return 410. Still render a human page.
  if (job.status === "expired") {
    return new NextResponse(
      `${escapeHtml(
        job.title
      )} (Closed)# Job closed
`,
      {
        status: 410,
        headers: {
          "content-type": "text/html; charset=utf-8",
          "cache-control": "public, max-age=300",
        },
      }
    );
  }

  // Active: normal render.
  return (

      # {job.title}

      {/* rest of the job page */}

  );
}

function escapeHtml(input: string) {
  return input
    .replaceAll("&", "&")
    .replaceAll("<", "<")
    .replaceAll(">", ">")
    .replaceAll('"', """)
    .replaceAll("'", "'");
}

Yeah. It’s weird returning raw HTML in a page.

I tried to do it “the React way” for 410. Spent 4 hours. Most of it was wrong.

In App Router, you don’t get an easy “render UI but with status 410” primitive. So I went direct.

And I keep it intentionally minimal. No indexing. No internal links. Just a polite dead-end.

3) I enforce “noindex” for anything not active

Status codes are good.

But bugs happen. Scrapers misclassify. Admin toggles go wrong. Somebody changes code and accidentally returns 200 for expired.

So I added a second guardrail: robots meta.

If a job isn’t active, it gets noindex, nofollow.

// app/jobs/[slug]/metadata.ts
import type { Metadata } from "next";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

type JobMetaRow = {
  title: string;
  status: "active" | "expired" | "removed";
};

export async function generateMetadata({
  params,
}: {
  params: Promise<{ slug: string }>;
}): Promise {
  const { slug } = await params;

  const { data: job } = await supabase
    .from("jobs")
    .select("title, status")
    .eq("slug", slug)
    .maybeSingle();

  if (!job) return { title: "Not found" };

  const isIndexable = job.status === "active";

  return {
    title: job.title,
    robots: isIndexable
      ? { index: true, follow: true }
      : { index: false, follow: false },
  };
}

Two layers now.

Active: 200 + index,follow
Expired: 410 + noindex,nofollow
Removed: 404

I sleep better.

4) I generate a sitemap from the DB. Only active jobs

My original sitemap was route-based.

/jobs/[slug] exists, so it got listed. That’s how I fed crawlers a buffet of expired pages.

Now I generate the sitemap from Postgres.

Only active jobs. And I cap it. Because 8,000 URLs is fine, but it keeps growing.

// app/sitemap.ts
import type { MetadataRoute } from "next";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

export default async function sitemap(): Promise {
  const siteUrl = process.env.NEXT_PUBLIC_SITE_URL!; // e.g. https://pmhnp.example

  // Only active jobs get into the sitemap.
  // I keep it under 45,000 to stay safe with size.
  const { data: jobs, error } = await supabase
    .from("jobs")
    .select("slug, last_seen_at")
    .eq("status", "active")
    .order("last_seen_at", { ascending: false })
    .limit(45000);

  if (error) throw error;

  const urls: MetadataRoute.Sitemap = jobs.map((j) => ({
    url: `${siteUrl}/jobs/${j.slug}`,
    lastModified: new Date(j.last_seen_at),
    changeFrequency: "daily",
    priority: 0.6,
  }));

  // Add a couple of stable pages.
  urls.push(
    {
      url: `${siteUrl}/`,
      lastModified: new Date(),
      changeFrequency: "daily",
      priority: 1,
    },
    {
      url: `${siteUrl}/jobs`,
      lastModified: new Date(),
      changeFrequency: "hourly",
      priority: 0.8,
    }
  );

  return urls;
}

This also forced me to keep status accurate.

If my scraper forgets to expire something, it stays in the sitemap. That’s a loud failure. Good.

5) I expire jobs automatically with one SQL update

I didn’t want a complicated workflow.

My scraper sets last_seen_at = now() whenever it still sees the job. If a job hasn’t been seen in 30 days, it’s probably closed.

So once per day, I run one SQL statement.

This is intentionally boring.

-- 002_expire_jobs.sql

-- Expire jobs not seen in 30 days.
-- Keeps “active” set clean for sitemap + indexing.

update public.jobs
set
  status = 'expired',
  expires_at = coalesce(expires_at, now())
where
  status = 'active'
  and last_seen_at < now() - interval '30 days';

In Supabase, I run this via a scheduled job (pg_cron if you have it, or a Vercel Cron hitting an API route that executes the SQL).

I used Vercel Cron.

Because I already have it. And I didn’t want to fight extension permissions.

Results

After this change, my sitemap dropped from 12,418 URLs to 8,091 URLs. That’s just “active” jobs now.

I also stopped serving 200 for closed listings. Expired jobs now return 410 consistently. Removed jobs return 404.

In Google Search Console, “Indexed, not submitted in sitemap” for job URLs went down from 3,204 to 611 over 10 days. Not zero yet, but it’s finally moving the right direction.

And my crawl stats stopped wasting time on dead pages.

Key takeaways

Don’t encode lifecycle in UI state. Put it in Postgres.
Use 410 Gone for expired content. It clears faster than a soft 404.
Add noindex as a second guardrail. Bugs happen.
Generate sitemaps from your database, not your route tree.
One daily SQL update beats a “smart” expiration pipeline.

Closing

If you’re running a job board (or any scraped directory), how are you deciding between 404 and 410?

Do you return 410 immediately on “closed”, or do you keep a grace period so the page can still help users for a week?

Cursor + Claude for PRs: my diff-first workflow

Sathish — Thu, 09 Apr 2026 15:12:59 +0000

I don’t ask Claude to “build features”. I ask for diffs.
I keep a local PR checklist in the repo. Enforced.
I auto-generate a patch, run tests, then iterate on failures.
You can copy my scripts: patch → typecheck → lint.

Context

I build small SaaS projects. Usually solo. Usually fast.

Vibe coding works. Until it doesn’t.

My failure mode was consistent: I’d paste a prompt, get 200 lines back, accept it, and then spend 3 hours chasing a dumb regression. Brutal.

So I changed the unit of work.
Not “a feature”. Not “a refactor”.
A diff.

If I can’t review it like a PR, it doesn’t ship. Even when I’m the only person on the repo.

Cursor helps because I can keep the conversation glued to the exact files. Claude helps because it can generate precise patches. But the workflow is the point.

1) I start with a PR checklist. In the repo.

If the checklist lives in my head, it doesn’t exist.

I keep mine in docs/pr-checklist.md. Then I reference it in every Cursor chat.

It’s boring. That’s why it works.


# PR checklist (local)

## Before code
- [ ] What’s the smallest diff that solves it?
- [ ] What’s the rollback plan? (git revert is fine)
- [ ] What’s the failure mode? (timeout, null, race, etc.)

## While coding
- [ ] No new deps unless unavoidable
- [ ] No "magic" env vars without docs
- [ ] Errors include context (ids, inputs)

## Before merge
- [ ] `npm run typecheck` passes
- [ ] `npm run lint` passes
- [ ] Added/updated tests (or wrote down why not)
- [ ] Ran the code path locally (screenshots optional, reality required)

I learned the hard way that “AI will remember constraints” is fake.
It won’t.
I won’t either, when I’m tired.

So I paste this into the prompt:

Follow docs/pr-checklist.md. Output a unified diff only.

No checklist. No code.

2) I force “diff-only” output. No essays.

Claude loves explaining. I get it.
But explanations don’t merge.

When I say “diff-only”, I mean it.
If it outputs anything else, I reject it and restate the constraint.

Also: I always request unified diff format.
Cursor applies it cleanly, and I can review it fast.

Here’s the exact prompt template I keep in a scratch file.
Not fancy. Just strict.

# prompts/diff-only.txt
You are editing a git repo.

Rules:
- Output ONLY a unified diff (```

diff ...

 ```).
- No prose. No bullets. No explanation.
- Touch the fewest files possible.
- Follow docs/pr-checklist.md.

Task:


Context:

Why this matters: it keeps me in review mode.
Not “wow it wrote code mode”.

And yeah, I still mess up.
I once accepted a nice-looking refactor that swapped zod parsing order and silently changed behavior. Spent 4 hours on this. Most of it was wrong.
Diff-first would’ve made it obvious.

3) I apply patches with a script. Then I run the gauntlet.

I don’t want manual steps.
Manual steps become “I’ll do it later”.

So I wrote a tiny patch runner.
It applies a diff file, then runs typecheck + lint + tests.
If anything fails, I feed the error back into Cursor + Claude.

This is Mac/Linux-friendly.
If you’re on Windows, WSL makes it normal.

#!/usr/bin/env bash
# scripts/apply_patch_and_check.sh
set -euo pipefail

PATCH_FILE="${1:-}"
if [[ -z "$PATCH_FILE" ]]; then
  echo "Usage: scripts/apply_patch_and_check.sh path/to/patch.diff" >&2
  exit 1
fi

# 1) Apply patch
# --whitespace=fix avoids dumb failures on trailing spaces
# --reject shows conflicts as .rej files instead of silently failing

git apply --whitespace=fix --reject "$PATCH_FILE"

# 2) Run the gauntlet
npm run typecheck
npm run lint
npm test

echo "OK: patch applied + checks passed"

My repo scripts are boring too:

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "lint": "next lint",
    "test": "vitest run"
  }
}

When something fails, I don’t “fix it manually” immediately.
I paste the exact error into Cursor.
Then ask for a new diff that fixes only that.

Example error I hit last week:

TypeError: Cannot read properties of undefined (reading 'id')
  at app/api/widgets/route.ts:41:23

That’s not a “write more code” problem.
That’s a “handle null input” problem.
Diff-only keeps that scoped.

4) I add guardrails in code, not in prompts

Prompts decay.
Code stays.

The simplest guardrail: validate inputs at boundaries.
In Next.js route handlers, I parse JSON safely and validate with Zod.

This prevents the classic AI bug: assuming fields exist.

// app/api/widgets/route.ts
import { NextResponse } from "next/server";
import { z } from "zod";

const WidgetCreate = z.object({
  name: z.string().min(1),
  size: z.number().int().min(1).max(1000)
});

export async function POST(req: Request) {
  // Don't trust req.json() blindly. It throws.
  let body: unknown;
  try {
    body = await req.json();
  } catch {
    return NextResponse.json({ error: "Invalid JSON" }, { status: 400 });
  }

  const parsed = WidgetCreate.safeParse(body);
  if (!parsed.success) {
    return NextResponse.json(
      { error: "Invalid payload", issues: parsed.error.issues },
      { status: 400 }
    );
  }

  const { name, size } = parsed.data;

  // pretend persistence here
  return NextResponse.json({ id: crypto.randomUUID(), name, size }, { status: 201 });
}

Cursor + Claude can generate this.
But only if I demand it.

One thing that bit me — Claude sometimes “fixes” errors by widening types to any.
That’s not a fix.
That’s a mute button.

So I add one more constraint to my diff prompt:

Don’t add any. Don’t disable lint rules.

And if it still does it?
I reject the diff.

5) I keep the loop tight: commit small, revert fast

Long AI sessions feel productive.
They’re also where bugs hide.

My rule: every accepted diff becomes a commit.
Even if it’s tiny.

Then if the next diff breaks something, I revert cleanly.
No archaeology.

Here’s the exact git flow I use when I’m iterating with Cursor:

# 1) Create a branch
git checkout -b fix/input-guards

# 2) After a patch passes checks
git add -A
git commit -m "Add Zod validation to widgets POST"

# 3) If the next patch goes sideways
git revert HEAD

# 4) Or if I want to trash everything on the branch
git reset --hard origin/main

Yeah, reset --hard has teeth.
That’s the point.

I used to avoid committing “ugly” intermediate steps.
Bad instinct.
In solo repos, commits are my safety rope.

Results

I shipped fewer “looks fine” bugs.
Not zero. But fewer.

Over the last 10 working days, I counted 27 AI-generated diffs that made it to main.
21 passed checks on the first apply.
6 failed typecheck or tests and needed a second diff.

Before this workflow, I’d routinely accept a big paste, then do 10+ manual edits to make it compile. That’s where I’d accidentally change behavior.

Now the failures are loud, early, and localized to one diff.

Key takeaways

Treat AI output like a PR. Review a diff, not a story.
Put your checklist in the repo, not your brain.
Automate the “apply patch → run checks” loop. Remove willpower.
Add guardrails in code (validation at boundaries). Prompts rot.
Commit small so you can revert fast.

Closing

If you’re using Cursor + Claude too, try this for one week.
Diff-only prompts. Patch script. Small commits.

What’s the one check you always run before accepting an AI diff: typecheck, lint, unit tests, or a manual click-through of the UI?

React Native offline-first: SQLite write-ahead log

Sathish — Wed, 08 Apr 2026 15:00:41 +0000

Turn on SQLite WAL in Expo. It fixes “database is locked”.
Batch writes in one transaction. Fewer fsyncs. Faster UI.
Add a busy timeout + retry. Stops random write failures.
Measure it. I logged real timings per write batch.

Context

My fitness app needs 5-second set logging. No spinning loaders. No “try again” toast. And it has to work on airplane mode.

I use Expo + SQLite because I need real queries. Joins. Indexes. Counting volume per workout. AsyncStorage fell over fast.

Then I hit the classic wall: concurrent reads + writes. Search is running. The workout screen is inserting sets. And suddenly I get SQLITE_BUSY: database is locked.

I wasted 4 hours blaming React renders. Most of it was wrong. SQLite was doing exactly what I asked. I just hadn’t configured it for a mobile app that’s always doing something.

1) I stop fighting concurrency. I enable WAL.

SQLite defaults can be conservative. WAL (write-ahead logging) changes the locking model. Readers don’t block writers the same way.

On mobile, that’s the difference between “feels instant” and “random lock errors at the worst moment”.

I enable WAL once on startup. I also set a busy_timeout. Without it, a short lock turns into a hard failure.

// db.ts (Expo + expo-sqlite)
import * as SQLite from 'expo-sqlite';

export const db = SQLite.openDatabaseSync('gym.db');

export function initDb() {
  // WAL improves read/write concurrency.
  db.execSync('PRAGMA journal_mode = WAL;');

  // Wait up to 2 seconds when the DB is busy.
  db.execSync('PRAGMA busy_timeout = 2000;');

  // Durability vs speed. NORMAL is fine for app data.
  db.execSync('PRAGMA synchronous = NORMAL;');

  // Basic schema for set logging.
  db.execSync(`
    CREATE TABLE IF NOT EXISTS sets (
      id TEXT PRIMARY KEY NOT NULL,
      workout_id TEXT NOT NULL,
      exercise_id TEXT NOT NULL,
      reps INTEGER NOT NULL,
      weight_kg REAL NOT NULL,
      created_at_ms INTEGER NOT NULL
    );
    CREATE INDEX IF NOT EXISTS idx_sets_workout ON sets(workout_id, created_at_ms);
  `);
}

I learned the hard way that WAL isn’t “optional tuning”. If you’re doing offline-first + live search, you’re doing concurrent DB work. WAL makes that survivable.

2) I batch writes. One transaction. No drama.

My original implementation inserted one set per tap. One INSERT per tap. It worked… until I added auto-save for notes, timer ticks, and background sync metadata.

Then the lock errors got spicy.

The fix was boring. Batch writes inside a transaction. It reduces lock churn and fsync overhead. And it’s easier to retry.

This is the exact helper I use.

// writeBatch.ts
import { db } from './db';

type SetRow = {
  id: string;
  workoutId: string;
  exerciseId: string;
  reps: number;
  weightKg: number;
  createdAtMs: number;
};

export function insertSetsBatch(rows: SetRow[]) {
  if (rows.length === 0) return;

  db.withTransactionSync(() => {
    const stmt = db.prepareSync(
      `INSERT INTO sets (id, workout_id, exercise_id, reps, weight_kg, created_at_ms)
       VALUES (?, ?, ?, ?, ?, ?)`
    );

    try {
      for (const r of rows) {
        stmt.executeSync([
          r.id,
          r.workoutId,
          r.exerciseId,
          r.reps,
          r.weightKg,
          r.createdAtMs,
        ]);
      }
    } finally {
      stmt.finalizeSync();
    }
  });
}

This changed the feel immediately.

Not because batching is magic. Because I stopped forcing SQLite to constantly acquire/release locks while the UI is also querying.

3) I treat SQLITE_BUSY like a normal thing. Retry it.

Even with WAL + batching, you can still hit SQLITE_BUSY.

Example. User is scrolling exercise history (big query). At the same moment, they log a set. The write wants a lock. The read is still running. Boom.

busy_timeout helps. But I still saw failures on older Android devices.

So I added a tiny retry wrapper. Only for SQLITE_BUSY. Not for everything.

// retrySqliteBusy.ts
const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

export async function retrySqliteBusy(
  fn: () => T,
  opts: { retries?: number; baseDelayMs?: number } = {}
): Promise {
  const retries = opts.retries ?? 5;
  const baseDelayMs = opts.baseDelayMs ?? 20;

  let lastErr: unknown;

  for (let i = 0; i <= retries; i++) {
    try {
      return fn();
    } catch (e: any) {
      lastErr = e;
      const msg = String(e?.message ?? e);

      // expo-sqlite throws different shapes depending on platform.
      const isBusy = msg.includes('SQLITE_BUSY') || msg.includes('database is locked');
      if (!isBusy || i === retries) throw e;

      // Small exponential backoff.
      await sleep(baseDelayMs * Math.pow(2, i));
    }
  }

  throw lastErr;
}

I call it around the transaction.

Not everywhere. Just write paths.

I also log when it happens. If retries are constant, something else is wrong.

4) I measure the write path. Otherwise I’m guessing.

If you want sub-100ms UI, you can’t “feel” performance. You have to time it.

I added a timing wrapper around the batch insert. It prints duration and batch size.

This is how I caught a dumb mistake: I was inserting sets one-by-one again because my queue flush function split arrays wrong. Brutal.

// timedInsert.ts
import { insertSetsBatch } from './writeBatch';
import { retrySqliteBusy } from './retrySqliteBusy';

type SetRow = Parameters[0][number];

export async function insertSetsBatchTimed(rows: SetRow[]) {
  const t0 = global.performance?.now?.() ?? Date.now();

  await retrySqliteBusy(() => {
    insertSetsBatch(rows);
    return true;
  });

  const t1 = global.performance?.now?.() ?? Date.now();
  const ms = Math.round((t1 - t0) * 100) / 100;

  console.log(`[sqlite] inserted ${rows.length} sets in ${ms}ms`);
}

On my Pixel 7, a batch of 10 inserts is usually 2ms to 6ms. On an older Moto G (test device), it’s more like 8ms to 22ms.

More important: it doesn’t randomly fail anymore.

Results

Before WAL + batching, I could reproduce lock errors in under 60 seconds: start a workout, spam log 30 sets, then open history search in parallel. I’d see SQLITE_BUSY about 6 to 12 times per session.

After the changes, I did the same stress test for 20 minutes. I saw SQLITE_BUSY 2 times total, and both succeeded after 1 retry. No dropped set logs. No “tap again”.

Write timings also got predictable. My largest flush (48 set rows after an offline session) completed in 41ms on my slow Android test phone.

Key takeaways

Turn on WAL early. Startup code. Not “later”.
Use one transaction per flush. Not one insert per tap.
Add busy_timeout, then still handle SQLITE_BUSY with retries.
Time your writes and print batch size. You’ll catch dumb queue bugs fast.
If you’re seeing constant retries, you’ve got a long-running query somewhere. Fix that next.

Closing

If you’re using Expo SQLite: are you relying only on busy_timeout, or do you also retry SQLITE_BUSY in code with backoff?

Next.js job board: stable URLs for scraped jobs

Sathish — Tue, 07 Apr 2026 15:12:47 +0000

I generate stable job URLs from messy scraped data.
I avoid slug collisions with a deterministic hash.
I enforce uniqueness in Postgres, not in app code.
I handle “same job, new source URL” without 404s.

Context

My job board ingests 200+ jobs daily. Multiple sources. Same role. Different URLs. Different punctuation. Sometimes different company names too.

At first, I used a normal slug.

/jobs/psychiatric-nurse-practitioner-remote

Brutal idea.

I got collisions within a week. Two companies. Same title. Same city. Boom. Wrong job on the wrong page.

Then I tried “just append the company.” Still collisions. “Behavioral Health” vs “Behavioral-Health” vs “Behavioral Health Inc”. Scrapers aren’t polite.

So I switched to stable IDs. Deterministic. Based on a canonical fingerprint. Stored in Postgres. One URL per real-world job.

This post is that setup. Next.js 14 + Supabase + Postgres.

1) I stopped trusting slugs from scraped text

Slugs are for humans. IDs are for computers.

I still want readable URLs. But the stable part has to be machine-generated.

So I build two fields:

slug: pretty, derived from title + company
public_id: stable, derived from a fingerprint hash

public_id becomes the real key in the URL.

Here’s the exact function I use in my ingestion worker. Node runtime. No weird deps.

// lib/jobIdentity.ts
import crypto from "node:crypto";

export function slugify(input: string): string {
  return input
    .toLowerCase()
    .normalize("NFKD")
    .replace(/[\u0300-\u036f]/g, "") // strip accents
    .replace(/[^a-z0-9]+/g, "-")
    .replace(/(^-|-$)/g, "")
    .slice(0, 80);
}

// Keep it boring. Deterministic. No timestamps.
export function jobFingerprint(fields: {
  title: string;
  company: string;
  city?: string | null;
  state?: string | null;
  country?: string | null;
  employmentType?: string | null;
}): string {
  const norm = (s?: string | null) => (s ?? "").trim().toLowerCase();

  // Don't include source_url. It changes all the time.
  // Don't include salary. Scrapers lie.
  const payload = [
    norm(fields.title),
    norm(fields.company),
    norm(fields.city),
    norm(fields.state),
    norm(fields.country),
    norm(fields.employmentType),
  ].join("|");

  return crypto.createHash("sha256").update(payload).digest("hex");
}

export function publicIdFromFingerprint(fingerprint: string): string {
  // 12 bytes => 24 hex chars. Short enough for URLs.
  return fingerprint.slice(0, 24);
}

I learned the hard way that “include everything” makes IDs unstable.

If you put source_url into the hash, every time a site adds ?utm=..., you create a “new job”. Your listings inflate. Your dedupe fails silently.

2) I made the URL format boring on purpose

My job pages are:

/jobs/{public_id}/{slug}

The slug can change later. The public_id can’t.

That solves two things:

Collisions stop. public_id is unique.
Renames stop breaking links. Only the tail changes.

In Next.js App Router, I parse it like this.

// app/jobs/[publicId]/[slug]/page.tsx
import { notFound, redirect } from "next/navigation";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // server-only
);

function buildSlug(title: string, company: string) {
  return `${title} ${company}`
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, "-")
    .replace(/(^-|-$)/g, "")
    .slice(0, 80);
}

export default async function JobPage({
  params,
}: {
  params: Promise<{ publicId: string; slug: string }>;
}) {
  const { publicId, slug } = await params;

  const { data: job, error } = await supabase
    .from("jobs")
    .select("public_id,title,company,description,updated_at")
    .eq("public_id", publicId)
    .maybeSingle();

  if (error) throw error;
  if (!job) notFound();

  const canonicalSlug = buildSlug(job.title, job.company);
  if (slug !== canonicalSlug) {
    // Permanent canonicalization. Stops duplicate pages.
    redirect(`/jobs/${job.public_id}/${canonicalSlug}`);
  }

  return (

      # {job.title}

      {job.company}

      {job.description}

  );
}

Yeah, I’m using service role on the server.

If you don’t like that, use Supabase SSR helpers + RLS. I do that in other parts. For this page, I wanted predictable reads and zero client-side fetch.

Also: that redirect() is doing SEO work. It prevents /jobs/abc/old-slug from becoming a second indexed page.

3) I pushed uniqueness into Postgres, not my scraper

I tried to “dedupe in code.”

Spent 4 hours on this. Most of it was wrong.

Two workers ran at the same time. Same job. Both saw “not exists yet.” Both inserted. Classic race.

So I let Postgres do its job.

I store:

fingerprint (full sha256 hex)
public_id (short stable id)

And enforce uniqueness.

-- migrations/20260407_jobs_identity.sql
create extension if not exists pgcrypto;

create table if not exists jobs (
  id bigserial primary key,
  public_id text not null,
  fingerprint text not null,
  title text not null,
  company text not null,
  city text,
  state text,
  country text,
  employment_type text,
  source_url text,
  description text,
  posted_at timestamptz,
  updated_at timestamptz not null default now()
);

-- Stable identity
create unique index if not exists jobs_public_id_ux on jobs (public_id);
create unique index if not exists jobs_fingerprint_ux on jobs (fingerprint);

-- Helpful for common queries
create index if not exists jobs_updated_at_idx on jobs (updated_at desc);

Then ingestion becomes “upsert by fingerprint”.

If the job already exists, I update mutable fields like source_url, description, updated_at.

// scripts/ingestOne.ts
import { createClient } from "@supabase/supabase-js";
import {
  jobFingerprint,
  publicIdFromFingerprint,
  slugify,
} from "../lib/jobIdentity";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

type ScrapedJob = {
  title: string;
  company: string;
  city?: string | null;
  state?: string | null;
  country?: string | null;
  employmentType?: string | null;
  sourceUrl: string;
  description: string;
};

export async function ingestOne(j: ScrapedJob) {
  const fingerprint = jobFingerprint({
    title: j.title,
    company: j.company,
    city: j.city,
    state: j.state,
    country: j.country,
    employmentType: j.employmentType,
  });

  const publicId = publicIdFromFingerprint(fingerprint);

  const { error } = await supabase.from("jobs").upsert(
    {
      public_id: publicId,
      fingerprint,
      title: j.title,
      company: j.company,
      city: j.city ?? null,
      state: j.state ?? null,
      country: j.country ?? null,
      employment_type: j.employmentType ?? null,
      source_url: j.sourceUrl,
      description: j.description,
      updated_at: new Date().toISOString(),
    },
    {
      onConflict: "fingerprint", // the important part
    }
  );

  if (error) throw error;

  return {
    publicId,
    urlSlug: slugify(`${j.title} ${j.company}`),
  };
}

This is the whole trick.

I don’t care if 3 scrapers hit the same job. Postgres resolves it.

One thing that bit me: don’t use onConflict: "public_id".

If you ever change how you generate public_id (even accidentally), you’ll create duplicates. The fingerprint is the real identity. Keep that invariant.

4) I kept old URLs alive when the “identity” changes

Sometimes the fingerprint really does change.

Example: a source switches from “NYC” to “New York”. Or the company name gets normalized later. Or I fix a bug in my canonicalization.

If the fingerprint changes, public_id changes.

That’s a broken link.

So I store aliases. Old public_id values that redirect to the new one.

This saved me after I changed my normalization rules and accidentally invalidated 317 URLs. I noticed because my own smoke test started hitting 404.

Schema + redirect lookup.

-- migrations/20260407_job_aliases.sql
create table if not exists job_aliases (
  old_public_id text primary key,
  new_public_id text not null references jobs(public_id) on delete cascade,
  created_at timestamptz not null default now()
);

create index if not exists job_aliases_new_idx on job_aliases (new_public_id);

And in Next.js, I check aliases before I give up.

// app/jobs/[publicId]/[slug]/page.tsx
import { notFound, redirect } from "next/navigation";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

export default async function JobPage({
  params,
}: {
  params: Promise<{ publicId: string; slug: string }>;
}) {
  const { publicId, slug } = await params;

  const { data: job } = await supabase
    .from("jobs")
    .select("public_id,title,company,description")
    .eq("public_id", publicId)
    .maybeSingle();

  if (job) {
    const canonicalSlug = `${job.title} ${job.company}`
      .toLowerCase()
      .replace(/[^a-z0-9]+/g, "-")
      .replace(/(^-|-$)/g, "")
      .slice(0, 80);

    if (slug !== canonicalSlug) redirect(`/jobs/${job.public_id}/${canonicalSlug}`);
    return (

        # {job.title}

        {job.company}

        {job.description}

    );
  }

  // Not found? Try alias redirect.
  const { data: alias } = await supabase
    .from("job_aliases")
    .select("new_public_id")
    .eq("old_public_id", publicId)
    .maybeSingle();

  if (alias?.new_public_id) {
    redirect(`/jobs/${alias.new_public_id}/${slug}`); // slug will canonicalize next
  }

  notFound();
}

That last redirect looks weird. It is.

I redirect to the new public_id first, keeping whatever slug the user had. Then the canonical slug redirect runs. Two hops.

I kept it because it’s simple and it works.

If you want one hop, you can fetch the job by new_public_id and build the canonical URL immediately.

Results

Before stable IDs, I had 41 collisions in my jobs table in one week. Same slug. Different jobs. Users reported “this page changed overnight” twice. That was enough.

After switching to public_id + slug, collisions dropped to 0 because the URL key stopped being user-visible text. I also fixed 317 broken URLs after a normalization change by adding job_aliases redirects, instead of letting them 404.

The board is sitting at 8,000+ active listings from 2,000+ companies. URLs are boring now. That’s the point.

Key takeaways

Make the stable part of the URL deterministic, not pretty.
Hash a canonical fingerprint. Don’t hash source URLs.
Put uniqueness constraints in Postgres, or concurrency will humble you.
Treat slug as display-only. Enforce canonical redirects in Next.js.
When you change identity rules, keep aliases so old links still resolve.

Closing

If you’re scraping jobs (or listings, or products), URL stability becomes an SEO problem fast.

How do you build your fingerprint: which fields do you include, and which ones did you remove after getting burned by unstable IDs?

Cursor + Claude: stop shipping flaky UI states

Sathish — Thu, 02 Apr 2026 15:00:53 +0000

I use Cursor + Claude to generate state diagrams, not random code.
I convert UI states into a typed reducer. No more “boolean soup”.
I add 1 tiny invariant test that catches most regressions.
Works for Next.js, React, and even boring CRUD screens.

Context

I ship a lot of small SaaS apps. Usually solo. Usually fast.

And my UI bugs weren’t “hard.” They were dumb. The kind that shows up only after you add one more button.

Stuff like: loading spinner stays forever. Save button enables while a request is in flight. Error banner shows on the success screen. Or the classic: isLoading is false but you’re still “saving”.

I tried the usual.

A couple useStates. Then more. Then a useEffect to “sync” them. Brutal. Spent 4 hours on this once. Most of it was wrong.

Now I treat UI like a state machine. Not a library. Just a reducer and strict events.

Cursor + Claude help me do it fast. The trick: I don’t ask for code first. I ask for states.

1) I write the states down. Then I force Claude to agree

I start in Cursor. New file. Something like ui-state-notes.md.

I describe the screen in plain English. Then I ask Claude for a state table.

Not “write React code.”

I want a list of states and events. If the list is wrong, code won’t save me.

Here’s the exact prompt style I use (you can paste this into a Cursor chat). It’s boring on purpose.

You are my reviewer.
Given this UI, produce:
1) a list of mutually exclusive states
2) allowed events per state
3) forbidden transitions
4) 3 invariants that must always hold

UI:
- form with 3 fields
- Save triggers API call
- can show validation errors
- can show server error toast
- after success, show “Saved” and disable Save for 2s

No code yet. Only the table.

Then I sanity-check it like a grumpy QA.

If Claude gives me 12 states for a simple form, I push back. If it forgets “submit while already submitting”, I push back.

One thing that bit me early — Claude loves adding a retrying state. I almost never need it. I model retry as an event, not a state.

Once the table looks right, I freeze it. That’s my spec.

2) I kill boolean soup with a typed reducer

Most flaky screens I’ve seen have the same smell:

isLoading
isSaving
hasError
showSuccess
disabled

Five booleans. Thirty-two combinations. Half of them nonsense.

So I replace them with a discriminated union and a reducer.

This snippet is copy-paste ready. Plain React. Works in Next.js App Router too.

import * as React from "react";

type State =
  | { tag: "idle"; values: Record; fieldErrors: Record }
  | { tag: "submitting"; values: Record }
  | { tag: "success"; values: Record; lockedUntil: number }
  | { tag: "serverError"; values: Record; message: string };

type Event =
  | { type: "CHANGE"; name: string; value: string }
  | { type: "SUBMIT" }
  | { type: "VALIDATION_FAILED"; fieldErrors: Record }
  | { type: "SUBMIT_OK"; now: number }
  | { type: "SUBMIT_ERR"; message: string }
  | { type: "UNLOCK"; now: number };

export function reducer(state: State, event: Event): State {
  switch (state.tag) {
    case "idle": {
      if (event.type === "CHANGE") {
        return {
          tag: "idle",
          values: { ...state.values, [event.name]: event.value },
          fieldErrors: { ...state.fieldErrors, [event.name]: "" },
        };
      }
      if (event.type === "SUBMIT") return { tag: "submitting", values: state.values };
      if (event.type === "VALIDATION_FAILED") return { ...state, fieldErrors: event.fieldErrors };
      return state;
    }
    case "submitting": {
      if (event.type === "SUBMIT_OK") return { tag: "success", values: state.values, lockedUntil: event.now + 2000 };
      if (event.type === "SUBMIT_ERR") return { tag: "serverError", values: state.values, message: event.message };
      // Ignore changes while submitting. This is a product choice.
      return state;
    }
    case "success": {
      if (event.type === "UNLOCK" && event.now >= state.lockedUntil) {
        return { tag: "idle", values: state.values, fieldErrors: {} };
      }
      return state;
    }
    case "serverError": {
      if (event.type === "CHANGE") {
        return {
          tag: "serverError",
          values: { ...state.values, [event.name]: event.value },
          message: state.message,
        };
      }
      if (event.type === "SUBMIT") return { tag: "submitting", values: state.values };
      return state;
    }
  }
}

Notice what’s missing.

No isLoading. No showToast. No disabled state.

I derive UI behavior from state.tag.

And yeah, it feels slower at first. Then the second screen takes 15 minutes.

3) I wire the reducer to real async code (without useEffect spaghetti)

This is the part where I used to mess up.

I’d do:

set loading true
await
set loading false
set success

Then a request throws, and half the setters don’t run.

Reducer fixes that.

I dispatch events around the async boundary. One entry. One exit.

import * as React from "react";
import { reducer } from "./reducer";

type SaveInput = { values: Record };

async function saveToApi(input: SaveInput): Promise {
  const res = await fetch("/api/save", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify(input),
  });

  if (!res.ok) {
    // Common: API returns { message }
    const data = (await res.json().catch(() => ({}))) as { message?: string };
    throw new Error(data.message ?? `Request failed: ${res.status}`);
  }
}

export function SettingsForm() {
  const [state, dispatch] = React.useReducer(reducer, {
    tag: "idle",
    values: { name: "", email: "", company: "" },
    fieldErrors: {},
  });

  const onSubmit = async (e: React.FormEvent) => {
    e.preventDefault();

    if (state.tag !== "idle" && state.tag !== "serverError") return;

    // Tiny validation example. Keep it deterministic.
    const fieldErrors: Record = {};
    if (!state.values.email.includes("@")) fieldErrors.email = "Invalid email";
    if (Object.keys(fieldErrors).length) {
      dispatch({ type: "VALIDATION_FAILED", fieldErrors });
      return;
    }

    dispatch({ type: "SUBMIT" });

    try {
      await saveToApi({ values: state.values });
      dispatch({ type: "SUBMIT_OK", now: Date.now() });
    } catch (err) {
      dispatch({ type: "SUBMIT_ERR", message: err instanceof Error ? err.message : "Unknown error" });
    }
  };

  React.useEffect(() => {
    if (state.tag !== "success") return;
    const t = setInterval(() => dispatch({ type: "UNLOCK", now: Date.now() }), 200);
    return () => clearInterval(t);
  }, [state.tag]);

  const disabled = state.tag === "submitting" || (state.tag === "success" && Date.now() < state.lockedUntil);

  return (

       dispatch({ type: "CHANGE", name: "name", value: e.target.value })}
        disabled={disabled}
      />
       dispatch({ type: "CHANGE", name: "email", value: e.target.value })}
        disabled={disabled}
      />

        {state.tag === "submitting" ? "Saving…" : "Save"}

      {state.tag === "serverError" && {state.message}}
      {state.tag === "success" && Saved
}

  );
}

Yes, there’s a useEffect.

But it’s not “sync booleans.” It’s only for the timed unlock. And it’s scoped to one state.

Also. That disabled line is boring.

Boring is good.

4) I add one invariant test. It catches the dumb stuff

I don’t write a full test suite for every form. I’m not a hero.

But I do add one invariant test for reducers. Because reducers are pure. Cheap to test.

This one checks a rule I’ve broken multiple times: you can’t be success and submitting in the same flow, and success must have a future lockedUntil.

Node has a built-in test runner now. No Jest needed.

Create reducer.test.ts and run node --test --import tsx reducer.test.ts.

import test from "node:test";
import assert from "node:assert/strict";
import { reducer } from "./reducer";

test("success state always has a 2s lock", () => {
  const s1 = { tag: "submitting" as const, values: { name: "a" } };
  const now = 1712012345678;

  const s2 = reducer(s1, { type: "SUBMIT_OK", now });

  assert.equal(s2.tag, "success");
  if (s2.tag === "success") {
    assert.equal(s2.lockedUntil, now + 2000);
  }
});

test("SUBMIT_OK is ignored outside submitting", () => {
  const s1 = { tag: "idle" as const, values: { name: "a" }, fieldErrors: {} };
  const s2 = reducer(s1, { type: "SUBMIT_OK", now: 10 });
  assert.deepEqual(s2, s1);
});

That second test matters.

I once dispatched SUBMIT_OK from a stale promise after the user navigated away. UI went into a fake success state. Took me an hour to reproduce.

Now the reducer just ignores nonsense.

Results

On my last 3 screens built this way, I shipped with 4 reducer states (idle, submitting, success, serverError) and 6 events.

Before this approach, the same screens usually ended up with 7 booleans and 2 useEffects “keeping things in sync”. That’s where the bugs lived.

Also: debugging got faster. When something’s wrong, I log state.tag and the last event. That’s it. No more staring at React DevTools watching five flags flip.

Key takeaways

Don’t ask Claude for code first. Ask for a state/event table.
If you can’t explain the states in 60 seconds, the UI is too complex.
Replace multiple booleans with a discriminated union. Every time.
Dispatch events around async boundaries. One entry. One exit.
Add one invariant test for the reducer. Pure functions deserve cheap tests.

Closing

If you’re using Cursor + Claude, try this once.

Make Claude list states and forbidden transitions. Then write the reducer yourself, fast, inside Cursor.

What’s the one UI flow you keep breaking — settings form, onboarding, checkout, or something else — and what are the states you’d put in your reducer?

React Native offline-first: instant search in SQLite

Sathish — Wed, 01 Apr 2026 15:13:00 +0000

I ship offline exercise search with SQLite FTS5.
I keep typing smooth with a debounced query.
I highlight matches and rank results, fast.
I learned why %LIKE% is a trap on mobile.

Context

My fitness app has ~400 exercises. Each has a name, muscle group, and a GIF.

Search is the main screen. People open the app mid-workout. They type fast. They expect results instantly.

I started with LIKE '%query%' on a normal SQLite table. Brutal. It worked with 40 rows. Then I imported the real dataset. Typing dropped frames. My “5-second set logging” promise fell apart because the search screen felt sticky.

Also: offline-first. No server search. No Algolia. No “just hit an endpoint.”

So I moved search to SQLite FTS5. Same local DB. Real full-text index. And I stopped doing work on every keystroke.

1) I stopped using LIKE. I indexed.

LIKE feels simple. It’s also a full table scan when you wrap the query in %...%.

On a phone. While React is trying to render.

FTS5 fixed it. But only after I wired it correctly.

I keep a normal exercises table for the source of truth. Then an FTS virtual table for search. Then triggers to keep them in sync.

Code. This is the exact schema setup.

// db/schema.ts
import * as SQLite from "expo-sqlite";

export async function initDb(db: SQLite.SQLiteDatabase) {
  // Base table
  await db.execAsync(`
    PRAGMA journal_mode = WAL;

    CREATE TABLE IF NOT EXISTS exercises (
      id INTEGER PRIMARY KEY NOT NULL,
      name TEXT NOT NULL,
      primary_muscle TEXT NOT NULL,
      equipment TEXT NOT NULL
    );

    -- Full-text index. content=exercises lets us join back.
    CREATE VIRTUAL TABLE IF NOT EXISTS exercises_fts
    USING fts5(
      name,
      primary_muscle,
      equipment,
      content='exercises',
      content_rowid='id',
      tokenize='unicode61 remove_diacritics 2'
    );

    -- Keep FTS in sync.
    CREATE TRIGGER IF NOT EXISTS exercises_ai AFTER INSERT ON exercises BEGIN
      INSERT INTO exercises_fts(rowid, name, primary_muscle, equipment)
      VALUES (new.id, new.name, new.primary_muscle, new.equipment);
    END;

    CREATE TRIGGER IF NOT EXISTS exercises_ad AFTER DELETE ON exercises BEGIN
      INSERT INTO exercises_fts(exercises_fts, rowid, name, primary_muscle, equipment)
      VALUES ('delete', old.id, old.name, old.primary_muscle, old.equipment);
    END;

    CREATE TRIGGER IF NOT EXISTS exercises_au AFTER UPDATE ON exercises BEGIN
      INSERT INTO exercises_fts(exercises_fts, rowid, name, primary_muscle, equipment)
      VALUES ('delete', old.id, old.name, old.primary_muscle, old.equipment);
      INSERT INTO exercises_fts(rowid, name, primary_muscle, equipment)
      VALUES (new.id, new.name, new.primary_muscle, new.primary_muscle, new.equipment);
    END;
  `);
}

Yes, I made a dumb mistake there the first time.

I had new.primary_muscle twice (copy/paste brain). Search results were “fine” but equipment filtering was wrong. Spent 2 hours thinking FTS was broken. It was me.

Also: WAL matters. Without it, I hit random “database is locked” during writes + reads. WAL reduced that pain a lot.

2) I query FTS5 like a grown-up

FTS query syntax is not SQL LIKE.

I want prefix matching. If someone types ben, I want bench press.

FTS does that with *. So I build ben*.

But. If you shove raw user input into FTS, you’ll get parser errors.

I hit this exact error:

SQLITE_ERROR: fts5: syntax error near "-"

Someone typed t-bar.

So I sanitize. And I keep the query small.

// db/search.ts
import * as SQLite from "expo-sqlite";

function ftsPrefixQuery(input: string) {
  // Keep letters/numbers/spaces. Drop punctuation that breaks FTS.
  const cleaned = input
    .toLowerCase()
    .replace(/[^a-z0-9\s]/g, " ")
    .trim();

  if (!cleaned) return "";

  // "bench press" -> "bench* press*"
  return cleaned
    .split(/\s+/)
    .filter(Boolean)
    .map((t) => `${t}*`)
    .join(" ");
}

export async function searchExercises(
  db: SQLite.SQLiteDatabase,
  input: string,
  limit = 30
) {
  const q = ftsPrefixQuery(input);
  if (!q) return [] as any[];

  // bm25() gives decent ranking for free.
  const rows = await db.getAllAsync(
    `
    SELECT e.id, e.name, e.primary_muscle, e.equipment,
           bm25(exercises_fts) AS rank
    FROM exercises_fts
    JOIN exercises e ON e.id = exercises_fts.rowid
    WHERE exercises_fts MATCH ?
    ORDER BY rank
    LIMIT ?;
    `,
    [q, limit]
  );

  return rows;
}

bm25() is underrated. I used to hand-roll scoring. Total waste.

And yes, I sort ascending. Smaller bm25 score ranks higher.

One more thing that bit me — FTS tokenization.

If your dataset has incline bench and users type inclined, stemming won’t happen by default. SQLite FTS5 doesn’t magically do stemming unless you add a tokenizer that supports it. I didn’t. I accepted it. I’d rather be predictable than “smart” and wrong.

3) I debounced typing. Otherwise you DDOS your own DB

Even with FTS, doing a query on every keystroke is noisy.

React Native renders. The keyboard fires events. Your JS thread gets busy. Then you blame SQLite.

I debounce at 120ms. Not 500ms. That feels laggy.

And I cancel stale requests so results don’t flicker.

// hooks/useDebouncedValue.ts
import { useEffect, useState } from "react";

export function useDebouncedValue(value: T, delayMs: number) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delayMs);
    return () => clearTimeout(id);
  }, [value, delayMs]);

  return debounced;
}

// screens/ExerciseSearchScreen.tsx
import React, { useEffect, useMemo, useState } from "react";
import { Text, TextInput, View, FlatList } from "react-native";
import * as SQLite from "expo-sqlite";
import { useDebouncedValue } from "../hooks/useDebouncedValue";
import { searchExercises } from "../db/search";

const db = SQLite.openDatabaseSync("gym.db");

export function ExerciseSearchScreen() {
  const [text, setText] = useState("");
  const debounced = useDebouncedValue(text, 120);
  const [rows, setRows] = useState([]);

  // Simple request id. Prevent stale async updates.
  const requestIdRef = React.useRef(0);

  useEffect(() => {
    let alive = true;
    const reqId = ++requestIdRef.current;

    (async () => {
      if (!debounced.trim()) {
        setRows([]);
        return;
      }
      const res = await searchExercises(db, debounced, 30);
      if (!alive) return;
      if (reqId !== requestIdRef.current) return;
      setRows(res);
    })();

    return () => {
      alive = false;
    };
  }, [debounced]);

  const renderItem = ({ item }: { item: any }) => (

      {item.name}

        {item.primary_muscle} • {item.equipment}


  );

  return (



       String(x.id)}
        renderItem={renderItem}
      />

  );
}

This is boring code. Good.

Before debounce, I could see 20+ queries in a second while typing. After debounce, it’s usually 4–6 queries for a typical search.

And the UI stopped feeling “wet.” You know that feeling. Like you’re dragging the app through mud.

4) I highlight matches without doing fancy stuff

People scan.

If I show bench press and they typed ben, their eyes want confirmation.

FTS5 can return offsets via offsets() but parsing that output is annoying. I tried. Spent 4 hours on it. Most of it was wrong.

I went simpler: highlight prefix matches in the UI using the debounced input tokens. It’s not perfect, but it’s stable and fast.

// ui/highlight.tsx
import React from "react";
import { Text } from "react-native";

export function HighlightedText({ text, query }: { text: string; query: string }) {
  const tokens = query
    .toLowerCase()
    .replace(/[^a-z0-9\s]/g, " ")
    .trim()
    .split(/\s+/)
    .filter(Boolean);

  if (!tokens.length) return {text};

  // Highlight only the first token prefix. Simple. Predictable.
  const t0 = tokens[0];
  const lower = text.toLowerCase();
  const idx = lower.indexOf(t0);

  if (idx === -1) return {text};

  return (

      {text.slice(0, idx)}
      {text.slice(idx, idx + t0.length)}
      {text.slice(idx + t0.length)}

  );
}

Does it highlight the second word? Nope.

But it avoids a class of bugs where the highlight logic fights the ranking logic. I’ll take “good enough” when the main goal is speed.

Results

I went from a LIKE query that routinely took 120–300ms on my Pixel 7 (and sometimes spiked to ~600ms) to an FTS query that’s usually 8–25ms for the same input.

The bigger win was UI feel.

With debounce at 120ms, typing bench press triggers 5 queries instead of 11. The search screen stays at 60fps on my iPhone 13 mini, even with the exercise list rendering 30 rows and each row showing muscle + equipment.

And offline still works. Airplane mode. Same experience.

Key takeaways

Don’t use %LIKE% for mobile search beyond toy datasets.
Use FTS5 with content='table' + triggers so you don’t duplicate data.
Sanitize user input or you’ll ship fts5: syntax error near "-".
Debounce at ~120ms and cancel stale requests. Otherwise results flicker.
Keep highlighting dumb. Stable beats clever.

Closing

If you’re doing offline-first search in React Native: do you rely on SQLite FTS ranking (bm25) only, or do you add your own scoring (muscle match, equipment match, recency) on top of it? What’s your exact formula?

Cursor + Claude: stop shipping broken auth flows

Sathish — Thu, 26 Mar 2026 15:00:49 +0000

I use Cursor + Claude to generate auth code, then I try to break it.
I run a tiny Node script to fuzz cookies + headers.
I lock session handling into one file. No scattered reads.
I add 3 tests that catch 80% of my dumb mistakes.

Context

I ship small SaaS apps. Usually fast. Usually solo.

Auth is where I bleed time. Not because OAuth is hard. Because I miss boring edge cases.

Cursor + Claude help me write the first draft. Fast. But the first draft lies. It’ll “work” in the happy path. Then I open a second tab, log out, and something still looks logged in.

Spent 4 hours last month on a “random logout” bug. Most of it was wrong. The root cause: I was reading the session in 3 different places, each with slightly different assumptions.

So I switched to a workflow: generate → centralize → fuzz → test. Same steps every time.

1) I force all session reads through one function

If I read cookies in five files, I’m done.

One module. One exported function. Everything else calls that.

In Next.js App Router, I do it in lib/session.ts. Server-only.

// lib/session.ts
import { cookies, headers } from "next/headers";

export type Session = {
  userId: string;
  email: string;
  roles: string[];
  expiresAt: number; // unix ms
};

// Example: cookie contains base64url(JSON). Swap with real signed token.
function base64UrlToString(input: string) {
  const pad = "=".repeat((4 - (input.length % 4)) % 4);
  const b64 = (input + pad).replace(/-/g, "+").replace(/_/g, "/");
  return Buffer.from(b64, "base64").toString("utf8");
}

export function getSession(): Session | null {
  // Single source of truth.
  const token = cookies().get("session")?.value;
  if (!token) return null;

  try {
    const json = base64UrlToString(token);
    const parsed = JSON.parse(json) as Session;

    // Hard checks. No vibes.
    if (!parsed.userId) return null;
    if (!parsed.email) return null;
    if (!Array.isArray(parsed.roles)) return null;
    if (typeof parsed.expiresAt !== "number") return null;
    if (Date.now() > parsed.expiresAt) return null;

    // Optional: bind to user-agent to reduce replay.
    const ua = headers().get("user-agent") || "";
    if (ua.length === 0) return null;

    return parsed;
  } catch {
    return null;
  }
}

This snippet isn’t “secure auth”. It’s structure.

The point: every request goes through the same gates. If I change cookie format, I change one file.

One thing that bit me — Cursor happily generated JSON.parse(cookies().get(...)) with no try/catch. That crashed rendering for anyone with a stale cookie.

2) I make middleware do one job: block obvious bad routes

I used to do too much in middleware.

Then I got stuck in redirect loops. Brutal.

Now middleware only answers: “Can this request touch /app?” It doesn’t fetch user profiles. It doesn’t refresh tokens. It doesn’t call Supabase.

// middleware.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(req: NextRequest) {
  const { pathname, searchParams } = req.nextUrl;

  // Only protect app routes.
  if (!pathname.startsWith("/app")) return NextResponse.next();

  const hasSessionCookie = req.cookies.has("session");
  if (hasSessionCookie) return NextResponse.next();

  const loginUrl = req.nextUrl.clone();
  loginUrl.pathname = "/login";
  loginUrl.searchParams.set("next", pathname + (searchParams.size ? `?${searchParams}` : ""));

  return NextResponse.redirect(loginUrl);
}

export const config = {
  matcher: ["/app/:path*"],
};

That’s it.

Why so dumb-simple? Because I can reason about it when I’m tired.

Also: middleware runs on Edge by default. Half the Node APIs aren’t there. Cursor will still generate code that uses crypto in middleware and you’ll get a fun error like:

Module not found: Can't resolve 'crypto'

So I keep middleware boring. Server-only logic stays server-only.

3) I fuzz my auth endpoints with a 30-line script

This is the part that changed everything.

I don’t wait for “a user reported it.” I try to break my own app.

I keep a script in scripts/fuzz-auth.mjs. It hits a few routes with:

no cookie
garbage cookie
expired cookie
huge cookie

It catches crashes. It catches accidental 200s. It catches HTML pages returning JSON errors.

// scripts/fuzz-auth.mjs
const base = process.env.BASE_URL || "http://localhost:3000";

const cases = [
  { name: "no cookie", cookie: null },
  { name: "garbage", cookie: "session=lol-nope" },
  { name: "expired-ish", cookie: "session=ZXhwaXJlZA" },
  { name: "huge", cookie: "session=" + "a".repeat(9000) },
];

const paths = ["/app", "/app/settings", "/api/me"]; // adjust for your app

for (const p of paths) {
  for (const c of cases) {
    const res = await fetch(base + p, {
      redirect: "manual",
      headers: c.cookie ? { cookie: c.cookie } : {},
    });

    const ct = res.headers.get("content-type") || "";
    console.log(`${p} | ${c.name} | ${res.status} | ${ct.split(";")[0]}`);

    // If your API routes should never return HTML, enforce it.
    if (p.startsWith("/api") && ct.includes("text/html")) {
      process.exitCode = 1;
    }

    // Catch server crashes disguised as 200.
    if (res.status >= 500) {
      process.exitCode = 1;
    }
  }
}

Run it like:

BASE_URL=http://localhost:3000 node scripts/fuzz-auth.mjs

This is where Claude helps a lot.

I paste the console output. I paste the route code. I ask: “Why is /api/me returning HTML for garbage cookies?” Then I fix the actual bug.

But I don’t let it rewrite everything. I tell it: keep the shape, change the smallest surface area.

4) I add 3 tests. Only 3. They’re mean.

I don’t write 40 auth tests. I won’t maintain them.

I write three that stop the bleeding:
1) protected page redirects when no cookie
2) API returns 401 JSON when no cookie
3) API returns 401 JSON when cookie is invalid

In App Router, I like testing the session parser directly. It’s stable and fast.

Here’s a Vitest unit test for the token decoding logic. I keep it pure by extracting decode into a helper.

// lib/session-decode.ts
export type Session = {
  userId: string;
  email: string;
  roles: string[];
  expiresAt: number;
};

function base64UrlToString(input: string) {
  const pad = "=".repeat((4 - (input.length % 4)) % 4);
  const b64 = (input + pad).replace(/-/g, "+").replace(/_/g, "/");
  return Buffer.from(b64, "base64").toString("utf8");
}

export function decodeSessionCookie(token: string): Session | null {
  try {
    const json = base64UrlToString(token);
    const parsed = JSON.parse(json) as Session;
    if (!parsed.userId) return null;
    if (!parsed.email) return null;
    if (!Array.isArray(parsed.roles)) return null;
    if (typeof parsed.expiresAt !== "number") return null;
    if (Date.now() > parsed.expiresAt) return null;
    return parsed;
  } catch {
    return null;
  }
}

// test/session-decode.test.ts
import { describe, it, expect } from "vitest";
import { decodeSessionCookie } from "../lib/session-decode";

function toBase64Url(s: string) {
  return Buffer.from(s, "utf8")
    .toString("base64")
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/g, "");
}

describe("decodeSessionCookie", () => {
  it("returns null for garbage", () => {
    expect(decodeSessionCookie("lol-nope")).toBeNull();
  });

  it("returns null for expired", () => {
    const token = toBase64Url(
      JSON.stringify({
        userId: "u1",
        email: "a@b.com",
        roles: ["user"],
        expiresAt: Date.now() - 1,
      })
    );
    expect(decodeSessionCookie(token)).toBeNull();
  });

  it("parses a valid session", () => {
    const token = toBase64Url(
      JSON.stringify({
        userId: "u1",
        email: "a@b.com",
        roles: ["user"],
        expiresAt: Date.now() + 60_000,
      })
    );
    const s = decodeSessionCookie(token);
    expect(s?.userId).toBe("u1");
    expect(s?.roles).toEqual(["user"]);
  });
});

Yeah, it’s “just parsing”.

But it stops regressions when I change cookie structure. And Claude is good at suggesting extra assertions without turning the test into a novel.

Results

On my last build week, I shipped auth changes on 6 different days. Real life.

Before this workflow, I’d usually find 2 or 3 auth regressions per week. Stuff like: /api/me returning a 500 for a bad cookie, or a protected page rendering and then redirecting client-side.

After centralizing session reads + adding the fuzz script + the 3 tests, I hit 0 auth-related 500s locally across 27 fuzz runs (3 paths × 4 cases × reruns while fixing). And I stopped seeing redirect loops entirely because middleware stopped doing “smart” things.

Not magic. Just fewer moving parts.

Key takeaways

Put all cookie/session reads in one server-only module.
Keep middleware dumb: allow/deny + redirect only.
Fuzz auth with a script. It’s faster than clicking.
Add 3 unit tests that you’ll actually maintain.
When Claude writes auth code, assume it forgot the unhappy path.

Closing

If you already use Cursor + Claude for auth, don’t ask it for “secure auth”. Ask it for smaller, testable pieces.

What’s the one fuzz case you run against your auth routes that caught a real bug (cookie size, invalid JWT, missing headers, double-submit, something else)?

React Native offline-first: conflict rules in SQLite

Sathish — Wed, 25 Mar 2026 15:01:24 +0000

I stopped “last write wins” from nuking offline edits.
I model conflicts with base_rev + rev in SQLite.
I sync with 1 endpoint: pull then push.
I ship deterministic merges for workout sets.

Context

My fitness app has one job.
Log a set in ~5 seconds.
No spinner.
No “retry later”.

Offline-first forced me into SQLite.
AsyncStorage died fast.
I need queries like “last 12 sets for this exercise” in under 100ms.
And I need sync.

I shipped a naive sync first.
It was brutal.
Two devices editing the same workout would randomly overwrite each other.
Sometimes it looked fine.
Then you’d refresh.
Poof.
Half the sets gone.

So I rebuilt it around conflict rules.
Not “hope”.
Rules I can test.
Rules SQLite can enforce.

1) I store revisions per row. Not timestamps.

Timestamps lied to me.
Device clocks drift.
Also, two updates can share the same millisecond.
And I don’t want “latest” anyway.
I want “what was this row based on?”

So every row gets:

rev (server-assigned integer)
base_rev (what the client last saw)
updated_at (still useful for UI)

On create, rev = 0.
Server assigns real rev later.

Here’s the SQLite schema I ended up keeping.
It’s small.
But it fixed the mental model.

-- schema.sql (SQLite)
PRAGMA foreign_keys = ON;

CREATE TABLE IF NOT EXISTS sets (
  id TEXT PRIMARY KEY,              -- uuid
  workout_id TEXT NOT NULL,
  exercise_id TEXT NOT NULL,
  reps INTEGER NOT NULL,
  weight REAL NOT NULL,
  created_at INTEGER NOT NULL,       -- unix ms
  updated_at INTEGER NOT NULL,       -- unix ms

  rev INTEGER NOT NULL DEFAULT 0,    -- server revision, 0 = not on server yet
  base_rev INTEGER NOT NULL DEFAULT 0,
  deleted INTEGER NOT NULL DEFAULT 0,

  CHECK (deleted IN (0, 1))
);

CREATE INDEX IF NOT EXISTS idx_sets_workout
ON sets(workout_id, deleted, updated_at);

CREATE TABLE IF NOT EXISTS outbox (
  id TEXT PRIMARY KEY,              -- uuid for the op
  entity TEXT NOT NULL,             -- 'sets'
  entity_id TEXT NOT NULL,          -- sets.id
  op TEXT NOT NULL,                 -- 'upsert' | 'delete'
  payload TEXT NOT NULL,            -- JSON string
  base_rev INTEGER NOT NULL,
  created_at INTEGER NOT NULL
);

CREATE INDEX IF NOT EXISTS idx_outbox_created
ON outbox(created_at);

That base_rev in the outbox is the whole point.
It’s the receipt.
It tells the server what I edited against.

2) Every local write also writes an outbox op

I wanted “offline-first”.
I accidentally built “offline-only” for a day.
Because my UI wrote to SQLite.
But I forgot to queue ops.
Sync ran.
Nothing pushed.
Looked fine locally.
Server stayed stale.

Now I don’t allow a write without an outbox row.
Same transaction.
All-or-nothing.

I’m using Expo’s SQLite.
This code runs.
Copy-paste.
It’s the exact pattern I use for set logging.

// db/upsertSet.ts
import * as SQLite from 'expo-sqlite';
import { randomUUID } from 'expo-crypto';

const db = SQLite.openDatabaseSync('gym.db');

type SetRow = {
  id?: string;
  workout_id: string;
  exercise_id: string;
  reps: number;
  weight: number;
};

export function upsertSetLocal(input: SetRow) {
  const now = Date.now();
  const id = input.id ?? randomUUID();

  db.withTransactionSync(() => {
    // Read current base_rev so the server can detect conflicts.
    const cur = db.getFirstSync<{ rev: number }>(
      'SELECT rev FROM sets WHERE id = ? LIMIT 1',
      [id]
    );
    const baseRev = cur?.rev ?? 0;

    db.runSync(
      `INSERT INTO sets (id, workout_id, exercise_id, reps, weight, created_at, updated_at, rev, base_rev, deleted)
       VALUES (?, ?, ?, ?, ?, ?, ?, COALESCE((SELECT rev FROM sets WHERE id = ?), 0), ?, 0)
       ON CONFLICT(id) DO UPDATE SET
         reps = excluded.reps,
         weight = excluded.weight,
         updated_at = excluded.updated_at,
         base_rev = excluded.base_rev,
         deleted = 0`,
      [
        id,
        input.workout_id,
        input.exercise_id,
        input.reps,
        input.weight,
        now,
        now,
        id,
        baseRev
      ]
    );

    db.runSync(
      `INSERT INTO outbox (id, entity, entity_id, op, payload, base_rev, created_at)
       VALUES (?, 'sets', ?, 'upsert', ?, ?, ?)`,
      [
        randomUUID(),
        id,
        JSON.stringify({ ...input, id, updated_at: now }),
        baseRev,
        now
      ]
    );
  });

  return id;
}

Two things I learned the hard way:
1) If you don’t do this in a transaction, you’ll eventually enqueue an op without the row (or vice versa).
2) Don’t build the payload from the UI state. Build it from what you wrote.

3) Sync is pull-then-push. Always in that order.

I tried push-first.
Bad call.
If you push against an old server state, you create conflicts you didn’t need.

My sync loop is:
1) Pull server changes since last_server_rev.
2) Apply them locally.
3) Push outbox ops.
4) Update last_server_rev.

I store last_server_rev in a tiny meta table.
Could be SecureStore.
I kept it in SQLite so it survives reinstalls with backups.

Here’s the sync function.
It’s trimmed.
But it’s real.

// sync/syncNow.ts
import * as SQLite from 'expo-sqlite';

const db = SQLite.openDatabaseSync('gym.db');

type PullResponse = {
  latestRev: number;
  changes: Array<{
    id: string;
    workout_id: string;
    exercise_id: string;
    reps: number;
    weight: number;
    updated_at: number;
    rev: number;
    deleted: number;
  }>;
};

async function apiPost(path: string, body: unknown): Promise {
  const res = await fetch(`https://api.example.com${path}`, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify(body)
  });
  if (!res.ok) throw new Error(`HTTP ${res.status} ${await res.text()}`);
  return res.json() as Promise;
}

export async function syncNow(userId: string) {
  const meta = db.getFirstSync<{ value: string }>(
    'SELECT value FROM meta WHERE key = ? LIMIT 1',
    ['last_server_rev']
  );
  const sinceRev = meta ? Number(meta.value) : 0;

  const pulled = await apiPost('/sync/pull', { userId, sinceRev });

  // Apply server changes.
  db.withTransactionSync(() => {
    for (const c of pulled.changes) {
      db.runSync(
        `INSERT INTO sets (id, workout_id, exercise_id, reps, weight, created_at, updated_at, rev, base_rev, deleted)
         VALUES (?, ?, ?, ?, ?, COALESCE((SELECT created_at FROM sets WHERE id = ?), ?), ?, ?, ?, ?)
         ON CONFLICT(id) DO UPDATE SET
           workout_id = excluded.workout_id,
           exercise_id = excluded.exercise_id,
           reps = excluded.reps,
           weight = excluded.weight,
           updated_at = excluded.updated_at,
           rev = excluded.rev,
           deleted = excluded.deleted`,
        [
          c.id,
          c.workout_id,
          c.exercise_id,
          c.reps,
          c.weight,
          c.id,
          c.updated_at,
          c.updated_at,
          c.rev,
          c.rev,
          c.deleted
        ]
      );
    }

    db.runSync(
      `INSERT INTO meta (key, value)
       VALUES ('last_server_rev', ?)
       ON CONFLICT(key) DO UPDATE SET value = excluded.value`,
      [String(pulled.latestRev)]
    );
  });

  // Push after pull.
  await pushOutbox(userId);
}

async function pushOutbox(userId: string) {
  const ops = db.getAllSync<{ id: string; entity_id: string; op: string; payload: string; base_rev: number }>(
    'SELECT id, entity_id, op, payload, base_rev FROM outbox ORDER BY created_at ASC LIMIT 50'
  );
  if (ops.length === 0) return;

  const res = await apiPost<{ acked: string[]; conflicts: string[] }>('/sync/push', {
    userId,
    ops: ops.map(o => ({ ...o, payload: JSON.parse(o.payload) }))
  });

  db.withTransactionSync(() => {
    for (const ackId of res.acked) {
      db.runSync('DELETE FROM outbox WHERE id = ?', [ackId]);
    }
  });

  // Conflicts handled in the next section.
}

Real bug I hit:
HTTP 413 Payload Too Large.
Because I tried to push 2,000 ops in one request.
Now it’s LIMIT 50.
Boring.
Works.

4) Conflicts: I don’t “merge” everything. I pick winners.

I wanted fancy merges.
Like Git.
For workout sets.
Why.

Sets are append-heavy.
Conflicts mostly happen on edits.
Like changing weight from 185 to 195.
If two devices edit the same set, I don’t want an average.
I want a deterministic rule.

My rule:

If the server row rev equals the op’s base_rev, accept.
Else, conflict.
For conflicts, keep the server version.
But keep the client edit as a new set row (duplicate) with a note.

That last part sounds weird.
It is.
But it avoids silent data loss.
And it’s visible in the UI.
I’d rather show “(from offline edit)” than delete someone’s work.

This is the server-side SQL check.
Postgres in my case.
But the logic is universal.

-- Server-side (Postgres) apply op with optimistic concurrency
-- Table: sets(id pk, reps, weight, rev int, deleted bool, updated_at bigint)

-- Given: :id, :reps, :weight, :base_rev

UPDATE sets
SET reps = :reps,
    weight = :weight,
    updated_at = :updated_at,
    rev = rev + 1,
    deleted = false
WHERE id = :id
  AND rev = :base_rev
  AND deleted = false;

-- If rowCount = 0 => conflict (someone else changed it)

And here’s how I handle the conflict on the client.
This part took me 4 hours.
Most of it was wrong.
I kept trying to “auto-resolve”.
It just made it harder to reason about.

// sync/handleConflicts.ts
import * as SQLite from 'expo-sqlite';
import { randomUUID } from 'expo-crypto';

const db = SQLite.openDatabaseSync('gym.db');

export function materializeConflictAsNewSet(entityId: string) {
  const row = db.getFirstSync(
    'SELECT * FROM sets WHERE id = ? LIMIT 1',
    [entityId]
  );
  if (!row) return;

  const now = Date.now();
  const newId = randomUUID();

  db.withTransactionSync(() => {
    // Keep server row as-is. Create a new local row with the client's values.
    // rev=0 so it will be treated as a new create on next sync.
    db.runSync(
      `INSERT INTO sets (id, workout_id, exercise_id, reps, weight, created_at, updated_at, rev, base_rev, deleted)
       VALUES (?, ?, ?, ?, ?, ?, ?, 0, 0, 0)`,
      [
        newId,
        row.workout_id,
        row.exercise_id,
        row.reps,
        row.weight,
        now,
        now
      ]
    );

    db.runSync(
      `INSERT INTO outbox (id, entity, entity_id, op, payload, base_rev, created_at)
       VALUES (?, 'sets', ?, 'upsert', ?, 0, ?)`,
      [
        randomUUID(),
        newId,
        JSON.stringify({
          id: newId,
          workout_id: row.workout_id,
          exercise_id: row.exercise_id,
          reps: row.reps,
          weight: row.weight,
          updated_at: now,
          note: 'conflict_copy'
        }),
        now
      ]
    );
  });
}

Is it perfect?
No.
But it’s honest.
No silent overwrite.
No “maybe it synced”.

And the UI stays fast.
Because conflicts are rare.
And when they happen, I can show a banner.

Results

Before this, I could reproduce data loss in 6 steps.
Two devices.
Airplane mode.
Edit the same set.
Sync both.
One edit vanished.
Every time.

After the revision + base revision change, I ran 30 conflict simulations.
15 “same set edited on both devices”.
15 “delete on one, edit on the other”.
I got 30 deterministic outcomes.
Zero silent overwrites.

Perf stayed fine.
On a 3-year-old Android device, upsertSetLocal() took 4–12ms per log in my profiling.
The UI stayed under my 100ms budget.

Key takeaways

Don’t use timestamps for conflict resolution. Use integer revisions.
Every local mutation needs an outbox op in the same transaction.
Sync order matters: pull first, then push.
“Server wins” is acceptable if you preserve the client edit visibly.
Keep your rules testable. If you can’t write a 6-step repro, you’re guessing.

Closing

I’m still not happy with the conflict UI.
It’s functional.
It’s not pretty.

If you’ve shipped offline-first sync in React Native: when you hit a conflict, do you surface a “choose version” screen, or do you do deterministic rules like I’m doing here?

Next.js job board search: Postgres FTS + trgm

Sathish — Tue, 24 Mar 2026 15:02:10 +0000

My job board has 8,000+ listings. Basic ILIKE died fast.
I combined Postgres full-text search with pg_trgm for typos.
I rank results with a single SQL function. No app-side scoring.
I ship it via Supabase RPC + a simple Next.js route.

Context

I’m building a job board for Psychiatric Mental Health Nurse Practitioners.

Search is the whole product.
If search feels dumb, users bounce.

I started with ILIKE '%term%'.
It worked for 200 listings.
Then I crossed ~8,000 active listings and it got brutal.
Slow queries. Weird ranking. Typos returning nothing.

I didn’t want Elasticsearch.
Not for this.
I already have Postgres (Supabase). So I leaned into it.

Goal: fast search, decent ranking, typo tolerance.
And something I can maintain solo.

1) I stopped doing `ILIKE`. It’s a trap.

ILIKE is fine for admin screens.
Not for user-facing search.

Two problems hit me.

First: performance.
ILIKE '%remote%' can’t use a normal btree index.
It scans.

Second: ranking.
Everything matches the same.
A job with “Remote” once beats a job with “Remote PMHNP” everywhere.

So I moved to two signals:

Full-text search for “real” matching.
Trigram similarity for typos and partials.

Here’s the schema change I actually run.
Generated columns. Indexed. Boring. Reliable.

-- 1) Extensions for search
create extension if not exists pg_trgm;

-- (optional but common)
create extension if not exists unaccent;

-- 2) Columns used by search
alter table public.jobs
  add column if not exists search_tsv tsvector
  generated always as (
    setweight(to_tsvector('english', coalesce(title, '')), 'A') ||
    setweight(to_tsvector('english', coalesce(company_name, '')), 'B') ||
    setweight(to_tsvector('english', coalesce(location, '')), 'C') ||
    setweight(to_tsvector('english', coalesce(description, '')), 'D')
  ) stored;

-- 3) Indexes
create index if not exists jobs_search_tsv_gin
  on public.jobs using gin (search_tsv);

create index if not exists jobs_title_trgm_gin
  on public.jobs using gin (title gin_trgm_ops);

create index if not exists jobs_company_trgm_gin
  on public.jobs using gin (company_name gin_trgm_ops);

One thing that bit me — generated columns are only as good as your inputs.
I had a scraper bug that wrote empty company_name for 312 rows.
Search looked “random” until I fixed data quality.
Not glamorous.

2) I rank with one SQL function. No client math.

I want one call.
Query in. Rows out.

Also: consistent ranking.
If I score in TypeScript, I’ll change it three times and forget why.
SQL keeps me honest.

This is the function.
It returns a score.
It blends:

ts_rank_cd for FTS ranking.
similarity() for typo-ish matching.

And I clamp it.
Because trigram scores can dominate when the query is short.
“ny” matched half the planet.

create or replace function public.search_jobs(
  q text,
  limit_count int default 25,
  offset_count int default 0
)
returns table (
  id uuid,
  title text,
  company_name text,
  location text,
  url text,
  posted_at timestamptz,
  score real
)
language sql
stable
as $$
  with params as (
    select
      websearch_to_tsquery('english', q) as tsq,
      greatest(length(trim(q)), 0) as qlen
  )
  select
    j.id,
    j.title,
    j.company_name,
    j.location,
    j.url,
    j.posted_at,
    (
      -- full-text score
      (ts_rank_cd(j.search_tsv, p.tsq) * 1.0)
      +
      -- trigram score (down-weighted for short queries)
      (
        least(
          greatest(similarity(j.title, q), similarity(j.company_name, q)),
          0.60
        )
        * case when p.qlen >= 5 then 0.6 else 0.2 end
      )
    )::real as score
  from public.jobs j
  cross join params p
  where
    -- must match either full-text or be "close enough"
    (j.search_tsv @@ p.tsq)
    or (similarity(j.title, q) > 0.25)
    or (similarity(j.company_name, q) > 0.25)
  order by score desc, j.posted_at desc
  limit limit_count
  offset offset_count;
$$;

Yes, those numbers are arbitrary.
I spent 4 hours tuning them.
Most of it was wrong.

What finally worked was testing with real searches:

“pmhnp remote”
“psych np telehealth”
“kaiser pmhnp”
“new yrok” (typo)

If you don’t test typos, you’re lying to yourself.
Users type like raccoons.

3) I call it via Supabase RPC. Clean boundary.

I don’t want raw SQL in my Next.js server code.
Not because it’s “bad”.
Because I’ll copy/paste it into 3 routes.
Then I’ll forget one.

RPC keeps it centralized.
So my app just does:

take query
call function
return JSON

This is the route handler.
App Router.
Server-only.

// app/api/search/route.ts
import { NextResponse } from "next/server";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // server-only
);

export async function GET(req: Request) {
  const { searchParams } = new URL(req.url);

  const q = (searchParams.get("q") ?? "").trim();
  const limit = Math.min(Number(searchParams.get("limit") ?? 25), 50);
  const offset = Math.max(Number(searchParams.get("offset") ?? 0), 0);

  if (q.length < 2) {
    return NextResponse.json({ items: [], count: 0 });
  }

  const { data, error } = await supabase.rpc("search_jobs", {
    q,
    limit_count: limit,
    offset_count: offset,
  });

  if (error) {
    // I’ve seen: "canceling statement due to statement timeout"
    return NextResponse.json({ error: error.message }, { status: 500 });
  }

  return NextResponse.json({ items: data ?? [], count: data?.length ?? 0 });
}

Service role key is touchy.
Don’t leak it.
I keep this route server-side only.
No client components calling Supabase directly for search.

Also.
I set a statement timeout on Supabase.
Because one runaway query can eat your day.

4) I debug search with `EXPLAIN ANALYZE`. Every time.

Search “feels” slow.
Until you measure it.

I run the exact query shape.
Then I read the plan.
Not the vibes.

Here’s the kind of thing I run in the SQL editor.
Same function logic, simplified.

explain (analyze, buffers)
select id, title
from public.jobs
where
  search_tsv @@ websearch_to_tsquery('english', 'pmhnp remote')
  or similarity(title, 'pmhnp remote') > 0.25
order by
  (ts_rank_cd(search_tsv, websearch_to_tsquery('english', 'pmhnp remote'))
   + least(similarity(title, 'pmhnp remote'), 0.60) * 0.6) desc
limit 25;

If you don’t see your GIN indexes used, stop.
Fix that first.

One dumb mistake I made.
I originally used to_tsquery().
It blew up on user input like c++ or remote (west).
Error was:

ERROR: syntax error in tsquery: "remote (west)"

websearch_to_tsquery() fixed it.
It handles normal human text.
That’s what I needed.

Results

Before: ILIKE search regularly spiked to 900–1400ms on my Vercel API route when the query was common (like “remote”). It also returned “meh” ordering. Typos like “psychiatrc” returned zero rows.

After: Postgres FTS + trigram search stays under ~120–220ms for my top queries, returning 25 rows with stable ranking. Typos now return usable results (usually 10–25 rows) instead of nothing. On the data side, this setup handles my current volume: 8,000+ active listings across 2,000+ companies, with 200+ new jobs scraped daily.

Key takeaways

Drop ILIKE '%term%' for user search. It doesn’t scale.
Store a weighted tsvector column and GIN-index it. Don’t compute it per query.
Use websearch_to_tsquery() for real user input. to_tsquery() will betray you.
Add trigram similarity for typos, but cap and down-weight it for short queries.
Keep scoring in SQL (RPC). Your Next.js code stays tiny.

Closing

I’m still not fully happy with ranking for super-short queries like “ny” and “la”. It matches too much, even with down-weighting.

How are you handling 2–3 character queries in Postgres search—hard minimum length, prefix-only, or a separate “location autocomplete” table?

Cursor Rules + Claude: stop breaking builds

Sathish — Thu, 19 Mar 2026 15:01:14 +0000

I use Cursor Rules to make Claude follow my stack.
I add a tiny “done = tests pass” contract.
I lint AI output hard. Automatically.
I keep prompts short. Diff-first.

Context

I build small SaaS projects. Usually solo. Usually fast.

Cursor + Claude makes me fast. It also makes me sloppy.

The failure mode is always the same. Claude writes code that looks right. It compiles. Then it breaks edge cases, ignores my existing patterns, or sneaks in a dependency I didn’t want.

I spent 4 hours on this once. Most of it was wrong. Not because Claude was “bad”. Because my workflow was vibes. No guardrails.

So I started treating AI like a junior dev with a very specific contract. Same stack. Same conventions. Same “definition of done”. And I automated the policing.

1) I write Cursor Rules first. Not prompts.

Prompts rot. Fast.

Rules don’t. They sit there. Every request gets them.

In Cursor, I keep a project rule file that forces Claude into my existing choices: Next.js App Router, TypeScript strict, no random state libs, prefer server actions, etc.

This is the exact kind of rules file I use (trimmed, but real). Drop it in .cursor/rules.md.

# .cursor/rules.md

You are coding in a Next.js 15 + TypeScript repo.

Hard rules:
- TypeScript only. No JavaScript files.
- No new dependencies unless I ask.
- Prefer built-in Web APIs over libraries.
- Keep functions small. 30 lines max.
- Every change must include: types, error handling, and tests if logic changed.

Next.js rules:
- App Router only.
- Prefer Server Components.
- Client Components only when needed (use 'use client').
- Prefer Server Actions for mutations.

Output rules:
- Show a diff-style plan first (bullets).
- Then edit minimal files.
- Don’t rewrite unrelated code.

One thing that bit me — if rules are too long, Claude starts “agreeing” and then doing whatever.

So I keep it short. Sharp edges only.

2) I force a “definition of done”: tests + typecheck

Claude will happily say “done” after writing code that doesn’t typecheck.

I stopped trusting completions. I only trust green commands.

In every repo I add a check script that matches what CI should do. No creativity.

{
  "scripts": {
    "lint": "next lint",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "check": "pnpm lint && pnpm typecheck && pnpm test"
  }
}

Then I bake this into my prompts.

Not a wall of text. Just a contract.

Make the minimal diff. pnpm check must pass.

If pnpm check fails, I paste the exact error back.

No paraphrasing. No “it’s failing somewhere”. I paste the stack trace like a robot.

That single habit cut my back-and-forth in half.

3) I run a “no new deps” tripwire

The sneakiest AI failure isn’t wrong code.

It’s new dependencies.

You ask for a tiny feature. You get zod, lodash, and some date library because Claude saw it in training data.

I added a tiny script that fails if package.json changed and I didn’t explicitly allow it.

This runs in pre-commit for me. You can also run it manually.

// scripts/no-new-deps.ts
import { readFileSync } from "node:fs";
import { createHash } from "node:crypto";

function sha256(s: string) {
  return createHash("sha256").update(s).digest("hex");
}

const pkg = readFileSync("package.json", "utf8");
const lock = readFileSync("pnpm-lock.yaml", "utf8");

// Commit the baseline hashes once. Update only when you *intend* to.
const BASE_PKG = process.env.BASE_PKG_HASH;
const BASE_LOCK = process.env.BASE_LOCK_HASH;

if (!BASE_PKG || !BASE_LOCK) {
  console.error("Missing BASE_PKG_HASH/BASE_LOCK_HASH env vars");
  process.exit(2);
}

const pkgHash = sha256(pkg);
const lockHash = sha256(lock);

if (pkgHash !== BASE_PKG || lockHash !== BASE_LOCK) {
  console.error("Dependency files changed. Did you mean to add/update deps?");
  console.error({ pkgHash, lockHash });
  process.exit(1);
}

console.log("OK: no dependency changes detected");

Yeah, it’s blunt.

But it matches how I work: I want dependencies to be a conscious decision.

To set the baseline once:

node -e 'const fs=require("fs"),c=require("crypto");
const h=s=>c.createHash("sha256").update(s).digest("hex");
console.log("BASE_PKG_HASH="+h(fs.readFileSync("package.json","utf8")));
console.log("BASE_LOCK_HASH="+h(fs.readFileSync("pnpm-lock.yaml","utf8")));'

Then store those in your shell env or .env.local for local use.

When I do want a dependency bump, I update the baseline and move on.

4) I make Claude work diff-first (and I reject big diffs)

My worst AI merges were big.

Not “big feature big diff”. More like: asked for a small refactor, got a rewrite.

Now I force a diff-first flow:

Claude lists the files it’ll touch.
Claude explains why each file changes.
I approve.
Only then it edits.

If it can’t describe the changes in 5 bullets, it’s about to go off-road.

Also: I cap file touches.

“Fix this bug. Touch max 2 files.”

It sounds restrictive. It’s not.

It keeps the model focused. And it keeps me reviewing.

Here’s a pattern I use a lot in Next.js when Claude wants to sprawl: isolate logic into a single module and test it.

Example: I’ll move tricky parsing/validation into lib/ and write a Vitest spec. Claude stays inside that box.

// lib/parsePagination.ts
export type Pagination = { page: number; pageSize: number };

export function parsePagination(input: Record): Pagination {
  const pageRaw = Array.isArray(input.page) ? input.page[0] : input.page;
  const sizeRaw = Array.isArray(input.pageSize) ? input.pageSize[0] : input.pageSize;

  const page = Math.max(1, Number(pageRaw ?? 1) || 1);
  const pageSize = Math.min(100, Math.max(1, Number(sizeRaw ?? 20) || 20));

  return { page, pageSize };
}

Test it. Lock behavior.

// lib/parsePagination.test.ts
import { describe, expect, it } from "vitest";
import { parsePagination } from "./parsePagination";

describe("parsePagination", () => {
  it("defaults safely", () => {
    expect(parsePagination({})).toEqual({ page: 1, pageSize: 20 });
  });

  it("coerces and clamps", () => {
    expect(parsePagination({ page: "0", pageSize: "1000" })).toEqual({ page: 1, pageSize: 100 });
    expect(parsePagination({ page: "-2", pageSize: "-5" })).toEqual({ page: 1, pageSize: 1 });
  });

  it("handles arrays from querystring", () => {
    expect(parsePagination({ page: ["2"], pageSize: ["10"] })).toEqual({ page: 2, pageSize: 10 });
  });
});

Now when Claude “improves” stuff, it has to respect the tests.

And I can review a 20-line diff instead of a 400-line rewrite.

5) I keep a failure log. One line per screw-up.

This is the unsexy part.

But it’s the part that compounds.

Whenever AI causes a bug or wastes time, I add one line to a local NOTES.md.

Stuff like:

“Claude used cookies() in a Client Component. Build failed with: Error: cookies was called outside a request scope.”
“It returned 200 with empty JSON on errors. Caused silent UI failures.”
“It changed a Prisma query shape and broke serialization.”

Then I convert the common ones into rules.

Rules are just my scars, written down.

Results

This workflow reduced my rework time a lot.

On my last build week, I tracked 23 AI-assisted coding sessions in a scratchpad. 17 ended with pnpm check passing on the first try. Before rules + contracts, that number was 6 out of 20 sessions on a similar codebase.

I also caught 4 unwanted dependency changes with the tripwire script. All four were unnecessary.

The biggest win wasn’t speed. It was fewer “what did it even change?” moments.

Key takeaways

Put your stack decisions in Cursor Rules. Keep it short.
Define “done” as lint + typecheck + tests. Nothing else counts.
Paste exact errors back to Claude. Don’t translate them.
Reject big diffs for small requests. Force diff-first planning.
When AI burns you, write it down. Turn it into a rule.

Closing

I’m still using Claude constantly. I just don’t let it drive unsupervised anymore.

If you already use Cursor Rules: what’s the one rule that saved you the most time (the exact line), and what bug did it prevent?