Forem: nareshipme

Adding YouTube thumbnails and real titles to existing projects — without a migration

nareshipme — Sun, 03 May 2026 11:54:08 +0000

Sometimes the best UX fix is the one that requires no new infrastructure. Here's how we added YouTube thumbnails and real video titles to ClipCrafter project cards — using only what was already in the database and what YouTube freely provides.

The problem

Project cards on the dashboard looked like this:

Title: YouTube video (8fcJ4Y-uxCw)
Thumbnail: none
Status badge, timestamp, action buttons

Not great. Users couldn't tell their projects apart at a glance. The fix seemed obvious — store the real title and a thumbnail URL. But that would mean:

A database migration to add a thumbnail_url column
A backfill for existing rows
Storing the title at upload time

We did none of those things.

Fix 1: Real titles via YouTube's oEmbed API

YouTube's oEmbed endpoint returns video metadata including the title — no API key required:

GET https://www.youtube.com/oembed?url=https://www.youtube.com/watch?v=VIDEO_ID&format=json

Response:

{
  "title": "The actual video title",
  "author_name": "Channel Name",
  "thumbnail_url": "https://i.ytimg.com/vi/.../hqdefault.jpg",
  ...
}

We call this during project creation, before inserting to the database:

async function fetchYoutubeTitle(url: string): Promise<string | null> {
  try {
    const res = await fetch(
      `https://www.youtube.com/oembed?url=${encodeURIComponent(url)}&format=json`
    );
    if (!res.ok) return null;
    const data = await res.json() as { title?: string };
    return data.title ?? null;
  } catch {
    return null;
  }
}

async function submitYoutubeUrl(url: string): Promise<void> {
  const ytMatch = url.match(/(?:v=|youtu\.be\/)([a-zA-Z0-9_-]{11})/);
  const fallback = ytMatch ? `YouTube video (${ytMatch[1]})` : url;
  const title = (await fetchYoutubeTitle(url)) ?? fallback;

  // title is now "How to Build a Rocket" instead of "YouTube video (dQw4w9WgXcQ)"
  await createProject({ title, type: "youtube", youtubeUrl: url });
}

A few things worth noting:

The fallback is always safe. If the oEmbed call fails (private video, network error, rate limit), we fall back to the ID-based title. The user flow never breaks.
The title is stored, not fetched on read. This means no repeated API calls and the title survives even if the video is later deleted or made private.
No API key. YouTube's oEmbed endpoint is publicly accessible. It works for any public video.

Fix 2: Thumbnails from a predictable URL pattern

YouTube serves thumbnails at deterministic URLs:

https://img.youtube.com/vi/{VIDEO_ID}/mqdefault.jpg  // 320×180
https://img.youtube.com/vi/{VIDEO_ID}/hqdefault.jpg  // 480×360
https://img.youtube.com/vi/{VIDEO_ID}/maxresdefault.jpg // max resolution

No API call needed — just the video ID. The question was: how do we get the video ID from our stored data?

For new projects, we store the normalized YouTube URL in r2_key (e.g. https://www.youtube.com/watch?v=8fcJ4Y-uxCw), so extracting the ID is straightforward.

For old projects, the stored r2_key is the R2 object path of the downloaded video file (videos/{uuid}/video.mp4) — no video ID there. But old projects have a predictable title format: YouTube video (8fcJ4Y-uxCw). The ID is right there in the title.

This gave us a two-path function with a graceful fallback:

function getYoutubeThumbnail(project: Project): string | null {
  if (project.type !== "youtube") return null;

  // New projects: r2_key is the YouTube URL
  const fromKey = project.r2_key?.match(/[?&]v=([a-zA-Z0-9_-]{11})/)?.[1];
  if (fromKey) return `https://img.youtube.com/vi/${fromKey}/mqdefault.jpg`;

  // Old projects: r2_key is a storage path, but title has the ID
  const fromTitle = project.title.match(/\(([a-zA-Z0-9_-]{11})\)$/)?.[1];
  return fromTitle ? `https://img.youtube.com/vi/${fromTitle}/mqdefault.jpg` : null;
}

No migration. No backfill script. Every existing project gets thumbnails automatically.

Wiring it into the card

The project card uses Next.js <Image> with the YouTube thumbnail domain added to next.config.ts:

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [{ protocol: "https", hostname: "img.youtube.com" }],
  },
};

The card component:

function YoutubeThumbnail({ project }: { project: Project }) {
  const src = getYoutubeThumbnail(project);
  if (!src) return null;
  return (
    <div className="relative w-full aspect-video">
      <Image
        src={src}
        alt=""
        fill
        className="object-cover"
        sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
        unoptimized
      />
    </div>
  );
}

