DEV Community: Gloria

I Stopped Managing 4 AI SDKs and Routed Everything Through Crun.ai API — Here's the Code

Gloria — Mon, 08 Jun 2026 01:57:05 +0000

Let me paint a picture.

You're three months into your AI-powered SaaS. You've integrated Flux for image generation, Kling for video, a second image model for higher-resolution output, and an LLM for copy assistance. Four providers. Four API keys. Four completely different authentication patterns. Four sets of response formats. And four independent async handling strategies — because one provider is synchronous, two are async-poll, and one prefers webhooks.

You ship it. It works. You move on.

Then Kling updates their callback field names. Then your Flux adapter breaks because you forgot the temporary URL has a 12-hour TTL and your queue runs slow on weekends. Then you hire a new engineer, they touch the LLM integration, and somehow the image generation pipeline starts throwing 401s.

Sound familiar?

This is "SDK sprawl" — and it quietly ate about 40% of my team's engineering time before we did something about it. This post shows exactly what we did, with real working code.

The Before Picture: What SDK Sprawl Actually Looks Like

Here's what our codebase looked like before the refactor. Four different functions, four different patterns, zero shared logic:

// ❌ BEFORE: Flux image generation
async function generateFluxImage(prompt: string) {
  const response = await fetch('https://api.flux.ai/v1/generate', {
    method: 'POST',
    headers: {
      'X-Flux-Key': process.env.FLUX_API_KEY!,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ prompt, width: 1024, height: 1024 }),
  })
  const data = await response.json()
  // Returns a temp URL that expires in 12 hours — must download immediately
  return data.image_url
}

// ❌ BEFORE: Kling video generation (completely different pattern)
async function generateKlingVideo(prompt: string) {
  const submit = await fetch('https://api.kling.ai/v1/video/create', {
    method: 'POST',
    headers: { Authorization: `Bearer ${process.env.KLING_KEY}` },
    body: JSON.stringify({ prompt, duration: 5 }),
  })
  const { task_id } = await submit.json()

  // Different polling logic from every other provider
  while (true) {
    await sleep(5000)
    const status = await fetch(`https://api.kling.ai/v1/video/${task_id}`, {
      headers: { Authorization: `Bearer ${process.env.KLING_KEY}` },
    })
    const data = await status.json()
    if (data.status === 'completed') return data.output_video  // different field name
    if (data.status === 'error') throw new Error(data.error_message)
  }
}

// ❌ BEFORE: Third provider — yet another pattern, yet another auth style
async function generateHDImage(prompt: string) {
  // ... completely different auth, different field names, different error codes
}

Three providers, three completely different implementations. No shared retry logic. No unified error handling. No consistent file storage strategy. And when any one of these providers changed something — which they all did, regularly — the fix lived in exactly one place and nowhere else could benefit from it.

The After: One Client, One Pattern, Every Model

After migrating to Crun.ai API, the same functionality looks like this:

// ✅ AFTER: One client setup covers everything
import axios from 'axios'

const crun = axios.create({
  baseURL: 'https://api.crun.ai/v1',
  headers: {
    Authorization: `Bearer ${process.env.CRUN_API_KEY}`,
    'Content-Type': 'application/json',
  },
  timeout: 30_000,
})

// One image generation function — model is just a config param
async function generateImage(prompt: string, model = 'flux') {
  const { data } = await crun.post('/tasks/image', {
    model,   // swap to 'dall-e-3' by changing this string. Zero other changes.
    prompt,
    size: '1024x1024',
  })
  return data.output.url  // Persistent URL — no expiry, no manual download needed
}

// One video generation function — same shape as image
async function generateVideo(prompt: string, model = 'kling') {
  const { data } = await crun.post('/tasks/video', {
    model,
    prompt,
    duration: 5,
    aspect_ratio: '16:9',
  })
  return data.task_id  // Async — we'll poll or webhook from here
}

Same shape. Same field names. Same auth. The model name is the only thing that changes between providers.