export default function ProjectCard({ project }: ProjectCardProps) {
  return (
    <div className="bg-gray-900 border border-gray-800 rounded-xl overflow-hidden flex flex-col">
      <YoutubeThumbnail project={project} />
      <div className="p-4 flex flex-col gap-3">
        {/* title, status, timestamp, actions */}
      </div>
    </div>
  );
}

unoptimized is set because YouTube's CDN already serves optimized images — running them through Next.js image optimization would be redundant.

The broader pattern

Before reaching for a migration or a new API integration, ask:

Is the data already in the database? The video ID was in the title all along.
Does the platform expose it for free? YouTube's oEmbed gives us the real title with no authentication.
Can the URL be derived deterministically? Thumbnail URLs follow a predictable pattern once you have the ID.

Data you already have, combined with free platform APIs and predictable URL structures, can cover a lot of ground before you need to store anything new.

We're building ClipCrafter — AI-powered video clip extraction for creators. If you found this useful, follow along for more engineering notes.

Three CI failures we fixed this week (and what each one taught us)

nareshipme — Sun, 03 May 2026 11:53:20 +0000

A green CI pipeline is a contract. When it breaks in ways that differ from your local environment, something in the contract is wrong — not the code. Here are three failures we debugged this week on ClipCrafter and the underlying problems each exposed.

Failure 1: CI fails typecheck, local passes

What we saw

error TS2345: Argument of type '{ quality: number; }' is not assignable
to parameter of type 'ExportOptions'.
  Types of property 'quality' are incompatible.
    Type 'number' is not assignable to type 'QualityPreset | undefined'.

Passed locally. Failed in CI. Classic.

The investigation

First instinct: the code changed the type. But quality was already a string in our code — we were passing "medium" or "original". So why was CI complaining about number?

The error message says QualityPreset — a type that didn't exist in our local type definitions at all.

$ cat node_modules/framewebworker/package.json | grep version
  "version": "0.4.0"

$ cat package.json | grep framewebworker
  "framewebworker": "^0.5.5"

Local node_modules was 0.4.0. CI installs fresh from npm every run and got 0.5.5. The library changed quality between versions:

// 0.4.0 — quality is a number (0-1)
quality?: number;

// 0.5.5 — quality is a named preset
type QualityPreset = 'medium' | 'original';
quality?: QualityPreset;

We had already written quality: "medium" — which is correct for 0.5.5. But with 0.4.0 installed locally, the compiler accepted number too loosely.

The wrong fix we almost made

We initially mapped the string to a number:

// ❌ wrong — fighting the type instead of fixing the environment
const quality = quality === "original" ? 1 : 0.8;

This made local typecheck pass — but would have broken CI even harder.

The actual fix

npm install  # update node_modules to match package.json

With 0.5.5 installed locally, our original string values were already correct. No code change needed.

The lesson

When CI typecheck fails but local passes, suspect the environment before the code. Check node_modules version vs package.json declared version. A stale install is invisible until CI runs fresh.

Add this to your debugging checklist before changing code to satisfy a type error:

Is the installed version what package.json declares?
Is the CI environment installing the same lockfile?
Did a transitive dependency change?

Failure 2: Worker sync check fails after billing changes

What we saw

❌ Worker files are out of sync with src/.
   Run: bash scripts/sync-worker.sh
   Then commit the changes in worker/src/.

The context

The project runs a separate worker process alongside the Next.js app. Certain lib files are shared between them, but the worker uses relative imports instead of path aliases (@/lib/billing → ./billing). Rather than maintaining two copies by hand, a sync script rewrites imports and copies the files:

# scripts/sync-worker.sh (simplified)
for f in supabase r2 billing transcribe highlights; do
  sed 's|from "@/lib/\([^"]*\)"|from "./\1"|g' \
    src/lib/$f.ts > worker/src/lib/$f.ts
done

CI diffs the expected output against the committed worker/src/ files. Any divergence fails the build.

What happened

We'd updated src/lib/billing.ts as part of the billing hardening work and didn't run the sync script before pushing. The worker copy was one commit behind.

The fix

bash scripts/sync-worker.sh
git add worker/src/lib/billing.ts
git commit -m "chore: sync worker billing"

The lesson

Automated sync checks are worth the setup cost. Without the CI check, the worker would have silently run old billing code while the app used the new atomic RPC call — a subtle, hard-to-debug divergence. The check makes the implicit dependency explicit and enforced.

If you have files that need to stay in sync across boundaries (monorepo packages, generated types, worker copies), automate both the sync and the verification.

Failure 3: Linter flags complexity after a refactor

What we saw

error  Async function 'POST' has a complexity of 13. Maximum allowed is 10  complexity
error  Async function 'POST' has a complexity of 11. Maximum allowed is 10  complexity

The context

The project enforces complexity: ["error", 10] in ESLint — cyclomatic complexity measures the number of independent paths through a function. Each if, else if, ||, &&, try/catch, and ternary adds one.

A refactor had added idempotency checking (a try/catch + an if) and plan ID mapping (a three-way condition) directly into two POST route handlers. Both tipped over 10.

The fix: extract the decision logic

Webhook handler — moved idempotency check into its own function:

// Before: all inline in POST, complexity = 13
// After: extracted, POST complexity drops to 8

async function isDuplicate(payload: Record<string, unknown>): Promise<boolean> {
  const eventId = payload.id as string | undefined;
  if (!eventId) return false;
  const { error } = await supabaseAdmin
    .from("webhook_events")
    .insert({ id: eventId, event: (payload.event as string) ?? "unknown" });
  return error?.code === "23505";
}

Upgrade handler — extracted the plan validation guard:

// Before: three-way comparison inline, adds 2 complexity points
if (plan !== "starter" && plan !== "pro" && plan !== "unlimited") { ... }

// After: extracted to a type guard
function isValidPlan(plan: string): plan is ValidPlan {
  return plan === "starter" || plan === "pro" || plan === "unlimited";
}

The lesson

Complexity limits force good decomposition. The isDuplicate function is now:

Named (self-documenting)
Independently testable
Reusable if a second handler needs the same check

None of that would have happened without the linter pushing back. Cyclomatic complexity rules feel annoying until you're reading someone else's 200-line function with 15 nested conditions.

If your project doesn't have one, consider adding:

// .eslintrc or eslint.config.mjs
"complexity": ["error", 10]

Start with 15 if 10 feels too aggressive — the discipline it enforces is worth it.

The common thread

All three failures had the same shape: a local environment that hid a real problem. Stale node_modules hid a version mismatch. No sync check would have hidden a worker divergence. No complexity rule would have hidden spaghetti accumulating in route handlers.

CI's job is to be stricter than your local setup. When it catches something your machine didn't, that's it working correctly.

We build ClipCrafter — AI-powered video clip extraction. If CI war stories resonate, follow along.

Two billing bugs that looked fine until production proved otherwise

nareshipme — Sun, 03 May 2026 11:43:02 +0000

Billing code is the most dangerous place to have subtle bugs. It rarely crashes — it just silently does the wrong thing. Here are two we found and fixed in ClipCrafter, an AI video clip extraction tool.

Bug 1: The usage counter that lost data under load

We track how many seconds of video each user processes per day to enforce plan limits. The original increment looked like this:

const { data } = await db
  .from("users")
  .select("daily_usage_seconds")
  .eq("clerk_id", clerkUserId)
  .single();

const next = (data.daily_usage_seconds ?? 0) + seconds;

await db
  .from("users")
  .update({ daily_usage_seconds: next })
  .eq("clerk_id", clerkUserId);

This is a textbook read-modify-write race. Here's the scenario that breaks it:

Request A reads daily_usage_seconds = 120
Request B reads daily_usage_seconds = 120 (before A has written)
Request A writes 120 + 300 = 420
Request B writes 120 + 180 = 300 — overwriting A's write

The user processed 480 seconds of video but the counter shows 300. They get more usage than they're supposed to. At scale — multiple clips rendering simultaneously — this happens constantly.

The code looks correct. It reads, adds, writes. The problem is invisible in single-user testing.

The fix: push the increment into Postgres

CREATE OR REPLACE FUNCTION increment_daily_usage(
  p_clerk_id TEXT,
  p_seconds  INTEGER
)
RETURNS void LANGUAGE plpgsql SECURITY DEFINER AS $$
BEGIN
  UPDATE users
  SET daily_usage_seconds = COALESCE(daily_usage_seconds, 0) + p_seconds
  WHERE clerk_id = p_clerk_id;
END;
$$;

A single UPDATE ... SET col = col + n is atomic. Postgres takes a row-level lock for the duration of the update — no two concurrent updates can interleave. The application becomes:

await supabaseAdmin.rpc("increment_daily_usage", {
  p_clerk_id: clerkUserId,
  p_seconds: seconds,
});

One network round-trip instead of two, and no race condition.

Why SECURITY DEFINER? It lets the function run with the privileges of its creator (the DB owner), bypassing row-level security for this specific operation. Since the app calls it via a service-role client that already bypasses RLS, this is consistent — but it's worth knowing the tradeoff.