Let me walk through the full implementation now.

Step 1: Base Client + Environment Setup

npm install axios dotenv

# .env
CRUN_API_KEY=your_key_here
CRUN_BASE_URL=https://api.crun.ai/v1

// lib/crun-client.ts
import axios, { AxiosInstance } from 'axios'
import 'dotenv/config'

const createCrunClient = (): AxiosInstance => {
  const client = axios.create({
    baseURL: process.env.CRUN_BASE_URL,
    headers: {
      Authorization: `Bearer ${process.env.CRUN_API_KEY}`,
      'Content-Type': 'application/json',
    },
    timeout: 30_000,
  })

  // Unified error interceptor — one place, all providers
  client.interceptors.response.use(
    (res) => res,
    (err) => {
      const status = err.response?.status
      const message = err.response?.data?.error || err.message
      throw new Error(`[Crun API] ${status ?? 'Network Error'}: ${message}`)
    }
  )

  return client
}

export const crun = createCrunClient()

One client. One error interceptor that covers every model call in your entire codebase.

Step 2: Image Generation — Sync, with Model Switching

Image tasks complete in seconds and return synchronously.

// lib/image.ts
import { crun } from './crun-client'

type ImageModel = 'flux' | 'dall-e-3'
type ImageSize = '512x512' | '1024x1024' | '1792x1024'

interface ImageResult {
  taskId: string
  url: string        // Persistent — no TTL, no manual download
  width: number
  height: number
  costUsd: number
}

export async function generateImage(
  prompt: string,
  model: ImageModel = 'flux',
  size: ImageSize = '1024x1024'
): Promise<ImageResult> {
  const { data } = await crun.post('/tasks/image', { model, prompt, size })

  return {
    taskId: data.task_id,
    url: data.output.url,
    width: data.output.width,
    height: data.output.height,
    costUsd: data.usage.cost,
  }
}

Want to A/B test Flux vs. DALL·E? It's literally one argument:

// A/B test: route 50% of requests to each model
const model = Math.random() > 0.5 ? 'flux' : 'dall-e-3'
const result = await generateImage(prompt, model)

No adapter rewrite. No separate code path. One line.

Step 3: Async Video Generation — Polling Mode

Video generation takes 30 seconds to 3 minutes. You have two solid options for handling the async lifecycle: polling and webhooks. Here's polling first — good for scripts and low-volume use cases.

// lib/video-polling.ts
import { crun } from './crun-client'

type VideoModel = 'kling' | 'luma'

interface VideoResult {
  taskId: string
  url: string
  durationSeconds: number
}

const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms))

export async function generateVideoWithPolling(
  prompt: string,
  model: VideoModel = 'kling',
  options: { duration?: 5 | 10; pollIntervalMs?: number; timeoutMs?: number } = {}
): Promise<VideoResult> {
  const { duration = 5, pollIntervalMs = 5_000, timeoutMs = 300_000 } = options

  // 1. Submit the task
  const { data: submitData } = await crun.post('/tasks/video', {
    model,
    prompt,
    duration,
    aspect_ratio: '16:9',
  })
  const taskId: string = submitData.task_id
  console.log(`[video] Task submitted: ${taskId}`)

  // 2. Poll until done
  const deadline = Date.now() + timeoutMs

  while (Date.now() < deadline) {
    await sleep(pollIntervalMs)

    const { data: statusData } = await crun.get(`/tasks/${taskId}`)
    const { status } = statusData
    console.log(`[video] ${taskId} → ${status} (${Math.round((Date.now() - (deadline - timeoutMs)) / 1000)}s)`)

    if (status === 'succeeded') {
      return {
        taskId,
        url: statusData.output.url,
        durationSeconds: statusData.output.duration,
      }
    }

    if (status === 'failed') {
      throw new Error(`Task ${taskId} failed: ${statusData.error}`)
    }
    // 'pending' | 'processing' → keep waiting
  }

  throw new Error(`Task ${taskId} timed out after ${timeoutMs / 1000}s`)
}

⚠️ Don't set pollIntervalMs below 3000ms. You'll burn rate limit quota and you won't get results any faster — model inference doesn't speed up because you're polling more often.

Step 4: Async Video Generation — Webhook Mode (Production-Recommended)

Polling holds a thread open for the duration of the task. In production, with many concurrent video jobs, that gets expensive fast. Use webhooks instead.

// lib/video-webhook.ts
import { crun } from './crun-client'

export async function submitVideoTask(
  prompt: string,
  model: 'kling' | 'luma' = 'kling',
  webhookUrl: string
): Promise<string> {
  const { data } = await crun.post('/tasks/video', {
    model,
    prompt,
    duration: 5,
    webhook: {
      url: webhookUrl,
      events: ['succeeded', 'failed'],  // Only fire on terminal states
    },
  })

  // Returns immediately with task_id — no blocking
  return data.task_id
}

Your webhook receiver (Express/Fastify/any framework):

// routes/webhook.ts
import { Router } from 'express'
import { db } from '../db'
import { notifyUser } from '../notifications'

const router = Router()

router.post('/webhook/crun', async (req, res) => {
  // ✅ Respond within 5 seconds or Crun will retry the webhook
  // Acknowledge first, then process async
  res.json({ received: true })

  const { task_id, status, output, error } = req.body

  try {
    if (status === 'succeeded') {
      await db.tasks.update(task_id, {
        status: 'done',
        videoUrl: output.url,       // Persistent URL — save it directly
        completedAt: new Date(),
      })
      await notifyUser(task_id)

    } else if (status === 'failed') {
      await db.tasks.update(task_id, {
        status: 'failed',
        errorMessage: error,
      })
    }
  } catch (err) {
    console.error(`[webhook] Failed to process task ${task_id}:`, err)
    // Don't re-throw — response already sent
    // Queue for retry via your job system instead
  }
})

export { router as webhookRouter }

⚠️ Critical: Send your 200 response before doing any async work. If your handler takes longer than 5 seconds to respond, the webhook will be retried — and you'll process the same completion event twice. The pattern above (respond → process async) is the right structure.

Step 5: Unified File URL — No More Expiry Bugs

This one deserves its own section because it's bitten so many teams.

When you integrate directly against most model APIs, the file URLs they return are temporary. They might be valid for 1 hour, 12 hours, or 24 hours depending on the provider. If your users access the URL after it expires — empty. If your queue runs slow and picks up a job 13 hours later — the file is gone.

Crun.ai API handles file storage for you. The URLs in output.url are persistent. You can store them directly in your database and reference them indefinitely.

That said, if you ever need to move files to your own storage (your own S3/OSS bucket for compliance, CDN reasons, etc.), here's a clean utility:

// lib/storage.ts
import fs from 'fs'
import path from 'path'
import axios from 'axios'

export async function downloadToLocal(
  sourceUrl: string,
  destPath: string
): Promise<void> {
  const response = await axios.get(sourceUrl, {
    responseType: 'stream',
    timeout: 60_000,
  })

  await new Promise<void>((resolve, reject) => {
    const writer = fs.createWriteStream(destPath)
    response.data.pipe(writer)
    writer.on('finish', resolve)
    writer.on('error', reject)
  })

  console.log(`Saved to: ${path.resolve(destPath)}`)
}

// Usage
await downloadToLocal(result.url, './outputs/product-video.mp4')

Step 6: Reusable Retry Wrapper

Network errors happen. Model services have transient blips. Here's a retry decorator that works across all your Crun.ai API calls — image, video, text, everything.

// lib/retry.ts

interface RetryOptions {
  maxAttempts?: number
  baseDelayMs?: number
  maxDelayMs?: number
  shouldRetry?: (error: Error, attempt: number) => boolean
}