Bug 2: The webhook handler that processed events twice

Payment providers retry webhook deliveries when they don't receive a 200 response quickly enough — network blip, slow cold start, anything. Our handler wasn't idempotent:

export async function POST(request: Request) {
  // ... verify signature ...
  const { event, clerkUserId, subscriptionId } = parseEvent(body);

  if (event === "subscription.activated") {
    // This runs twice if the webhook is retried
    await activateSubscription(clerkUserId, subscriptionId);
  }
}

If the provider retried after a slow response, the user's subscription could be activated twice — not catastrophic here, but the pattern generalises to things like crediting accounts or sending emails.

The fix: a deduplication table

CREATE TABLE IF NOT EXISTS webhook_events (
  id           TEXT        PRIMARY KEY,
  event        TEXT        NOT NULL,
  processed_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Every webhook payload has a unique event ID. We try to insert it; a primary key conflict means we've already processed it:

async function isDuplicate(payload: Record<string, unknown>): Promise<boolean> {
  const eventId = payload.id as string | undefined;
  if (!eventId) return false;

  const { error } = await supabaseAdmin
    .from("webhook_events")
    .insert({ id: eventId, event: (payload.event as string) ?? "unknown" });

  // 23505 = unique_violation in Postgres
  return error?.code === "23505";
}

export async function POST(request: Request) {
  // ...
  if (await isDuplicate(rawPayload)) {
    return Response.json({ received: true }); // 200 so provider stops retrying
  }
  // ... process event ...
}

Key details:

Return 200 on duplicate — returning an error would cause the provider to retry again
The insert-and-check-conflict is itself atomic — no TOCTOU gap
The table doubles as an audit log of every event ever received

Shipping both as one migration

Both fixes are database objects, so they went into a single migration file:

-- 016_billing_fixes.sql

CREATE OR REPLACE FUNCTION increment_daily_usage(p_clerk_id TEXT, p_seconds INTEGER)
RETURNS void LANGUAGE plpgsql SECURITY DEFINER AS $$
BEGIN
  UPDATE users
  SET daily_usage_seconds = COALESCE(daily_usage_seconds, 0) + p_seconds
  WHERE clerk_id = p_clerk_id;
END;
$$;

CREATE TABLE IF NOT EXISTS webhook_events (
  id           TEXT        PRIMARY KEY,
  event        TEXT        NOT NULL,
  processed_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

They land together or not at all. Code that depends on both objects was deployed in the same release.

The pattern to remember

Both bugs share the same root cause: state mutation across multiple round-trips is never safe under concurrency. The fix in both cases was the same: push the mutation into the database where it can be made atomic.

Use UPDATE ... SET col = col + n instead of read-then-write
Use an insert-with-conflict as an atomic check-and-record for idempotency

Postgres is very good at this. Let it do the work.

We're building ClipCrafter — AI-powered short clip extraction from long videos. If you're working on similar problems, I'd love to hear how you handle billing correctness at scale.

Fixing "No Credentials Found" when using AWS SSO Profiles in Zsh

nareshipme — Mon, 27 Apr 2026 05:50:42 +0000

TL;DR: An AWS SSO login was successful, but subsequent AWS commands failed with "No credentials found" because the shell alias was pointing to a profile name that didn't match the configured credential block in ~/.aws/config.

I wanted to automate my AWS authentication by creating an alias in my .zshrc to trigger the SSO login process. After running the command, the terminal reported Login successful, but any subsequent attempt to list S3 buckets or use the AWS CLI resulted in a credential error.

The issue stemmed from a mismatch between how the profile was defined in ~/.aws/config and how I was calling it via the CLI.

Here is the configuration block I had in my ~/.aws/config:

[profile 123456789012_AWSEngineerAccessRole]
sso_start_url = https://your-org.awsapps.com/start
sso_region = eu-west-2
sso_account_id = 123456789012
sso_role_name = AWSEngineerAccessRole
region = eu-west-2

When I ran my login command, the output was:

Login successful

However, running a basic AWS command immediately after produced this error:

Unable to locate credentials. You can configure credentials manually via the 'aws configure' command.

The failure happened because even though the SSO session was active in the background, the AWS CLI does not automatically know which profile to use for subsequent commands unless explicitly instructed. If my alias or environment variable was pointing to a generic default profile, the CLI looked for credentials under [default], found nothing, and failed—ignoring the fact that a valid SSO session existed for the specific 123456789012_AWSEngineerAccessRole profile.

To fix this, I updated my .zshrc alias to ensure every command explicitly references the correct profile name defined in the config file:

# Before (failed because it defaulted to 'default' profile)
alias awslogin="aws sso login"

# After (explicitly targets the SSO profile)
alias awslogin="aws sso login --profile 123456789012_AWSEngineerAccessRole"
alias aws='aws --profile 123456789012_AWSEngineerAccessRole'

By appending --profile 123456789012_AWSEngineerAccessRole to the login command, the CLI maps the successful authentication token specifically to that profile block. By aliasing aws itself, I ensure all subsequent commands bypass the empty [default] profile and use the authenticated SSO session.

Why We Switched to Streaming Frame Extraction for Mobile Video Editing

nareshipme — Fri, 24 Apr 2026 15:32:19 +0000

When we first started building ClipCrafter's browser-based video engine, our biggest enemy wasn’t the complexity of FFmpeg—it was something much more silent and deadly: Memory Exhaustion.

If you are working with high-resolution clips or long durations in a Web Worker, there is an invisible wall you will eventually hit. We call it "The OOM (Out Of Render) Wall."

Recently, we noticed that while our desktop users were enjoying smooth multi-clip stitching, mobile Chrome and Safari users on mid-range Androids/iPhones were experiencing frequent tab crashes during the rendering process. The culprit? Our frame extraction logic was attempting to hold too much in memory at once.

The Problem: $O(n)$ Memory Complexity

In our early architecture of framewebworker, we used a pattern that looked like this conceptually (simplified for clarity):

// ❌ THE OLD WAY: High risk of OOM crashes on mobile
async function extractFramesAllAtOnce(videoSource: Blob) {
  const frames = []; // This array grows linearly with video length!
  let currentTime = 0;

  while (currentTime < duration) {
    // We were grabbing a frame, converting it to an ImageBitmap/Blob...
    const frame = await captureFrameAt(videoSource, currentTime);
    frames.push(frame); // Every single frame stays in RAM until the end
    currentTime += interval; 
  }

  return frames; // If you have 500 frames of a long clip? Goodbye memory!
}

In this "Load-All" approach, our memory complexity was $O(n)$, where $n$ is total number of extracted frames. For an 8MB video file might be fine—but for high-bitrate clips or longer sequences involving multiple stitches, the browser's heap would balloon until it hit its limit and killed the worker thread (and usually our entire app tab).

The Solution: Streaming Extraction

To fix this, we upgraded framewebworker to version 0.4.0 with a focus on Streaming Frame Extraction. Instead of accumulating an array of frames in memory before starting the stitch process, we moved toward $O(1)$ spatial complexity relative to total frame count (per step).

We refactored our pipeline so that each extracted frame is processed through its next stage immediately—whether it's being passed into a WebCodecs encoder or written as part of an intermediate stream.

Here’s how we restructured the logic:

// ✅ THE NEW WAY: Streaming approach (O(1) memory footprint per step)
async function processFramesStreaming(videoSource: Blob, onFrameReady: Callback<Blob>) {
  let currentTime = 0;
  const interval = 1 / 30; // target fps

  while (currentTime < duration) {
    // Extract ONLY the current frame needed for this specific timestamp
    const singleFrameBuffer = await captureSingleFrame(videoSource, currentTime);

    /**
     * Instead of pushing to a massive global array 'frames', 
     * we emit it immediately. The downstream consumer (WebCodecs) 
     * processes the frame and then allows this buffer to be garbage collected.
     */
    await onFrameReady(singleFrameBuffer);

    currentTime += interval;
  }
}

Why This Matters for Developers Building Heavy Web Apps

By moving from an "Accumulate-then-Process" model to a Streaming model, we achieved two critical wins:

Memory Stability: The memory footprint of our worker is now tied more closely to the size of one single frame rather than total video duration/frame count. This makes mobile rendering significantly more reliable even on low-end devices with restricted heap sizes.
Time To First Byte (TTFB) for Rendering: Because we start processing frames as soon as they are extracted, our downstream encoders can begin working immediately without waiting for the "extraction phase" to finish entirely.

The Takeaway

When building resource-intensive features in JavaScript—whether it’s video editing with FFmpeg/WebCodecs or heavy data visualization—always ask yourself: Is my memory usage $O(n)$?

If your app's stability degrades as the input size increases, you don't have a logic bug; you have an architectural bottleneck. Switching to streaming-based processing is often more difficult than simple array manipulation (due to managing backpressure and state), but it’s what makes "pro" web tools possible on mobile browsers.

ClipCrafter continues to evolve! Check out our latest updates for even faster WebCodecs hardware acceleration.

Fixing "No Credentials Found" when using AWS SSO Profiles in Zsh

nareshipme — Fri, 24 Apr 2026 06:31:24 +0000

TL;DR: An AWS CLI alias was failing with "No credentials found" because the shell command was not explicitly pointing to the specific named profile configured for SSO. I fixed this by appending --profile to the command execution within the Zsh alias.

I set up a new Zsh alias to automate my AWS SSO login process and update my local ~/.aws/credentials file. The configuration in my ~/ .aws/config looked correct:

[profile 123456789012_AWSEngineerAccessRole]
sso_start_url = https://your-org.awsapps.com/start
sso_region = eu-west-2
sso_account_id = 123456789012
sso_role_name = AWSEngineerAccessRole
region = eu-west-2

However, when running my custom login alias, the CLI returned this error:

error: No credentials found in the configured profile.

The issue was that aws sso login does not automatically assume you want to use a specific named profile if it isn't the [default] profile. If your configuration uses a custom profile name like 123456789012_AWSEngineerAccessRole, running a bare aws sso login command causes the CLI to look for credentials under the [default] block. Since that block was empty or missing the SSO metadata, it failed immediately.

To fix this, I updated my .zshrc alias to explicitly reference the profile name using the --profile flag:

# Before (Failing)
alias awslogin="aws sso login"

# After (Working)
alias awslogin="aws sso login --profile 123456789012_AWSEngineerAccessRole"

By adding --profile, the AWS CLI knows exactly which block in ~/.aws/config to parse for the sso_start_url and sso_account_id. Now, running awslogin triggers the browser authentication flow and correctly maps the session tokens to that specific profile.

The domain name was just productive procrastination

nareshipme — Thu, 23 Apr 2026 15:54:37 +0000

I finally reached a point with ClipCrafter where I had nothing left to hide behind in the code.

The features were all there—authentication flows working perfectly, transcription logic solid, clip generation functional, and even an export system that didn't crash every five minutes. After about 238 pull requests, it wasn’t just a "cool experiment" anymore; it was actually running like a real product. But despite having the tech ready to go, I kept delaying one specific thing: getting a domain name.

There is something deeply uncomfortable about attaching your own URL to an unfinished idea. As long as everything lived on some random deployment sub-domain or localhost, any bugs were just "developer quirks." Once you buy something.com, the project becomes real. It’s no longer yours alone; it belongs to whoever finds that link in a Google search and decides whether they like what they see.

When I finally forced myself to face this hurdle last week, I hit an immediate wall of frustration.

clipcrafter.com? Taken.
clipcrafter.app? Taken.
clipcrafter.io? Taken.
clipcrafter.video? Also taken.

I even had a brief moment where I considered just using my personal brand domain, kshan.ai. It felt safe because it was already mine and nothing could change with me personally failing at this project—but that would have been dishonest to the product itself. ClipCrafter needed its own identity.

Instead of spiraling into a naming crisis, I decided to stop manual searching and wrote a quick script to check availability for different prefixes across various TLDs programmatically. It was much less emotional than clicking through domain registrars one by one. That’s when I found getclipcrafter.com.

It wasn't "perfect," but it followed the classic indie hacker playbook—the same pattern used by giants like Postman (getpostman.com) or Figma (before they moved to their primary). It was cheap, available, and descriptive enough that people would know exactly what I do. Within minutes of buying it, my DNS records were updated and pointed at a live production deployment.

Looking back on the last few days spent obsessing over TLDs ($com vs $io) or prefix choices (get- vs try-) was actually quite revealing to me. The domain research wasn't about branding; it was productive procrastination. I used "finding the perfect name" as a shield against launching because once that URL is live, you can no longer hide from feedback.

The fear of someone using the tool and finding it broken or useless became much more concrete the moment getclipcrafter.com appeared in my browser bar. But strangely enough, making that fear real made it easier to face. You can't fix a product if nobody is looking at you actually ship it.

The app is officially live now. No more excuses—time to find those first users and see what they think of the mess I’ve built.

When Turbopack Breaks Your Web Worker Builds

nareshipme — Thu, 23 Apr 2026 15:32:10 +0000

In the world of modern frontend development, "speed" is usually a good thing. We want faster hot reloads during development and lightning-fast build times for production.

Recently at ClipCrafter, we hit this wall head-on when upgrading to Next.js 16. While moving towards Turbopack promised us incredible developer experience improvements, it introduced a silent killer: our video processing engine stopped working in production builds because of how Webpack handles worker files differently than Turbo/Turbopack does during the build pipeline.

The Problem: A Broken Worker Pipeline

ClipCrafter relies heavily on @ffmpeg/ffmpeg to handle heavy-duty video manipulation directly in the browser. This requires loading a specific .wasm file and an ESM worker via a Blob URL at runtime.

To make this work, we had configured a custom Webpack loader in next.config.ts. We needed specifically told webpack how to treat these files so they wouldn't be mangled during the bundling process:

// next.config.ts (The "Old" Way that worked)
const nextConfig = {
  webpack: (config, { isServer }) => {
    if (!isServer) {
      // We needed this custom loader to ensure ffmpeg-core 
      // could be resolved correctly via Blob URLs at runtime.
      config.module.rules.push({
        test: /ffmpeg\/dist\/esm\/worker\.js$/,
        loader: 'url-loader', // Or specialized worker loaders
      });
    }
    return config;
  },
};

When we upgraded, Next.js started defaulting to Turbopack for builds in certain environments. Since our configuration was strictly targeting the webpack object and didn't provide a corresponding Turbo-compatible instruction set via turbo: { rules: ... }, those critical worker files were being bundled incorrectly. The result? A production build that looked perfect but crashed with an "Uncaught TypeError" as soon as you tried to initialize any video clip processing.

Moving Toward Hardware Acceleration

While fixing the bundler, we also had a chance to look at our performance bottleneck. We realized ffmpeg.wasm was great for compatibility, but it's essentially running software-based encoding in JavaScript—which is slow and heavy on CPU usage.

We decided to upgrade/integrate with @framewebworker@0.3.0. This library uses WebCodecs, a modern browser API that allows us to tap into the device’s hardware acceleration (H.264). The difference was night and day: we saw encoding speeds jump from "painfully slow" up to 10–50× faster on supported browsers, with an automatic fallback to our existing FFmpeg setup for older devices.

How We Fixed It

To get the build pipeline stable again while embracing these upgrades, we had two main tasks in a single PR:

Force Webpack for Production: Until Next.js provides more robust Turbopack configuration hooks specifically for complex WASM/Worker loaders like ours, we explicitly forced webpack during our production builds to ensure the @ffmpeg/ffmpeg worker remains intact and resolvable at runtime.
Clean up Route Exports: We also had a minor type-safety issue where arbitrary constants (like language lists) were being exported from Next.js App Router files, causing TypeScript violations in generated types during build time. In route.ts, you should only export HTTP handlers (GET, POST) and config objects.

The Lesson Learned

If your application relies on "heavy" browser APIs like WebAssembly (WASM), SharedArrayBuffer, or complex Worker threads: Don't assume the new default bundler just works.

The transition from Webpack to Turbopack is a massive leap forward for dev speed, but it requires you to audit how your most critical pieces of infrastructure—the ones that don't follow standard "UI component" rules—are being bundled. We fixed our build by reverting the production engine back to its proven Webpack configuration while keeping all other Next.js 16 benefits intact.

Have you run into bundling issues with newer versions of Next.js? Let us know in the comments!

Debugging "No Credentials Found" when Aliasing AWS SSO Login in ZSH

nareshipme — Thu, 23 Apr 2026 12:13:53 +0000

TL;DR: Creating a ZSH alias that runs aws sso login appeared to succeed, but subsequent commands failed with "no credentials found" because the alias was not correctly setting the profile for downstream tools.

I was trying to streamline my workflow by adding an alias to my .zshrc to automate logging into a specific AWS SSO profile. The goal was simple: run one command, and have all subsequent AWS CLI commands work immediately using that authenticated session.

The alias looked like this in my .zshrc:

alias awslogin="aws sso login --profile 123456789012_AWSEngineerAccessRole"

When I ran awslogin, the terminal returned:

Login successful

However, as soon as I tried to list my S3 buckets using that same profile, the CLI threw a credential error:

fatal error: An error occurred (NoCredentialsError) when calling the ListBuckets operation: unable to locate credentials.

The Root Cause

The issue was not with the SSO login itself — the browser-based authentication was completing successfully and updating the token cache in ~/.aws/sso/cache. The problem was a mismatch between how I was initiating the session and how my AWS configuration was structured.

In my ~/.aws/config, I had defined the profile like this:

[profile 123456789012_AWSEngineerAccessRole]
sso_start_url = https://your-org.awsapps.com/start
sso_region = eu-west-2
sso_account_id = 123456789012
sso_role_name = AWSEngineerAccessRole
region = eu-west-2

While aws sso login --profile <name> successfully refreshed the SSO token, subsequent commands were failing because they were not explicitly told to use that specific profile. The AWS CLI defaults to looking for a [default] profile or AWS_ACCESS_KEY_ID environment variables. Since neither was set, it found nothing — even though the SSO token was valid.

The Fix

Update the alias to also export AWS_PROFILE after a successful login:

alias awslogin='aws sso login --profile 123456789012_AWSEngineerAccessRole && export AWS_PROFILE=123456789012_AWSEngineerAccessRole'

The && means the export only runs if the login succeeded. From that point, every subsequent command in the shell session picks up the correct profile automatically — no --profile flag needed.

Verification:

$ awslogin
Login successful
$ aws s3 ls
[your buckets appear]
$ aws sts get-caller-identity
{
    "UserId": "...",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/AWSEngineerAccessRole/..."
}

The sts get-caller-identity check is worth adding to your alias or running manually after login — it confirms the session is actually active, not just that the token handshake completed.

Why We Switched from Stripe to Razorpay for ClipCrafter’s Billing Engine

nareshipme — Wed, 22 Apr 2026 14:01:20 +0000

Building a SaaS is rarely just about the core feature. For us at ClipCrafter—an AI-powered video editor—the "video" part was actually one of our easier challenges. The real complexity crept in when we had to figure out how to charge people for it.

Recently, we hit a major milestone: moving from an experimental Stripe setup into a production-ready billing system powered by Razorpay. While many developers default to Stripe because of its incredible documentation and global footprint, scaling ClipCrafter required us to rethink our payment architecture based on specific regional needs and usage enforcement.

The "Why" Behind the Pivot

When we first started prototyping Phase 10 (our Billing & Payments phase), a dual-provider approach seemed attractive for international coverage via Stripe + Razorpay. However, as development progressed, it became clear that maintaining two separate webhooks, two different subscription lifec/ycles, and twofold error handling was creating massive technical debt in our Inngest workflows.

We decided to simplify: Razorpay only.

By focusing on a single provider for the initial launch phase (specifically targeting India-based payments), we were able to prune significant amounts of boilerplate code from both our Next.js API routes and our background workers. We removed stripe_subscription_id entirely, cleaned up our database migrations in Supabase, and focused strictly on usage enforcement via a unified schema.

Implementing Usage Enforcement

The real challenge wasn't just "taking money"—it was ensuring that if someone is on the 'Starter' plan, they don’t accidentally trigger an unlimited number of high-compute video renders using our WebWorker architecture.

We needed a way to check usage limits before every single rendering job hit our worker queue via Inngest. Here is how we structured that logic in TypeScript:

// src/lib/billing.ts - Simplified Usage Check Logic

import { createClient } from '@supabase/supabase-js';

interface UserBillingRow {
  planKey: 'starter' | 'pro';
  videoCreditsRemaining: number;
}

export async function validateRenderPermissions(userId: string, supabaseClient: any) {
  // 1. Fetch the current user billing status from Supabase
  const { data: billingData, error } = await supabaseClient
    .from('user_billing')
    .select('planKey, videoCreditsRemaining')
    .eq('id', userId)
    .single();

  if (error || !billingData) {
    throw new Error("Could not retrieve billing information.");
  }

  const { planKey, videoCreditsRemaining } = billingData as UserBillingRow;

  // 2. Enforce hard limits based on the Plan Key
  console.log(`Checking permissions for ${planKey} user...`);

  if (videoCreditsRemaining <= 0) {
    throw new Error("No credits remaining! Please upgrade your plan.");
  }

  return true; // Permission granted to proceed with rendering task
}

The Lesson: Pruning is as important as Adding

The most satisfying part of this refactor wasn't adding the Razorpay integration—it was deleting everything related to Stripe. We removed entire client libraries, deleted webhook listeners that were no longer being triggered, and cleaned up our PlanBadge components which previously had "zombie" styles for plans we weren't even supporting anymore via a specific provider.

In software engineering (and especially in early-stage startups), there is an immense temptation to build every possible integration from Day 1 just because you might need it later. We learned that the complexity of managing two payment gateways far outweighed any potential benefit for our current user base.

Takeaway

If you're building a global SaaS, don't let "feature creep" infect your core infrastructure before they even pay their first invoice. Pick one provider, master its webhook lifecycle and usage enforcement patterns (like we did with Inngest + Supabase), and only expand when the market—not your imagination—demands it.

What’s your experience with payment gateways? Did you stick to Stripe or find a more localized solution for much of less friction? Let us know in the comments!

Dev Journal: 2026-04-21

nareshipme — Tue, 21 Apr 2026 06:42:21 +0000

/Users/ONBAdmin/Development/term-sheet/scripts/daily-blog.sh: line 132: /users/ONBAdmin/.nvm/versions/node/v20.19.0/bin/claude: No such file or directory

Dev Journal: 2026-04-21

nareshipme — Tue, 21 Apr 2026 06:30:08 +0000

Not logged in · Please run /login