export async function withRetry<T>(
  fn: () => Promise<T>,
  options: RetryOptions = {}
): Promise<T> {
  const {
    maxAttempts = 3,
    baseDelayMs = 1_000,
    maxDelayMs = 30_000,
    shouldRetry = defaultShouldRetry,
  } = options

  let lastError: Error

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn()
    } catch (err) {
      lastError = err as Error

      if (attempt === maxAttempts || !shouldRetry(lastError, attempt)) {
        throw lastError
      }

      // Exponential backoff + jitter to prevent thundering herd
      const exponential = baseDelayMs * Math.pow(2, attempt - 1)
      const jitter = Math.random() * 1_000
      const delay = Math.min(exponential + jitter, maxDelayMs)

      console.warn(`[retry] Attempt ${attempt} failed. Retrying in ${Math.round(delay)}ms...`)
      await new Promise((r) => setTimeout(r, delay))
    }
  }

  throw lastError!
}

function defaultShouldRetry(error: Error, attempt: number): boolean {
  const message = error.message
  // Don't retry client errors (4xx) — those are our fault
  if (message.includes('400') || message.includes('401') ||
      message.includes('403') || message.includes('422')) {
    return false
  }
  // Do retry server errors (5xx) and network failures
  return true
}

Using it is clean:

// Wrap any call with automatic retry
const image = await withRetry(
  () => generateImage('a golden retriever on a beach', 'flux'),
  { maxAttempts: 3, baseDelayMs: 1_000 }
)

// Works identically for video
const taskId = await withRetry(
  () => submitVideoTask(prompt, 'kling', webhookUrl),
  { maxAttempts: 2 }
)

Same retry logic. Every model. One implementation.

The Complete Flow, End to End

Here's how these pieces fit together in a real request handler:

// Example: Express route that handles both image and video generation
import { withRetry } from './lib/retry'
import { generateImage } from './lib/image'
import { submitVideoTask } from './lib/video-webhook'
import { db } from './db'

app.post('/api/generate', async (req, res) => {
  const { type, prompt, model } = req.body

  try {
    if (type === 'image') {
      const result = await withRetry(() => generateImage(prompt, model))
      await db.assets.create({ type: 'image', url: result.url, taskId: result.taskId })
      return res.json({ success: true, url: result.url })
    }

    if (type === 'video') {
      const taskId = await withRetry(() =>
        submitVideoTask(prompt, model, `${process.env.SERVER_URL}/webhook/crun`)
      )
      await db.tasks.create({ taskId, status: 'pending', type: 'video' })
      return res.json({ success: true, taskId, status: 'pending' })
    }

    res.status(400).json({ error: 'Invalid generation type' })

  } catch (err) {
    console.error('[generate] Error:', err)
    res.status(500).json({ error: (err as Error).message })
  }
})

Clean. Typed. Handles both sync and async generation patterns through the same route.

Quick Reference: Common Errors

Error	Likely Cause	Fix
`401: Unauthorized`	Wrong or missing API key	Check `Authorization: Bearer <key>` header format
`422: Unprocessable Entity`	Invalid parameter value	Check `duration` (only `5` or `10`), `size` format
`429: Too Many Requests`	Rate limit hit	Add backoff in retry wrapper, reduce concurrency
`task status: failed`	Content filter or prompt issue	Check prompt for policy violations, simplify
Webhook not received	Server not publicly accessible	Use ngrok locally, verify URL in Crun dashboard

What Changed for Our Team

After migrating:

AI-related maintenance tickets: from ~11/quarter to ~1/quarter
Lines of AI integration code: from ~2,400 to ~380 (our code) + shared client
Time to add a new AI capability: from ~1.5 days to ~2 hours
Model switching for A/B tests: from 2-day migration to 1-line config change

The biggest change wasn't the numbers — it was that my engineers stopped treating the AI integration layer as "the thing that randomly breaks." It became infrastructure. Stable, boring, reliable infrastructure.

That's the goal.

Wrapping Up

The pattern here isn't magic — it's just good software engineering applied to AI integrations. Normalize your interfaces early, before your integration surface area becomes a domain unto itself.

Crun.ai API gives you a clean Task abstraction that handles the provider differences so you don't have to. If you're building an AI-powered app and you're on your second or third model integration, it's worth considering before the sprawl compounds.

The full repo for the examples in this post: bookmark it, fork it, adapt it.

Drop a comment if you've hit similar SDK sprawl issues — curious how others have approached it. 👇

How I Rebuilt My Entire User Feedback Workflow with FeedLog (And Why I Ditched Canny)

Gloria — Mon, 01 Jun 2026 03:19:11 +0000

Six months into running my SaaS, my "feedback system" was three browser tabs, a starred Gmail folder, and a sticky note on my monitor that said "check Discord."

That was the whole system.

It held together until the day I found a three-paragraph email from a paying user — a genuinely detailed feature request with a real use case — sitting unread for 24 days. His last line was: "Happy to pay more if you can support this."

I replied the same afternoon I found it.

His reply: "Switched last week, thanks anyway."

That was the moment I stopped treating feedback management as a nice-to-have.

Why the usual fixes didn't fix anything

I tried the obvious things first. I want to document them because I see a lot of people cycling through the same failed solutions.

Notion database 🪦

Built a beautiful one. Color-coded tags, priority columns, status tracking. It lasted 11 days before nobody — including me — was maintaining it. The friction of "open Notion, find the right database, fill in six fields" is invisible when you're designing the system and fatal when you're in the middle of a support conversation.

Airtable form 🪦

Better entry point, still disconnected from where users actually were when they had feedback. Nobody bookmarks your Airtable form. They DM you on Discord and you think "I'll add that later" and you don't.

Canny — this one actually worked, for a while

I genuinely liked Canny. Clean interface, users could upvote requests, I could see what was popular. It felt like a real system.

Then our user count grew and the pricing tier jumped. I was looking at $99/month for a feedback board for a product still finding its footing. That's not a moral judgment on Canny — it's a fair product — but for a bootstrapped indie dev, it started feeling like a tax on momentum.

The deeper problem with all three solutions was the same: they were inboxes, not loops.

User submits → enters the void → user never knows if anyone saw it → user assumes nobody did → trust erodes → churn.

I had built a place to receive feedback. I had not built a way to respond to it at scale.

What I was actually looking for

Before I started evaluating new tools, I wrote down what a real system needed to do:

1. One place for feedback from every channel
   (Discord, email, in-app, wherever)

2. Something that helps me find signal in the noise
   (not just more data — actual insight)

3. A way for users to see that their input matters
   (visibility into what's planned)

4. Proof that the product is alive and improving
   (something users can point to)

Most tools I evaluated checked box 1. A few checked box 2. Almost none addressed 3 and 4 — which, in retrospect, are the ones that actually affect retention.

Finding FeedLog

I found FeedLog the way I find most good tools: buried in a Reddit comment thread.

Someone asked for Canny alternatives in r/SaaS. A reply mentioned FeedLog — open-source, self-hostable, AI-powered deduplication. I clicked with low expectations.

The GitHub repo: https://github.com/linkcraftstudio/feedlog

What I found wasn't a half-finished side project. It was a complete platform built around three modules that mapped almost exactly to my list:

My requirement	FeedLog module
One place for all feedback	Feedback — centralized collection with AI auto-classification
Signal from noise	Feedback — AI deduplication clusters similar requests
Users see what's planned	Roadmap — public-facing, live product roadmap
Proof the product is alive	Changelog — every update documented and visible

I deployed the Vercel version in about 20 minutes. (They also support Docker and Cloudflare Workers — I've since moved to Docker on my own VPS for data sovereignty reasons, which I'll get to.)

The setup, honestly

No sugarcoating here because I know devs hate vague "it was easy!" writeups.

Vercel deploy: Fork the repo, connect to Vercel, set your environment variables (database URL, NextAuth secret, OpenAI API key for AI features), deploy. The README is clear. I hit one issue with the DB migration step that I resolved by checking the GitHub Issues — someone had the same problem two weeks earlier, fix was already there.

Environment variables you'll need:

DATABASE_URL=             # PostgreSQL connection string
NEXTAUTH_SECRET=          # run: openssl rand -base64 32
NEXTAUTH_URL=             # your deployment URL
OPENAI_API_KEY=           # for AI dedup/classification (optional but worth it)

Time to first feedback submitted: About 35 minutes from zero.

Docker self-host (what I use now):

git clone https://github.com/linkcraftstudio/feedlog.git
cd feedlog
cp .env.example .env
# edit .env with your values
docker compose up -d
docker compose exec server npx prisma migrate deploy

Running on a $6/month VPS. Total infra cost including the server: ~$8/month with OpenAI usage. Previous Canny cost: $99/month.

What actually changed — with specifics

The dedup surfaced a blind spot

When I migrated historical feedback into FeedLog, the AI clustered roughly 65 items into 24 distinct themes.

One cluster had 13 entries from 13 different users, all describing the same workflow gap in completely different language. I had mentally registered that problem as "two or three people mentioned this." It was our single most-requested improvement, invisible to me because each signal arrived in a different channel with different wording.

That cluster went straight to the top of our next sprint. We shipped it three weeks later. The users who had submitted that feedback got a Changelog notification that explicitly referenced their requests. Two of them upgraded their plans within the same week.

I can't prove causation. But I notice the correlation.

The public Roadmap changed the conversation dynamic

Before: Discord was full of "any update on X?" and "is Y on the roadmap?" messages. Each one required a manual response. Each unanswered one was a small withdrawal from the trust account.

After: I pointed users to the public Roadmap. The "when is X coming?" traffic dropped noticeably. Users who wanted to know where things stood could find out themselves.

What I didn't expect: users started commenting on Roadmap items. Not just checking — participating. The Roadmap became a live conversation rather than a static list. Users who engaged with it in this way felt more invested in the product. That's not a metric I track, but I feel it in the texture of the community.

Changelog entries closed loops I didn't know were open

Every release, I now write a FeedLog Changelog entry. Not just "v2.3 released." Specifically:

"You asked for [X]. We built it. Here's how it works."

A user whose feature request was referenced in a Changelog replied in Discord: "You actually shipped it. That doesn't happen."

That response tells you everything about how low the bar is. Users have learned to expect silence. When you close the loop with evidence, it registers.

The data ownership piece (this mattered to me)

User feedback is not just operational data. It's strategic intelligence.

It tells you what users actually want, how they think about problems, which competitors they're comparing you to, and what frictions are closest to causing churn. Having all of that sitting on a third-party SaaS platform — accessible by their team, subject to their pricing changes, vulnerable to their acquisition or shutdown — is a risk that grows as your product becomes more valuable.

FeedLog self-hosted means that data is on my infrastructure. MIT licensed code means I can see exactly what runs. No vendor lock-in, no pricing surprises as we scale.

This might sound like an edge concern for an early-stage product. I've started thinking of it as hygiene.

Honest limitations

I want to be useful here, not just promotional:

Integration ecosystem: No native Slack or Discord sync yet. I handle this with a simple webhook but it requires some setup.
Mobile admin UX: Functional, not polished. I review feedback on desktop.
Community size: Smaller than Canny's. GitHub Issues is responsive, but you're not getting 24/7 enterprise support.
Age: It's a younger project. Some edges are rougher than a tool that's had years of polish.

If you need deep CRM integrations, advanced user segmentation by plan tier, or SLA-backed support on day one — Canny is probably still your tool. FeedLog is built for teams where the dev and the product manager are sometimes the same person.

Summary: what the stack looks like now

Feedback channels:  Discord → FeedLog widget → Feedback board
                    Email   → forwarding rule → Feedback board
                    In-app  → embedded widget → Feedback board

Processing:         AI dedup + clustering (weekly review)
                    Manual prioritization based on cluster size

User communication: Public Roadmap (what's planned)
                    Changelog (what shipped, tied to requests)

Infrastructure:     Docker on $6/mo VPS
                    PostgreSQL (bundled)
                    OpenAI API for AI features (~$2/mo)

Total cost:         ~$8/month
Previous cost:      $99/month

The actual lesson

The problem I had wasn't that I lacked a place to collect feedback. I had several places.

The problem was that feedback collection and feedback response are two different capabilities, and I had built one while ignoring the other.

FeedLog is the first tool I've used that treats both halves as equally important — and connects them through a public-facing Roadmap and Changelog that make the loop visible to users, not just to the team.

That visibility is what changes user behavior. Not the tooling. The transparency.

→ https://feedlog.ai/
→ GitHub (⭐ appreciated): https://github.com/linkcraftstudio/feedlog

How are you currently managing feedback across multiple channels? Genuinely curious — drop your setup in the comments. Especially interested if anyone has found a clean Discord-to-feedback-board pipeline.

Skip the FFmpeg One-Liner: How Developers Can Trim Screen Recordings Instantly with Video Cutter (No CLI Needed)

Gloria — Fri, 22 May 2026 03:25:48 +0000

Here's a scenario I ran into last month that I'm guessing isn't unique to me.

I recorded a 40-minute code review session with OBS. The first five minutes are me dragging windows around, resizing the terminal, and muttering "can you hear me okay?" The last ten minutes are a Zoom black screen slowly fading out after everyone left the call. The actual useful content? Roughly 25 minutes, sandwiched in the middle.

My team needed that recording shared by end of day.

My first instinct: fire up FFmpeg. It's what I always reach for when I need to cut video without re-encoding. But then I hit the usual friction point — I didn't actually know the exact timestamps. I had to scrub through the file in VLC first, note the start and end, then run the command.

That's when I started questioning whether the CLI is always the right tool for this job.

The FFmpeg Approach: Powerful, but Not Always the Right Fit

Let's be real — FFmpeg's stream-copy trim is genuinely great for a lot of situations:

ffmpeg -i input.mkv -ss 00:05:12 -to 00:34:47 -c copy output.mkv

The -c copy flag means no re-encoding. It's fast, lossless, and if you already know your timestamps, it's done in seconds. For batch scripts, automation pipelines, or CI workflows that process video assets, FFmpeg is the correct answer, full stop.

But there's a gap in the workflow that this command doesn't address well: the exploratory trim, where you don't know the exact cut points yet.

The actual steps look more like this:

Open the file in a media player
Scrub to where the useful content starts, note the timestamp
Scrub to where it ends, note that timestamp
Open a terminal
Construct and run the FFmpeg command
Check the output
Realize your keyframe alignment was slightly off, adjust, re-run

For a one-off trim — especially one you're doing at 5pm when you just want to share the recording and go home — that's a lot of steps for a task that feels like it should take 30 seconds.

The Second Problem: Your Non-Technical Teammates

Here's the part that comes up more often than I expected.

Your PM watches the raw recording, finds something useful in it, and wants to share a trimmed clip in Slack. Your designer needs to cut down a user research session to the relevant 10 minutes for a stakeholder review.

You can't tell them to install FFmpeg. You also can't justify making them install Premiere for a single clip trim. And most "free" online tools you'd typically recommend come with one of the following surprises:

Forced account creation before you can export
A watermark you only discover at download time
A file size cap that blocks their 800MB recording
Format rejection because their Zoom export was .mp4 but something about the encoding triggers an error

The team ends up pinging you to "just do it real quick" — and now you're the video editing help desk.

Where Video Cutter Fits Into This

I started using Video Cutter for exactly these two scenarios: my own quick one-off trims where I don't want to leave the browser, and as the tool I send teammates when they need to do something simple without needing me involved.

It's browser-based, zero install, zero account. You open it, upload your file, trim it, download it. That's the full interaction model.

A few things that matter to me as a developer:

Dual input modes. There's a timeline scrubber for when you're exploring and don't have exact timestamps, and a time input field for when you do. I usually scrub first to find the cut points visually, then fine-tune using the text field. It's a small UX decision that removes the "watch first, then run command" loop from my workflow.

Format support that actually covers what developers produce. MKV (OBS default), MP4 (Zoom, screen capture tools, phones), MOV (macOS QuickTime, iOS), AVI (older tools, some cameras). All four formats work without pre-conversion. The MKV support specifically matters — OBS users know that .mkv is the safer recording format because it's recoverable if something crashes mid-recording, but a lot of online tools choke on it.

No re-encoding visible degradation. Output quality is consistent with the source. You're not getting a compressed-again version of your recording.

The Privacy and Security Angle (Developer Perspective)

This one deserves a direct mention, because screen recordings are often sensitive.

Internal code reviews. Debugging sessions with client credentials partially visible. Architecture discussions with unreleased product details. These aren't files you want processed by a server you don't control, logged somewhere, or associated with an account tied to your email.

Video Cutter processes files client-side in the browser. The video doesn't leave your machine for server-side processing. No account means no user record, no stored session, no email associated with the upload. There's genuinely no persistence layer on the user data side.

For the occasional developer who's had to think about where their screen recordings end up, this matters.

Format Compatibility: What's Actually Covered

Quick reference for where these formats come from in a dev context:

Format	Common Source
MKV	OBS Studio (default recording format)
MP4	Zoom, Google Meet, Loom, most phones
MOV	macOS screen recording, iOS, QuickTime
AVI	Older capture tools, some Bandicam configs

All four are supported without any pre-conversion step. If you've ever used an online tool that claimed MP4 support but silently failed on your specific MP4 encoding variant, the format tolerance here is meaningfully broader than the typical online trimmer.

FFmpeg vs. Video Cutter: These Aren't Competing

To be clear about what I'm actually recommending here: this isn't a "stop using FFmpeg" argument. These two tools solve different shapes of the same problem.

Scenario	What I reach for
Batch-trimming 20 recordings with known timestamps	FFmpeg in a shell script
Automated pipeline that processes video as part of CI	FFmpeg
Single recording, need to find the cut points first	Video Cutter
Teammate needs to trim their own recording without help	Video Cutter
Need lossless cut at exact keyframe with specific codec params	FFmpeg
5pm, just want this shared, done in under 2 minutes	Video Cutter

The mental model I've settled on: FFmpeg is the right answer when you're scripting or automating. Video Cutter is the right answer when you're doing something once and the overhead of constructing the command isn't worth it.

Neither tool is always correct. The useful thing is knowing when each one fits.

Workflow Summary: What This Actually Looks Like

For my own quick trims:

Open Video Cutter in the browser
Upload the OBS .mkv (drag and drop works)
Scrub the timeline to find where the real content starts
Fine-tune the timestamp in the input field
Do the same for the end point
Export and download

Total time for a 40-minute recording: under 3 minutes, including the scrubbing.

For teammates: I share the URL and tell them to upload their file, move the sliders, and download. No further instructions needed. I haven't had a follow-up question about it yet.

TL;DR

FFmpeg -c copy is still the best option for batch processing, scripting, and when you already know your exact timestamps. Nothing changes there.
Video Cutter fills the gap for one-off exploratory trims where you need to find the cut points visually first, or when you're sending a non-technical teammate somewhere that doesn't require your help to operate.
MKV, MP4, MOV, AVI all supported. No account. No watermark. Client-side processing means your recordings stay on your machine.

If your team produces screen recordings regularly and you find yourself being the informal "can you just trim this" person, this is a reasonable thing to bookmark.