DEV Community: Kazutaka Sugiyama

My First Paying Customer Hit a Bug 14 Times in a Row — Here's What I Found

Kazutaka Sugiyama — Fri, 27 Mar 2026 09:14:35 +0000

You know what's worse than having zero customers?

Having your first customer — someone who just paid you real money — fail to use your product 14 times in a row while you sleep through it.

The Context: 5 Weeks of Silence

I run RepoClip, a SaaS that auto-generates promotional videos from GitHub repositories. I launched on February 19, 2026. For five weeks, the revenue dashboard showed exactly $0.00.

Then on March 26, everything changed at once.

FutureTools featured us in their newsletter. Traffic exploded — 163 real users in a single day (vs. our usual ~10). I'd also just shipped a Credit Pack feature: a one-time $5 purchase for 40 credits, aimed at users who want to try video mode without committing to a subscription.

By 9:50 AM UTC, I had my first sale. Nenad from Belgrade bought a Credit Pack. Then at 10:43, he bought another one.

$10 in revenue. My first paying customer.

I found out the next morning that he'd spent the next 2.5 hours trying to generate a video — and failing every single time.

The Symptom: 14 Consecutive Failures

Digging into the data, Nenad's journey looked like this:

Time (UTC)	Action	Result
09:50	Credit Pack #1 ($5)	+40 credits
10:43	Credit Pack #2 ($5)	+40 credits
10:51	Image mode generation	Success
~11:00	Video Short attempt #1	Failed
~11:03	Video Short attempt #2	Failed
...	...	...
~13:30	Video Short attempt #14	Failed

Every single Video Short generation failed. Image mode worked fine. He kept retrying for 2.5 hours before giving up.

Bug #1: The Silent Upload Failure

I opened the Inngest dashboard and filtered for failed runs. 18 failures stared back at me — all Video Short generations, all from March 26.

The error message: "All 3 video clips failed to prefetch from CDN — rendering would likely fail"

But here's what the execution trace showed:

Pipeline Step	Duration	Status
fetch-github-code	~29s	Success
analyze-code (Gemini)	~20s	Success
generate-narrations (TTS)	~4s	Success
generate-videos-ltx	~1min	Success
prefetch-videos	1.6s	Failed

The video clips were generated successfully by LTX-2.3. The failure was in the prefetch step — where we download the clips from fal.ai's CDN and re-upload them to Supabase Storage to avoid rendering timeouts.

The code looked reasonable at first glance:

const { error } = await supabase.storage
  .from("assets")
  .upload(storagePath, buffer, {
    contentType: "video/mp4",
    upsert: true,
  });

if (error) {
  console.warn(`Upload failed for ${video.sceneId}:`, error.message);
  return video; // Return original CDN URL
}

See the bug? When the Supabase upload fails, it logs a warning and returns immediately — no retry. Compare this to the CDN download failure path just above it, which properly retries with backoff.

And when all clips fail to upload, the parent function throws:

if (cached === 0 && videos.length > 0) {
  throw new Error(
    `All ${videos.length} video clips failed to prefetch from CDN — rendering would likely fail`
  );
}

So: CDN download succeeds, Supabase upload fails silently (no retry), error count hits 100%, and the entire pipeline throws. Every time.

The fix: Add retry logic to the upload path, and fall back to CDN URLs instead of throwing when all prefetch attempts fail. The videos exist — let Remotion try to render with them.

Bug #2: The Phantom Pro Subscription

While investigating, I noticed something strange in GA4. A purchase_complete event showed plan: "pro", billing_cycle: "annual". But Lemon Squeezy recorded only three Credit Pack purchases — no Pro subscription at all.

Nenad's journey explained it:

He visited the /pricing page and toggled to annual billing while viewing the Pro plan
PricingButton component called window.LemonSqueezy.Setup() — registering a global event handler with plan: "pro" baked into its closure
He navigated to /dashboard/new where BuyCreditsButton registered its own handler
When his Credit Pack checkout succeeded, the old handler from the pricing page was still alive
Both handlers fired — the stale one logged a phantom Pro Annual purchase

The Lemon Squeezy SDK keeps event handlers on a global window object. Next.js client-side navigation doesn't reset it.

// The fix: track mount state, ignore events after unmount
const mountedRef = useRef(true);
useEffect(() => {
  return () => { mountedRef.current = false; };
}, []);

// In the event handler:
if (!mountedRef.current) return;

Bug #3: The Content Filter Lottery

After deploying the prefetch fix, I tested Video Short myself with a different repo. It failed again — but with a new error: "Unprocessable Entity".

This time the prefetch step was never reached. LTX-2.3 itself was rejecting the video prompts with HTTP 422.

I tested all 5 scene prompts individually:

Scene	Original Prompt	Sanitized	Result
intro	Camera pans over a desk...	-	OK
ai_learning	Virtual AI assistant chatbot...	Stripped special chars	OK after sanitize
targeted_study	Dashboard with 'weakness' section...	Stripped quotes	Still failed
flexible_review	Hand tapping through flashcards...	-	OK
call_to_action	Hands holding smartphones...	-	OK

One scene out of five was rejected, but because all scenes run inside Promise.all(), one rejection kills the entire batch.

The existing sanitizer removed brackets and code-like characters, but missed single quotes. And even after stripping those, the word combination kept triggering LTX's content filter. The filter rules are opaque — "legal news" fails but "legal documents" passes. It's not deterministic.

The fix was a 3-stage fallback:

const prompts = [
  originalPrompt,                          // Stage 1: Try as-is
  sanitizeVideoPrompt(originalPrompt),     // Stage 2: Strip risky chars
  FALLBACK_PROMPTS[index % FALLBACK_PROMPTS.length], // Stage 3: Safe generic prompt
];

Stage 3 uses pre-tested abstract motion graphics prompts that always pass the content filter. The video won't match the scene's narration perfectly, but the pipeline won't crash.

The Human Cost

Nenad spent $10 and 2.5 hours on a product that didn't work. His credit balance wasn't affected (credits are only deducted on success), but his time and trust were gone.

I sent him a personal apology email, added 40 bonus credits to his account, and explained what went wrong and that it was fixed. The technical honesty matters — he's a developer, he'll appreciate knowing it was a real bug, not handwaving.

What I Learned

1. Retry every I/O operation, not just the ones you expect to fail.

I had retries on CDN downloads (expected to be flaky) but not on Supabase uploads (expected to be reliable). The upload was the one that broke.

2. throw in a data pipeline is a nuclear option.

Throwing when all prefetches fail seemed conservative. In practice, it meant "if storage has a hiccup, destroy the entire 2-minute pipeline run." A warning + fallback would have let the video render successfully.

3. Global event handlers leak across SPA navigation.

Third-party SDKs (Lemon Squeezy, Stripe, etc.) that register on window don't clean up on React unmount. Always guard with a mounted ref.

4. AI content filters are a black box.

You can't enumerate what LTX-2.3 will reject. The only reliable strategy is fallback — try progressively safer prompts until one passes.

5. Your first customer is watching closer than anyone.

163 people visited that day. Most bounced. Nenad was the one who believed enough to pay. Of all the users to hit a bug, it was the one whose experience mattered most.

The Timeline

Time	Event
Mar 26, 09:50 UTC	First Credit Pack sale
Mar 26, 10:43	Second Credit Pack sale
Mar 26, 11:00–13:30	14 failed Video Short attempts
Mar 27, 07:00	Investigation begins
Mar 27, 07:30	Root cause identified (prefetch + GA4 + content filter)
Mar 27, 08:00	Fixes deployed
Mar 27, 08:08	First successful Video Short post-fix
Mar 27, 08:30	Apology + 40 bonus credits sent to Nenad

If you're building a SaaS with AI pipelines, I hope this saves you from the same mistakes. Every I/O boundary needs a retry. Every throw needs a fallback. And every first customer deserves an apology when things break.

RepoClip — AI-powered videos from your GitHub repos.

My Safety Check Killed 100% of Video Generations — Right When Traffic Spiked 3x

Kazutaka Sugiyama — Fri, 20 Mar 2026 15:44:50 +0000

You know what's worse than a bug in production?

A bug you introduced while fixing another bug — deployed at midnight, right when your biggest traffic spike ever is happening.

The Setup: Our Best Day Ever

I run RepoClip, an AI-powered SaaS that generates promotional videos from GitHub repositories. On March 19, 2026, console.dev featured us in their newsletter.

Traffic exploded:

Day	Active Users	New Users
March 19 (feature day)	448	445
March 20 (day after)	154	139

448 users. For a solo indie SaaS, that felt massive.

But there was a problem I wouldn't discover until 24 hours later.

The "Fix" That Broke Everything

Earlier on March 19, I noticed that some video generations were failing because Remotion Lambda (our video renderer on AWS) couldn't download images from fal.ai's temporary CDN URLs fast enough. The URLs were expiring or timing out.

So at midnight (00:20 JST, March 20), I shipped what I thought was a solid improvement:

Pre-fetch all media from fal.ai CDN → Supabase Storage before rendering
Add retry logic — 3 attempts with exponential backoff
Throw early if all clips failed to prefetch, instead of sending unreliable URLs to the renderer

That third point was the killer. Here's the diff:

// video-prefetch.ts — the "improvement"

const cached = results.filter((r, i) => r.url !== videos[i].url).length;

if (cached === 0 && videos.length > 0) {
  throw new Error(
    `All ${videos.length} video clips failed to prefetch from CDN`
  );
}

My reasoning: "If we can't cache any clips locally, Remotion will probably fail anyway. Let's fail fast and give the user a clear error instead of wasting 5 minutes on a doomed render."

It sounded so reasonable.

The Data I Should Have Checked First

The next evening, I ran a query against our projects table:

SELECT status, content_mode, COUNT(*) as cnt
FROM projects
WHERE created_at >= '2026-03-19T15:00:00+00:00'  -- after deploy
  AND created_at < '2026-03-20T15:00:00+00:00'
GROUP BY status, content_mode;

Status	Mode	Count
failed	video_short	10
completed	image	3

Zero. Not a single video succeeded after my deploy.

Every single failure had the same message:

All 3 video clips failed to prefetch from CDN — rendering would likely fail

Meanwhile, before my fix on the same day:

Status	Mode	Count
completed	video_short	22
failed	video_short	7
completed	image	6
failed	image	8

76% video success rate before. 0% after. My "safety check" didn't just fail to help — it made things infinitely worse.

Why My Assumption Was Wrong

Here's what I didn't understand about my own infrastructure:

The prefetch path (broken):
  Inngest (Vercel Edge) → fal.media CDN → frequently times out

The render path (working fine):
  Remotion Lambda (AWS us-east-1) → fal.media CDN → usually succeeds

The prefetch runs on Vercel's serverless infrastructure. Remotion Lambda runs on AWS in us-east-1. The network path from AWS to fal.ai's CDN was far more reliable than from Vercel.

Before my fix, when prefetch failed, the code silently fell back to the original fal.media URLs. Remotion Lambda would then download them directly — and it usually worked. The 7 pre-fix failures were mostly unrelated issues (prompt rejections, Lambda crashes), not CDN problems.

By adding the throw, I cut off the fallback path entirely. The pipeline would die at the prefetch step without ever giving Remotion a chance to try.

The Human Cost

6 unique users were affected. All on the free plan, all trying video generation for the first time:

User	Failed Attempts
rafael@...	3
gabomaldi@...	2
ale@...	2
enzo@...	1
moussan@...	1
tthorjen@...	1

These were people who came from console.dev, signed up, and tried to generate a video — our core product experience. One user tried 3 times before giving up.

The silver lining: our pipeline deducts credits only on success (Step 13, after status: "completed"), and failed projects are excluded from the free allowance count. So no one lost credits, and they could retry. But the first impression was ruined.

The Fix: One Line

  if (cached === 0 && videos.length > 0) {
-   throw new Error(
-     `All ${videos.length} video clips failed to prefetch from CDN`
+   console.warn(
+     `[video-prefetch] All ${videos.length} clips failed to prefetch — falling back to original CDN URLs`
    );
  }

That's it. Keep the retry logic (it helps when it works), but don't block the pipeline when it doesn't. Let Remotion Lambda try the direct download path.

The Uncomfortable Lesson

I've seen this pattern before, and I'll probably see it again:

"Fail fast" is not always the right answer.

In a pipeline with multiple fallback paths, throwing early can be worse than doing nothing. My prefetch-to-Supabase step was an optimization, not a requirement. The system had a perfectly good fallback — Remotion downloading directly from fal.media — and my throw statement eliminated it.

The mental model I had:

prefetch fails → render will fail → fail fast = better UX

The reality:

prefetch fails → render might succeed via different network path → fail fast = 0% success

Rules I'm Taking Away

Measure the fallback before removing it. I never checked how often Remotion Lambda could download from fal.media directly. If I had, I'd have seen it was ~90%+ reliable.
"Probably will fail" ≠ "will fail." My error message literally said "rendering would likely fail." Likely isn't certainly. Don't throw on likely.
Deploy ≠ done. I shipped at midnight and went to sleep. The next morning I was celebrating the traffic spike, not checking if video generation still worked.
Your biggest traffic day is your worst day for bugs. Murphy's law for SaaS: the feature that brought all those users? They tried the thing that was broken.

Timeline

Time (JST)	Event
Mar 19, 17:00	console.dev features RepoClip — traffic spikes
Mar 19, ~23:00	I notice some CDN-related render failures
Mar 20, 00:20	Deploy prefetch retry + throw on failure
Mar 20, 02:16	First post-deploy video generation fails
Mar 20, 22:27	Last failure before I investigate
Mar 20, 23:30	I discover 0% video success rate
Mar 21, 00:15	One-line fix deployed

24 hours of broken video generation. During our highest-traffic period ever.

If you're building a media pipeline with external CDN dependencies, don't assume your serverless function's network path is the same as your renderer's. And if you're adding safety checks — make sure you're not removing a working fallback.

RepoClip turns GitHub repos into promotional videos. It works again now. Probably. 😅

Have you ever shipped a "fix" that made things worse? I'd love to hear your story in the comments.

Our Videos Silently Failed for a Week — How a Stale Env Var Cost Us $60 and 12 Unhappy Users

Kazutaka Sugiyama — Mon, 09 Mar 2026 10:01:33 +0000

You know that sinking feeling when you check your billing dashboard and something doesn't add up?

That's how this started. I noticed RepoClip — my AI video generation SaaS — was burning through $20/day on fal.ai credits for three consecutive days. My first thought was optimistic: "Great, more users are trying the product!"

I was wrong. The money was being spent. The videos were being generated. But not a single user was getting their finished video.

The Symptom: $60 Burned, Zero Videos Delivered

RepoClip generates promotional videos from GitHub repos. The pipeline looks like this:

GitHub URL → Gemini Analysis → Kling Video Clips (fal.ai) → Remotion Lambda Render → Done

Each "Video Short" generates 5 AI video clips using Kling 3.0 Pro on fal.ai, then stitches them together with narration using Remotion on AWS Lambda.

When I checked the fal.ai dashboard, I saw $20/day being consumed on March 7, 8, and 9. That's roughly 2–4 video generations per day. Seemed plausible for organic traffic.

But then I queried the database:

SELECT
  created_at::date AS date,
  status,
  COUNT(*) AS count
FROM projects
WHERE created_at >= '2026-03-01'
GROUP BY date, status
ORDER BY date;

The result was alarming:

Date	Status	Count
Mar 1	completed	3
Mar 1	failed	5
Mar 1	rendering	1
Mar 2	rendering	2
Mar 5	rendering	1
Mar 6	rendering	2
Mar 7	rendering	2
Mar 8	rendering	4

After March 1, not a single project reached "completed". Every video was stuck in "rendering" — the step right after fal.ai finishes generating clips.

The fal.ai credits were being consumed successfully. The Kling clips were generated and saved. Then the pipeline just... stopped.

The Investigation: Following the Money

The video pipeline runs on Inngest, which breaks the work into discrete steps. Each step is memoized — if the function retries, completed steps aren't re-executed. The relevant steps:

Fetch GitHub code
Analyze with Gemini
Generate video clips (fal.ai) ← money spent here
Trigger Remotion Lambda render ← failure here
Poll for render completion
Update project to "completed"

Step 3 succeeded (fal.ai charged us), but Step 4 was clearly failing. The project status gets set to "rendering" just before Step 4 runs, which explains why everything was stuck there.

I checked the Remotion Lambda configuration:

# What our env var said:
REMOTION_LAMBDA_FUNCTION_NAME=remotion-render-4-0-414-mem2048mb-disk2048mb-600sec

# What actually exists in AWS:
aws lambda list-functions --query 'Functions[?starts_with(FunctionName, `remotion`)]'

remotion-render-4-0-429-mem2048mb-disk2048mb-600sec
remotion-render-4-0-429-mem3008mb-disk4096mb-900sec

There it was. The Lambda function 4-0-414 didn't exist anymore. We had upgraded Remotion from v4.0.414 to v4.0.429, deployed new Lambda functions, deleted the old ones — and never updated the environment variable on Vercel.

Every renderMediaOnLambda() call was throwing ResourceNotFoundException, silently, inside an Inngest background job that no user ever sees.

Why No One Noticed

This is the insidious part. The failure was completely invisible:

No client-side errors — the API returned a project ID successfully. Users saw "Rendering..." and waited.
No GA4 events — we tracked video_generate_start but had no video_generate_complete event. The absence of completions was invisible in analytics.
No monitoring — we had Sentry for errors, but the Inngest function's retry logic was eating the exceptions before they surfaced meaningfully.
fal.ai charges looked normal — if anything, increasing spend looked like a good sign.

The only signal was the billing anomaly — and even that was ambiguous.

The Recovery: Don't Re-generate, Re-render

Here's the silver lining: all 12 stuck projects had their assets fully saved in the database. The Kling video clips, the narration audio, the video config — everything was persisted in the assets JSONB column before the render step.

Re-triggering the full pipeline would have re-generated all the video clips on fal.ai, costing another $60+. Instead, I wrote a targeted retry script that:

Queries all projects with status = 'rendering'
Reads their saved video_config and assets
Calls renderMediaOnLambda() with the correct (new) function name
Polls for completion
Updates the project to completed
Sends the completion email

// The key insight: assets are already saved, just re-render
const { renderId, bucketName } = await renderMediaOnLambda({
  region: REGION,
  functionName: FUNCTION_NAME, // now pointing to the correct function
  serveUrl: SERVE_URL,
  composition: "ProductVideo",
  inputProps, // built from saved assets
  codec: "h264",
  // ...
});

Result: 12 out of 12 videos recovered (9 on first attempt, 3 on retry after transient network timeouts). Every user got a completion email with their finished video. Zero additional fal.ai charges.

The Prevention: Three Layers of Defense

Layer 1: Deploy Script Auto-Updates Env Vars

The root cause was a manual step that was easy to forget. The old deploy script ended with:

echo "Set the following environment variables:"
echo "  REMOTION_LAMBDA_FUNCTION_NAME=<function name from above>"

Now it automatically extracts and updates:

# Extract function name from deploy output
FUNC_NAME=$(echo "$FUNC_OUTPUT" | grep -oE 'remotion-render-[a-zA-Z0-9-]+' | head -1)

# Verify function exists
aws lambda get-function --function-name "$FUNC_NAME" --region "$REGION"

# Auto-update Vercel + local env
echo -n "$FUNC_NAME" | npx vercel env rm REMOTION_LAMBDA_FUNCTION_NAME production -y
echo -n "$FUNC_NAME" | npx vercel env add REMOTION_LAMBDA_FUNCTION_NAME production
sed -i '' "s|^REMOTION_LAMBDA_FUNCTION_NAME=.*|REMOTION_LAMBDA_FUNCTION_NAME=$FUNC_NAME|" .env.local

No more "please update manually" — the script handles it end-to-end.

Layer 2: Inngest Cron Alert for Stuck Renders

An hourly cron job checks for projects stuck in "rendering" for more than 30 minutes:

export const monitorStuckRendersFunction = inngest.createFunction(
  { id: "monitor-stuck-renders" },
  { cron: "0 * * * *" },
  async ({ step }) => {
    const stuckProjects = await step.run("check-stuck-projects", async () => {
      const threshold = new Date(Date.now() - 30 * 60 * 1000).toISOString();
      const { data } = await supabase
        .from("projects")
        .select("id, repo_name, content_mode, updated_at")
        .eq("status", "rendering")
        .lt("updated_at", threshold);
      return data ?? [];
    });

    if (stuckProjects.length > 0) {
      // Send alert email with project details
    }
  }
);

If this had existed a week ago, we'd have known within an hour instead of seven days.

Layer 3: GA4 Start/Complete Event Comparison

We added video_generate_complete and video_generate_fail events that fire when the user's browser sees the status change via Supabase Realtime:

// ProjectStatusListener.tsx
const channel = supabase
  .channel(`project-${projectId}`)
  .on("postgres_changes", { /* ... */ }, (payload) => {
    if (payload.new?.status === "completed") {
      gaEvent("video_generate_complete", { project_id: projectId });
    } else if (payload.new?.status === "failed") {
      gaEvent("video_generate_fail", { project_id: projectId });
    }
  })
  .subscribe();

Now our BigQuery funnel query shows the start-to-complete ratio:

SELECT
  event_date,
  COUNT(DISTINCT CASE WHEN event_name = 'video_generate_start'
    THEN user_pseudo_id END) AS start_users,
  COUNT(DISTINCT CASE WHEN event_name = 'video_generate_complete'
    THEN user_pseudo_id END) AS complete_users
FROM events_*
GROUP BY event_date

A sudden drop in the complete/start ratio is now a visible signal.

Bonus: The Cost Optimization That Came From This

While investigating, I realized every free-tier user was getting the same Kling 3.0 Pro clips as paying customers. At ~$5.60 per video, with a ~3% conversion rate, the customer acquisition cost was unsustainable.

The fix:

Free plan: Kling 3.0 Standard (3 clips, ~15s) — $2.52/video
Paid plans: Kling 3.0 Pro (5 clips, ~25s) — $5.60/video

This turns "Kling 3.0 Pro quality" into a tangible upgrade incentive while cutting free-tier costs by 55%.

Lessons Learned

1. Env vars are a silent single point of failure. Automate their lifecycle. If a deploy script creates a resource, it should update the env var that references it — in the same script, in the same run.

2. Background job failures are invisible by default. If your pipeline runs asynchronously (Inngest, Bull, SQS), you need explicit monitoring for "things that should have finished but didn't." A simple cron checking for stale statuses catches an entire class of bugs.

3. Track completion, not just initiation. We had video_generate_start in GA4 from day one. We never added video_generate_complete. The absence of data is the hardest signal to notice.

4. Persist intermediate results. The only reason we recovered without re-incurring $60+ in fal.ai charges is that every pipeline step saves its output to the database before moving on. This turned a potential re-generation into a simple re-render.

5. Billing anomalies are monitoring signals. The first hint of trouble wasn't an error log or a user complaint — it was an unexpected spend pattern. If you're running a SaaS with external API costs, set up billing alerts.

RepoClip generates AI-powered promotional videos from GitHub repositories. If you want to try it out, paste any public repo URL and get a video in minutes — free, no credit card required.

Beyond the AI Hype: How I Gained "100% Clean" Trust for My Rust-Powered Search App

Kazutaka Sugiyama — Mon, 09 Mar 2026 08:06:17 +0000

A few days ago, I shared my journey of choosing Tauri over Electron to build OmniFile, a privacy-first local search tool. The response from the community was incredible, and it reinforced my belief that performance and memory efficiency still matter deeply to developers.

However, since then, I’ve encountered a fascinating paradox in the modern software ecosystem.

I recently launched another project, RepoClip (an AI-powered tool for GitHub https://repoclip.io/). Within weeks, it was "picked up" by hundreds of AI directories, resulting in over 400 backlinks almost overnight. It was a whirlwind of automated growth.

But for OmniFile, a tool that handles sensitive local data, the "bot-driven" approach didn't work. And honestly? I’m glad it didn’t.

For utility tools that prioritize privacy, trust isn't something that can be automated by a crawler. It has to be earned. Today, I’m thrilled to share a major milestone: OmniFile has been officially listed on Softpedia and granted the "100% Clean" Award.

In this post, I want to discuss:

The stark difference between "AI Trend Hype" and "Utility Trust."
Why a single authoritative listing (like Softpedia) outweighs 400 automated links.
How to navigate the rigorous security reviews for desktop apps in 2026.

Section 1: The Illusion of "400 Backlinks" (AI Directory Hype)

One morning, I checked Ahrefs for my new AI project, RepoClip, and was stunned: 400+ backlinks in less than a month.

I hadn't done much—just listed it on a few major platforms like Futurepedia and Product Hunt. Then, the "bots" took over. In the current AI gold rush, hundreds of directory sites use automated crawlers to scrape new tools. They copy your description, tag it with "AI," and link back to you instantly.

It feels great for SEO metrics, but there’s a catch: These links are often empty calories. They provide high volume but low trust. They are essentially "digital posters" put up by robots for other robots.

Section 2: Why OmniFile Required a Different Map

When I launched OmniFile, my Rust-based local search app, the experience was the polar opposite. Despite being built with a modern stack (Tauri), it didn't fit the "AI Directory" mold. The bots ignored it. After a month, I had only 20 backlinks.

But here’s the thing: OmniFile handles your local files.

For a tool like this, a random link from an automated aggregator is worthless. Users won't download a file-system utility based on a bot's recommendation. They need to know it’s safe.

That’s why I pivoted my strategy from "Volume" to "Authority." I focused on getting listed on Softpedia.

Section 3: The Value of the "100% Clean" Badge

Softpedia is old school—and I mean that in the best way possible. They don’t just scrape your site; they test your software.

Getting the "100% Clean" Award means their team verified that OmniFile is free of malware, adware, and viruses. In an era where "Local-First" and "Privacy" are becoming mainstream, this badge is more than a marketing asset—it’s a security certification for my users.

It reminds us that while AI bots can give you visibility, only human-curated platforms can give you credibility.

Section 4: Tips for Navigating Security Reviews (How to get listed)

If you are building a desktop app (Tauri, Electron, or native) and want to earn this kind of trust, here are a few tips from my experience:

Code Signing is Non-Negotiable: Ensure your binaries are signed. It’s the first thing professional reviewers and OS filters (like SmartScreen) look for.
Clear Privacy Policy: Especially for local-first apps, explicitly state that no data leaves the machine.
Be Patient with Manual Reviews: Unlike AI directories that list you in seconds, sites like Softpedia or MajorGeeks take time. The wait is the proof of the quality of the review.

Conclusion & CTA

Building trust in 2026 feels like a constant battle against automated noise. While the 400+ bot links for my AI project were a fun experiment, the "100% Clean" badge for OmniFile is what helps me sleep at night.

I’m curious to hear from other indie hackers: How are you balancing the need for rapid growth with the necessity of building long-term trust? Do you still value these "old school" software directories?

If you’re looking for a privacy-first way to search your local files, I’d love for you to give OmniFile a spin.

📁 Try OmniFile: https://omnifile.app/ (or find us on Softpedia!)
⭐ GitHub: TwistTheoryGames/OmniFile-releases (If you want to see how a Tauri app is structured!)

Let’s chat in the comments!

28% of My Users Are on Mobile. My Conversion Page Was Broken for All of Them.

Kazutaka Sugiyama — Tue, 03 Mar 2026 11:28:17 +0000

I had analytics data for weeks showing mobile underperformance. I never noticed because I was looking at the wrong number.

I run RepoClip, a SaaS that generates promo videos from GitHub repos. The pipeline analyzes code with Gemini, generates images/video clips, adds narration, and renders a video. The previous articles covered image model migration and video clip integration.

This time, the problem wasn't in the AI pipeline. It was in a CSS grid.

The Aggregate Lie

My GA4 dashboard showed an overall bounce rate that looked fine. Mobile users were 28% of traffic — a meaningful chunk. But the aggregate number hid the real story.

When I broke it down by page using BigQuery, the conversion funnel on /dashboard/new (the video creation page) told a different story:

29 page views → 5 video generations

That's a 17% conversion rate on the page where users actually create videos. Desktop was converting at roughly 3x that rate.

What Was Actually Broken

I opened Chrome DevTools, switched to iPhone SE (375px), and immediately saw the problems.

Problem 1: Grids That Don't Fit

The content mode selector uses a 3-column grid. On 375px, each button was ~105px wide — barely enough for the emoji, label, and "100 credits" text. The visual style selector was worse: 4 columns on a phone screen.

// Before: cramped on mobile
<div className="grid grid-cols-3 gap-3">
  {CONTENT_MODES.map((cm) => (
    <button className="flex flex-col items-center gap-1.5 p-3 ...">
      <span className="text-xl">{cm.emoji}</span>
      <span className="text-xs font-medium">{cm.label}</span>
      <span className="text-[10px]">{cm.description}</span>
      <span className="text-[10px]">{cm.credits} credits</span>
    </button>
  ))}
</div>

The fix was one class change per grid:

- <div className="grid grid-cols-3 gap-3">
+ <div className="grid grid-cols-2 sm:grid-cols-3 gap-3">

- <div className="grid grid-cols-4 gap-3">
+ <div className="grid grid-cols-2 sm:grid-cols-4 gap-3">

Two columns on mobile, full grid on desktop. The buttons went from cramped and barely tappable to comfortable with clear labels.

Problem 2: The URL Input Squeeze

The URL input and "Validate" button sat side by side in a flex row. On a phone, the input was too narrow to show the full URL — users couldn't see what they'd typed:

- <div className="flex gap-3">
+ <div className="flex flex-col sm:flex-row gap-2 sm:gap-3">

Stacking vertically on mobile gave the input full width. Simple, obvious in hindsight.

Problem 3: The Real Friction — Typing a URL on a Phone

This was the insight that went beyond CSS.

On desktop, users copy a GitHub URL from their browser and paste it. One action. On mobile, users have to:

Switch to their browser
Navigate to GitHub
Find the repo
Copy the URL
Switch back to RepoClip
Paste it
Tap "Validate"

That's 7 steps before they even start configuring their video. No amount of responsive CSS fixes this.

The One-Tap Solution

RepoClip already has users' GitHub OAuth tokens (for private repo access). Those tokens can fetch their recent repositories:

// New GET handler in /api/github
export async function GET() {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) return NextResponse.json({ repos: [] });

  const { data: profile } = await supabase
    .from("profiles")
    .select("github_access_token")
    .eq("id", user.id)
    .single();

  const token = profile?.github_access_token;
  if (!token) return NextResponse.json({ repos: [] });

  const octokit = new Octokit({ auth: token });
  const { data: repos } = await octokit.repos.listForAuthenticatedUser({
    sort: "updated",
    per_page: 5,
  });

  return NextResponse.json({
    repos: repos.map((r) => ({
      owner: r.owner.login,
      name: r.name,
      description: r.description,
      stars: r.stargazers_count,
      language: r.language,
      isPrivate: r.private,
    })),
  });
}

On the frontend, when the URL input is empty, the user sees their 5 most recent repos as tappable chips:

{!githubUrl && !repoInfo && recentRepos.length > 0 && (
  <div>
    <p className="text-xs text-slate-500 mb-2">Recent repositories</p>
    <div className="flex flex-wrap gap-2">
      {recentRepos.map((repo) => (
        <button
          key={`${repo.owner}/${repo.name}`}
          onClick={() => {
            const url = `https://github.com/${repo.owner}/${repo.name}`;
            setGithubUrl(url);
            // Auto-validate immediately
            validateRepo(url);
          }}
          className="px-3 py-1.5 text-xs font-medium rounded-full border ..."
        >
          {repo.owner}/{repo.name}
        </button>
      ))}
    </div>
  </div>
)}

Tap a chip, auto-validate, start configuring. Three taps instead of 7 steps. On desktop, it's a nice convenience. On mobile, it eliminates the primary friction point.

The Analytics Blind Spot

While investigating the mobile conversion gap, I tried to answer a natural question: do mobile users choose portrait (9:16) video and desktop users choose landscape (16:9)?

I couldn't answer it. The video_generate_start GA4 event didn't include aspect_ratio:

// Before: missing aspect_ratio and visual_style
event("video_generate_start", {
  repo_owner: repoInfo?.owner ?? "",
  repo_name: repoInfo?.name ?? "",
  content_mode: contentMode,
  bgm_enabled: bgmEnabled ? "true" : "false",
});

I could see aspect ratio distribution in Supabase (82% landscape, 13% portrait, 5% square) and device breakdown in GA4 (83% desktop, 17% mobile for generations). But I couldn't correlate them — different systems, different user IDs.

The fix was two lines:

  event("video_generate_start", {
    repo_owner: repoInfo?.owner ?? "",
    repo_name: repoInfo?.name ?? "",
    content_mode: contentMode,
+   aspect_ratio: aspectRatio,
+   visual_style: visualStyle,
    bgm_enabled: bgmEnabled ? "true" : "false",
  });

Now I can run this BigQuery query:

SELECT
  device.category,
  (SELECT value.string_value
   FROM UNNEST(event_params)
   WHERE key = 'aspect_ratio') AS aspect_ratio,
  COUNT(*) AS generates
FROM `analytics.events_*`
WHERE event_name = 'video_generate_start'
GROUP BY device.category, aspect_ratio
ORDER BY generates DESC

The data won't be available until the next deployment collects new events, but the hypothesis is testable now. If mobile users do prefer portrait videos, I should default to 9:16 when navigator.userAgent indicates a mobile device.

The Landing Page Badge Overflow

One more mobile issue, unrelated to conversions but visible to every visitor: the third-party badges (TAAFT, BetaList, Futurepedia) on the landing page had hard-coded pixel widths.

// Before: fixed widths overflow on 375px screens
<div className="flex justify-center items-center gap-6 py-8">
  <img width="300" src="..." />
  <img width="156" height="54" style={{ width: 156, height: 54 }} />
  <img width={250} height={54} style={{ width: 250, height: 54 }} />
</div>

300 + 156 + 250 + gaps = 730px minimum. iPhone SE is 375px. The badges just overflowed.

// After: responsive widths with flex-wrap
<div className="flex flex-wrap justify-center items-center gap-4 sm:gap-6 px-4 py-8">
  <img src="..." className="w-48 sm:w-[300px]" />
  <img src="..." className="h-10 sm:h-[54px] w-auto" />
  <img src="..." className="h-10 sm:h-[54px] w-auto" />
</div>

flex-wrap lets badges flow to a second row on small screens. Responsive height classes scale them down proportionally.

What I Learned

1. Aggregate metrics hide page-level problems. "Mobile bounce rate" told me nothing. Breaking conversion down by page and device category revealed that one specific page was broken. If you have GA4 + BigQuery, query by page path — not just by device.

2. The biggest mobile friction isn't layout — it's input. Responsive grids are table stakes. The real question is: what actions require typing on mobile that could be replaced with tapping? For RepoClip, the answer was URL input. For your app, it might be search, filters, or form fields.

3. Track what you'll want to correlate later. I added content_mode to the GA4 event at launch but forgot aspect_ratio and visual_style. When I needed to correlate device type with aspect ratio choice, the data wasn't there. Think about the questions you'll ask in 3 months and instrument for them now.

4. Fixed pixel widths are mobile time bombs. Every width="300" and style={{ width: 250 }} is a mobile overflow waiting to happen. Use responsive classes from the start, even if your primary audience is desktop.

The Checklist

If you're building a SaaS and haven't checked your mobile conversion funnel recently, here's my quick audit list:

[ ] Query GA4 by page path + device category, not just aggregate
[ ] Open every conversion-critical page on a 375px viewport
[ ] Check every grid: does it still make sense at half the width?
[ ] Find every input that requires typing — can it be replaced with selection?
[ ] Search your codebase for hard-coded width= attributes
[ ] Verify your analytics events include all dimensions you'll want to slice by

Try It

The mobile improvements are live now: repoclip.io

If you have a GitHub repo, try the one-tap flow: log in, go to "Create New Video," and your recent repos should appear as chips. On a phone, it's noticeably faster than typing a URL.

Questions for the community:

What's the worst mobile UX bug you've found hiding in aggregate analytics?
How do you decide when to optimize for mobile vs. accepting that some workflows are desktop-first?

Drop a comment or find me on GitHub.

Four CSS changes, one API endpoint, and two GA4 parameters. Sometimes the highest-impact work isn't in the AI pipeline — it's in the form that feeds it.

I Added AI Video Clips to My SaaS and It Broke Everything — 5 Times

Kazutaka Sugiyama — Sun, 01 Mar 2026 15:37:10 +0000

Static images were working fine. Users were happy. Revenue was growing. So naturally, I decided to break everything.

I run RepoClip, a SaaS that turns GitHub repos into promotional videos. The pipeline analyzes code with Gemini, generates scene images, adds AI narration, and renders the final video with Remotion. The previous article covered switching the image model from FLUX.2 to Nano Banana 2 — a 6.7x cost increase that turned out to be noise.

This time, I went bigger. Instead of still images, I wanted each scene to be an AI-generated video clip. Five 5-second clips stitched together with narration. The kind of output that makes people say "wait, AI made this?"

The model: Kling 3.0 Pro via Fal.ai's queue API.

The result: it works — beautifully. But getting there nearly broke me.

Why Video Clips?

The still-image pipeline was solid. Nano Banana 2 produces gorgeous frames. But promo videos with static images and Ken Burns zoom feel like... slideshows. Because they are.

AI video generation has matured enough that 5-second clips look cinematic. Camera pans, particle effects, dynamic lighting — things you'd need After Effects for a year ago. For a tool that generates promotional content, this changes the value proposition entirely.

The plan was simple: add a "Video Short" content mode alongside the existing image mode. Five scenes, five 5-second AI video clips, same narration pipeline, same Remotion renderer.

Simple plan. Five production incidents.

The Cost Math

Before writing code, I ran the numbers. Kling 3.0 Pro costs $0.224 per second on Fal.ai. Each clip is 5 seconds.

	Image Mode	Video Short
Scenes	6	5
Visual cost	$0.08 × 6 = $0.48	$1.12 × 5 = $5.60
TTS cost	~$0.10	~$0.08
Render cost	~$0.05	~$0.05
Total per video	~$0.63	~$5.73
RepoClip credits	10	100

At $0.01/credit (Starter plan pricing), video mode generates $1.00 revenue per video against $5.73 cost. That's underwater.

But this is a premium feature. At Pro plan pricing ($0.004/credit × 100 = $0.40), it's even more underwater. The economics only work at scale with Agency plan users, or as a differentiator that drives subscription upgrades.

I decided to launch it anyway. The quality gap between a slideshow and cinematic AI clips is the kind of thing that converts free users to paid. Sometimes the feature pays for itself indirectly.

Incident #1: The 5-Minute Wall

First deploy. First test. Video generation starts, reaches "Generating Assets"... and stays there for 15 minutes. Then the whole pipeline dies silently.

The culprit: Vercel's serverless function timeout.

My existing image pipeline used fal.subscribe() — a convenience method that submits a job and long-polls until completion:

// This worked for images (7-30 seconds)
const result = await fal.subscribe("fal-ai/nano-banana-2", {
  input: { prompt, aspect_ratio: "16:9" },
});

fal.subscribe blocks the HTTP connection, waiting for the result. For images that generate in 30 seconds, this is fine. For video clips that take 18 minutes, it's a death sentence.

Vercel Pro plan has a hard limit: 300 seconds (5 minutes) per function invocation. The function gets killed mid-poll. No error. No cleanup. Just gone.

The Architecture Fix: Submit-Sleep-Collect

The solution was to stop waiting. Instead of long-polling inside a single function call, I split the work into three phases:

Submit all jobs (fast, <10s)
    ↓
step.sleep("15m")  ← Inngest manages this, zero Vercel resources
    ↓
Collect results (fast HTTP GETs)

This is where Inngest saved the architecture. Inngest step functions let you step.sleep() between operations. During the sleep, no Vercel function is running. No compute. No timeout risk. Inngest wakes your function up after the sleep and runs the next step as a fresh HTTP request.

// Phase 1: Submit all video jobs to fal.ai queue (<10 seconds)
const videoJobs = await step.run("submit-video-jobs", async () => {
  return await submitVideoJobs(videoConfig.scenes, aspectRatio);
});

// Phase 2: Sleep while fal.ai processes (no Vercel resources used)
await step.sleep("wait-for-videos", "15m");

// Phase 3: Collect results (fast HTTP GETs)
for (let attempt = 0; attempt < 10; attempt++) {
  const { completed, pending } = await step.run(
    `collect-video-results-${attempt}`,
    async () => collectVideoResults(remainingJobs)
  );
  // ... handle completed/pending
  if (pending.length === 0) break;
  await step.sleep(`wait-${attempt}`, "2m");
}

The key insight: each step.run() is a separate Vercel function invocation. As long as each individual step completes within 5 minutes, the overall pipeline can run for hours.

Incident #2: The 18-Minute Surprise

After implementing the submit-sleep-collect pattern, I deployed and tested. The pipeline submitted 5 jobs, slept for 3 minutes, then checked results.

All 5 clips: still processing.

I waited. Checked again at 5 minutes. Still processing. 8 minutes. Still processing.

I started a timer and polled manually with curl:

# Submit a test job
curl -X POST "https://queue.fal.run/fal-ai/kling-video/v2/master/text-to-video" \
  -H "Authorization: Key $FAL_KEY" \
  -d '{"prompt":"Futuristic data visualization dashboard","duration":"5"}'

# Poll every 2 minutes...
# IN_PROGRESS... IN_PROGRESS... IN_PROGRESS...
# 18 minutes later: COMPLETED

Kling 3.0 Pro takes ~18 minutes per clip. The documentation says 2-5 minutes. The reality is 3-4x slower.

The fix: increase the initial sleep from 3 minutes to 15 minutes, set max collect attempts to 10 with 2-minute intervals. Total maximum wait: ~35 minutes. Not elegant, but reliable.

Incident #3: Same Bug, Different Step

Video clips finally generate. Five beautiful 5-second clips. Pipeline moves to "Rendering Video" — Remotion Lambda stitches the clips with narration into a final MP4.

Status stays at "Rendering Video" for 30 minutes. Then silence.

Same root cause. The pollRenderProgress() function was a polling loop inside a single step.run():

// This loop runs for up to 10 minutes — kills the Vercel function
for (let i = 0; i < 200; i++) {
  const progress = await getRenderProgress(renderId, bucketName);
  if (progress.done) return progress.outputFile;
  await new Promise(r => setTimeout(r, 3000)); // 3s × 200 = 10 min
}

Same fix. Split into check-sleep-retry:

await step.sleep("wait-for-render", "5m");

for (let attempt = 0; attempt < 10; attempt++) {
  const result = await step.run(`check-render-${attempt}`, async () => {
    return await checkRenderProgress(renderId, bucketName);
  });
  if (result) { videoUrl = result; break; }
  await step.sleep(`wait-render-${attempt}`, "1m");
}

The pattern is universal: never long-poll inside a serverless function. If the operation takes more than a minute, use an external orchestrator.

Incident #4: The Invisible Bundle

Three deploys later. Video clips generate. Rendering starts. Remotion Lambda times out after 15 minutes with no output.

This time the code was fine. The problem was deployment.

Remotion Lambda runs a pre-bundled React application on AWS. I'd added <OffthreadVideo> to the scene component to render video clips:

{scene.videoUrl ? (
  <OffthreadVideo
    src={scene.videoUrl}
    style={{ width: "100%", height: "100%", objectFit: "cover" }}
  />
) : (
  <Img src={scene.imageUrl} style={{...}} />
)}

But I'd only deployed the Vercel app. The Remotion Lambda bundle on S3 was still the old version — no OffthreadVideo, no video clip support. Lambda was trying to render scenes with undefined video components and silently failing.

The fix:

# Redeploy the Remotion bundle to S3
npx remotion lambda sites create \
  --region us-east-1 \
  --site-name repoclip \
  remotion/src/Root.tsx

# Also upgrade Lambda resources for video decoding
npx remotion lambda functions deploy \
  --memory 3008 \
  --timeout 900 \
  --disk 4096

Two deployment targets. Two separate deploy processes. I now have a checklist.

Incident #5: The BGM Credit Trap

Pipeline works end-to-end. Video clips render. I enable background music (ElevenLabs Music API) and run a test.

[bgm_generation] ElevenLabs Music API error (401): insufficient_credits

The BGM for a 35-second video consumed ~4,000 ElevenLabs credits — nearly all of my monthly quota on the Creator plan. One BGM generation cost more than 400 TTS narrations.

Two fixes:

1. Graceful fallback — BGM failure no longer kills the pipeline:

const bgm = bgmEnabled
  ? await step.run("generate-bgm", async () => {
      try {
        return await withRetry("bgm_generation", () =>
          generateBGM(projectId, videoConfig, bgmDuration)
        );
      } catch (error) {
        console.warn("BGM failed, continuing without:", error);
        return null; // Video generates fine without BGM
      }
    })
  : null;

2. Price adjustment — BGM addon went from 5 credits to 20 credits. The original 5-credit price was set before I knew the actual API cost. Always validate pricing against real usage data.

The Pipeline Today

User submits GitHub URL
  ↓
[Inngest] Fetch code → Gemini analysis → Generate video config
  ↓
[Inngest] Submit 5 video jobs to fal.ai queue (< 10 seconds)
  ↓
[Inngest] step.sleep("15m") — zero compute cost
  ↓
[Inngest] Collect completed clips (retry up to 10× at 2-min intervals)
  ↓
[Inngest] Generate TTS narrations in parallel (< 30 seconds)
  ↓
[Inngest] Trigger Remotion Lambda render
  ↓
[Inngest] step.sleep("5m") — zero compute cost
  ↓
[Inngest] Check render progress (retry up to 10× at 1-min intervals)
  ↓
Final MP4 with AI video clips, narration, and BGM

Total wall-clock time: ~30 minutes. Total Vercel compute: under 2 minutes.

What I Learned

1. Serverless timeouts are the #1 constraint for AI pipelines. Not cost. Not quality. Not rate limits. The hard timeout wall shapes your entire architecture. Design for it from day one, not after your fifth production incident.

2. The submit-sleep-collect pattern is essential. If you're calling any AI API that takes more than 60 seconds, you need an orchestrator that can sleep without consuming resources. Inngest, Temporal, AWS Step Functions — pick one.

3. "2-5 minutes" in AI API docs means "maybe 18 minutes." Always measure actual latency with your real workload before setting timeouts. Published benchmarks are best-case scenarios.

4. Two deployment targets means two deploy checklists. When your rendering engine runs on separate infrastructure (Lambda, GPU workers, etc.), code changes require deploying to both. Automate this or you'll forget.

5. Make expensive features fail gracefully. BGM, video clips, 4K rendering — anything with high API costs should degrade, not crash. Users would rather have a video without music than no video at all.

The Numbers After Launch

	Image Mode	Video Short
Generation time	~8 min	~30 min
API cost per video	~$0.63	~$5.73
RepoClip price	10 credits	100 credits
Quality	Slideshow with Ken Burns	Cinematic AI clips
Production incidents	0	5

Was it worth five incidents? Look at the output and judge for yourself: repoclip.io/gallery

The Stack

Framework: Next.js 16 (App Router) + TypeScript
Orchestration: Inngest (the hero of this story)
Code Analysis: Gemini 2.5 Flash
Image Generation: Nano Banana 2 via Fal.ai
Video Generation: Kling 3.0 Pro via Fal.ai
Narration: OpenAI TTS
Background Music: ElevenLabs Music API
Video Rendering: Remotion Lambda (AWS)
Database/Auth/Storage: Supabase
Deployment: Vercel

Try It

Want to see what Kling 3.0 Pro produces in a real pipeline? Try it on your own repo: repoclip.io

Select "Video Short" mode when creating a video. The free tier gives you 2 videos/month. Fair warning: it takes ~30 minutes, but the result is worth the wait.

Questions for the community:

Have you hit serverless timeout walls with AI APIs? How did you solve it?
What orchestration tool do you use for long-running AI pipelines?

Drop a comment or find me on GitHub.

Five production incidents, three architectural rewrites, and one pricing mistake. Sometimes the best way to learn a platform's limits is to exceed them — repeatedly.

I Switched My AI Image Model and the Cost Went Up 6.7x — Here's Why I Did It Anyway

Kazutaka Sugiyama — Fri, 27 Feb 2026 15:33:53 +0000

You know that feeling when you find a better tool, but the pricing page makes you close the tab?

I run RepoClip, a SaaS that generates promo videos from GitHub repos using AI. The pipeline analyzes source code with Gemini, generates scene images, adds narration, and renders a video — all automatically. Images are at the center of the output quality. Every video has 6 scene images, and they're what users see first.

I'd been using FLUX.2 [dev] via Fal.ai for image generation since launch. It worked. Then I saw that Nano Banana 2 — Google's new image model — had landed on Fal.ai. I decided to test it with the exact same prompt.

The results were not close.

Same Prompt, Different Universe

I built a comparison script that runs the same prompt through both models across 4 visual styles (Tech, Realistic, Minimal, Vibrant). Here's the prompt:

"A digital dashboard showing interconnected data nodes and flowing information streams, representing an intelligent automation platform that connects multiple services and workflows seamlessly"

Tech Style

FLUX.2	Nano Banana 2

FLUX.2 gives you a flat infographic with a UI overlay. Nano Banana 2 produces a cinematic, three-dimensional data flow with depth and lighting that looks like concept art.

Realistic Style

FLUX.2	Nano Banana 2

FLUX.2 renders a network graph that looks like a screenshot from a monitoring tool. Nano Banana 2 creates a photorealistic control room scene — you can almost feel the screen glow.

Vibrant Style

FLUX.2	Nano Banana 2

This is where the gap is widest. FLUX.2 gives a cartoon explosion of color. Nano Banana 2 produces a bold, structured composition with neon circuit aesthetics that actually looks intentional.

The difference wasn't subtle. Every style, every prompt — Nano Banana 2 was producing images that looked like they belonged in a final product, not a prototype.

But then I checked the pricing.

The 6.7x Problem

	FLUX.2 [dev]	Nano Banana 2
Cost per image	~$0.012	~$0.08
Generation time	~7.7s	~31.3s

That's a 6.7x increase in per-image cost and 4x slower generation. For a bootstrapped SaaS, these numbers don't inspire confidence.

My gut said "too expensive." But I'd learned from past experience that gut feelings about costs are usually wrong — you need actual numbers.

Running the Simulation

Instead of staring at a spreadsheet, I asked Claude Code to run a scenario:

Assumptions:

10 Starter users ($29/mo each) generating 50 videos total
3 Pro users ($79/mo each) generating 50 videos total
6 images per video
Only revenue: subscription fees. Only cost: image generation API.

                    FLUX.2          Nano Banana 2
─────────────────────────────────────────────────
Images generated    600             600
Image cost          $7.20           $48.00
Monthly revenue     $527.00         $527.00
Profit              $519.80         $479.00
Margin              98.6%           90.9%

The difference was $40.80/month. That's it.

Even in this conservative scenario — just 13 paying users, no free tier buffer, ignoring all other operational costs — the profit impact was under 8 percentage points. With real-world numbers where hosting, AI analysis, and TTS costs dominate the bill, image generation was a rounding error either way.

The quality gap was obvious. The cost gap was negligible. Decision made.

Problem #1: File Size Explosion

The first thing I noticed after switching: Nano Banana 2's PNG outputs were massive.

Format	File Size (same prompt)
FLUX.2 PNG	978 KB
Nano Banana 2 PNG	2,043 KB
Nano Banana 2 JPEG	401 KB

Nano Banana 2 PNGs were 2x larger than FLUX.2. For a video pipeline that downloads 6 images per generation and passes them to a Lambda renderer, this matters — both for speed and storage costs.

The fix was one line:

const result = await fal.subscribe("fal-ai/nano-banana-2", {
  input: {
    prompt: enhancedPrompt,
    aspect_ratio: aspectRatio,
    resolution: "1K",
    output_format: "jpeg",  // <-- this
    num_images: 1,
  },
});

Since these images are frames in a video (which itself uses lossy H.264 compression), lossless PNG was overkill from the start. JPEG at default quality cut the size by 80% with no visible difference in the final rendered video.

Problem #2: The 4x Slower Generation

Nano Banana 2 takes ~31 seconds per image versus FLUX.2's ~8 seconds. For 6 scenes, that's 186 seconds sequential — over 3 minutes just on images.

But I was already generating all scene images in parallel:

const images = await Promise.all(
  scenes.map(scene => generateImage(scene.imagePrompt, aspectRatio, visualStyle))
);

With Promise.all, the wall-clock time is the slowest single image, not the sum. In practice, that's ~36 seconds — about 28 seconds more than before. Against a pipeline timeout of 15 minutes, this was a non-issue.

If you're calling AI APIs sequentially and wondering why things are slow, this is your sign to parallelize.

Problem #3: Brand Logo Hallucination

This one surprised me. Nano Banana 2 is significantly better at rendering recognizable imagery — and that's not always a good thing.

When the scene prompt contained words like "GitHub" or "Python," FLUX.2 would generate abstract tech art. Nano Banana 2 would render the actual Octocat logo or a realistic Python logo. For a product that generates promotional videos, having trademarked imagery appear in user content is a liability.

The fix was adding explicit exclusion instructions to every prompt:

const enhancedPrompt = `${prompt}. ${stylePrompt}. No text, no UI elements, no screenshots, no logos, no brand imagery, no mascots.`;

The last three exclusions (no logos, no brand imagery, no mascots) were added specifically for Nano Banana 2. FLUX.2 never needed them because it wasn't capable enough to reproduce them.

The Migration Diff

The actual code change was small. Here's the core of fal.ts before and after:

- const result = await fal.subscribe("fal-ai/flux-2", {
+ const result = await fal.subscribe("fal-ai/nano-banana-2", {
    input: {
      prompt: enhancedPrompt,
-     image_size: "landscape_16_9",
-     num_inference_steps: 28,
+     aspect_ratio: aspectRatio,
+     resolution: "1K",
+     output_format: "jpeg",
      num_images: 1,
    },
  });

Different model, different API shape, but the wrapper function signature stayed the same. Downstream code didn't change at all.

What I Learned

1. Always simulate before you panic. A 6.7x per-unit cost increase sounds terrifying in isolation. In the context of actual revenue and usage patterns, it was noise. Run the numbers before making decisions based on sticker shock.

2. Lossy formats are fine for intermediate assets. If your images are being consumed by a video encoder, compressed for web display, or otherwise transformed downstream, PNG is a waste of bandwidth. Match the format to the use case.

3. Better models bring new problems. FLUX.2 couldn't render brand logos, so I never had to worry about it. Nano Banana 2 can, so now I need explicit exclusion prompts. Capability upgrades aren't just free wins — they shift the problem space.

4. Parallelization absorbs latency. A 4x slower model barely matters when you're already running requests concurrently. Design for parallelism from the start and model speed becomes a secondary concern.

The Stack

Framework: Next.js (App Router) + TypeScript
Orchestration: Inngest
Code Analysis: Gemini 2.5 Flash
Image Generation: Nano Banana 2 via Fal.ai
Narration: OpenAI TTS
Video Rendering: Remotion Lambda
Database/Auth/Storage: Supabase
Deployment: Vercel

Try It

If you want to see what Nano Banana 2 produces in a real pipeline, try it on your own repo: repoclip.io

The free tier gives you 2 videos/month. Paste a GitHub URL and you'll have a narrated demo video in a few minutes.

I'd love to hear from the community:

Have you switched AI models in production and been surprised by the cost impact?
What's your approach to evaluating model upgrades — vibes, benchmarks, or simulations?

Drop a comment or find me on GitHub.

The comparison images in this post were generated with the exact same prompt, same visual style settings, same pipeline. The only variable was the model. Sometimes the upgrade really is worth it.

Built a desktop file search app with Tauri + Rust instead of Electron. This post covers integrating 7 cloud OAuth providers and the surprising workarounds I needed. Feedback welcome!

Kazutaka Sugiyama — Thu, 26 Feb 2026 06:12:23 +0000

Kazutaka Sugiyama

Feb 26

Building a Cross-Platform File Search App With Tauri — Not Electron

#showdev #rust #tauri #opensource

Comments

6 min read

Just published my first post — a deep dive into orchestrating 6+ AI services in a single serverless pipeline. Would love feedback from the community!

Kazutaka Sugiyama — Thu, 26 Feb 2026 06:09:02 +0000

Kazutaka Sugiyama

Feb 26

How I Built an AI Pipeline That Turns GitHub Repos into Demo Videos

#showdev #ai #nextjs #remotion

Comments

5 min read

Building a Cross-Platform File Search App With Tauri — Not Electron

Kazutaka Sugiyama — Thu, 26 Feb 2026 05:42:53 +0000

Every knowledge worker I know has the same problem: files scattered across Google Drive, Dropbox, SharePoint, Slack, Notion, GitHub, and their local machine. When you need to find something, you end up opening 4 different search bars.

I built OmniFile to fix that — a single search bar that finds files across all your sources instantly. Desktop app, privacy-first, everything stays on your machine.

Here's what I learned building it with Tauri + Rust instead of Electron, and why integrating 7 OAuth providers in a desktop app was harder than I expected.

Why Tauri Over Electron

The decision was simple: OmniFile needs to launch instantly (it's triggered by a global shortcut) and stay lightweight in the background. Electron ships a full Chromium browser. Tauri uses the OS's native webview and a Rust backend.

The result:

~8MB installer vs Electron's ~80MB+
~30MB RAM at idle vs Electron's ~150MB+
Rust backend for CPU-intensive indexing and file I/O

The tradeoff is that you write your backend in Rust instead of JavaScript. For file search, that's actually a benefit — Rust's performance for walking directories and parsing file formats is hard to beat.

Full-Text Search with Tantivy

Tantivy is Rust's answer to Lucene. I use it as the local search engine that indexes everything into a single queryable index.

The Schema Design

schema_builder.add_text_field("title", TEXT | STORED);      // Tokenized + returned
schema_builder.add_text_field("path", STRING | STORED);      // Exact match
schema_builder.add_text_field("content", TEXT);              // Searchable but NOT stored
schema_builder.add_text_field("source", STRING | STORED);    // "local", "gdrive", etc.
schema_builder.add_i64_field("modified_at", INDEXED | STORED);

The key decision: content is indexed but not stored. For a desktop search app, this saves significant disk space — the content is already on disk, so we re-extract it when needed for display. This keeps the index small while enabling full-text search.

Multi-Source Indexing

Each cloud provider indexes into the same Tantivy index but with a different source tag. When re-indexing Google Drive, I delete all documents where source = "gdrive" and re-add them — without touching Dropbox or local results:

let source_term = Term::from_field_text(source_field, "gdrive");
writer.delete_term(source_term);  // Clear only gdrive docs
// ... re-index gdrive files
writer.commit()?;

This means each provider can index independently without affecting others.

File Format Extraction

OmniFile doesn't just search filenames — it extracts and indexes content from DOCX, XLSX, and text files. DOCX files are ZIP archives containing XML, so extraction means:

Open the ZIP
Find word/document.xml
Parse XML, extract text from <w:t> tags

XLSX is trickier because Excel uses a shared strings table — cell values are stored as indices into a deduplicated string array. The extractor resolves these references at index time.

For text files, I try UTF-8 first, then fall back to Shift-JIS (common for Japanese files), then lossy UTF-8 as a last resort.

The OAuth Problem: 7 Providers, 7 Headaches

Desktop apps can't receive OAuth callbacks the way web apps do. There's no public URL to redirect to. My solution: spin up a temporary local HTTP server for each OAuth flow.

Each provider gets its own port:

Google Drive  → localhost:14200
Dropbox       → localhost:14201
Box           → localhost:14202
SharePoint    → localhost:14203
Slack         → localhost:14204 (HTTPS!)
Notion        → localhost:14205
GitHub        → localhost:14206

The flow: open the browser → user logs in → provider redirects to localhost:PORT/callback?code=XXX → local server catches it → exchange code for token.

All providers use PKCE (Proof Key for Code Exchange) to prevent authorization code interception, which matters more for desktop apps since the redirect happens on localhost.

The Slack HTTPS Problem

Six of the seven providers accept http://localhost redirects. Slack doesn't. It requires HTTPS, even for localhost.

My solution: generate a self-signed TLS certificate on-the-fly using rcgen, then serve the callback over HTTPS:

let subject_alt_names = vec!["localhost".to_string(), "127.0.0.1".to_string()];
let CertifiedKey { cert, key_pair } = generate_simple_self_signed(subject_alt_names)?;

let config = rustls::ServerConfig::builder()
    .with_no_client_auth()
    .with_single_cert(vec![cert_der], key_der)?;

let tls_acceptor = TlsAcceptor::from(Arc::new(config));

When the browser hits https://localhost:14204/callback, it shows a certificate warning. The user clicks through, and the callback completes. Not the most elegant UX, but it works — and the TLS handshake failure from the initial browser check is handled gracefully with a retry loop:

let mut tls_stream = match tls_acceptor.accept(stream).await {
    Ok(stream) => stream,
    Err(_) => continue,  // Browser cert warning — wait for retry
};

A critical detail: the TCP listener must be bound before opening the browser to prevent a race condition where the redirect arrives before the server is ready.

GitHub: Why the Search API Wasn't Enough

GitHub's Search API seems like the obvious choice for file search. But it has a frustrating limitation: not all files are indexed. Repositories need to meet certain criteria, and even then the index can be stale.

Instead, I use the Trees API — fetch the entire file tree for each repository in a single recursive call:

GET /repos/{owner}/{repo}/git/trees/{branch}?recursive=1

This returns every file path in the repository. I cache the results for 5 minutes and do case-insensitive matching client-side. To avoid hammering GitHub's rate limits, tree fetches are batched 10 repos at a time using futures::future::join_all.

The search results are ranked by relevance:

Exact filename match (highest)
Partial filename match
Shorter path depth (higher-level files = more relevant)

If the cache refresh fails (network issues, rate limiting), the system gracefully degrades to the stale cache instead of returning an error. For a search feature, showing slightly outdated results is better than showing nothing.

Global Shortcut with Debouncing

OmniFile is designed to pop up when you hit a keyboard shortcut (like Spotlight or Alfred). Tauri's global_shortcut plugin handles this, but I needed a few extras:

Debouncing: Without it, holding the shortcut key triggers multiple show/hide cycles. A 300ms threshold prevents this.

Rollback on failure: If registering a new shortcut fails (e.g., it's already claimed by another app), the system automatically re-registers the old shortcut. The user never loses their ability to summon the app.

Three-level persistence: The shortcut is stored in memory (fast access), persisted to a settings file (survives restart), and reflected in the tray menu label (user visibility).

iCloud: The Clever Non-Integration

Apple doesn't provide a public API for iCloud Drive search. My solution was embarrassingly simple: detect the iCloud Drive folder at ~/Library/Mobile Documents/com~apple~CloudDocs and treat it as a local directory.

The file watcher picks up changes, Tantivy indexes the contents, and users get iCloud search without any OAuth flow or API integration. It just works — as long as iCloud Drive syncs files to disk (which it does by default on macOS).

Things I'd Do Differently

1. Unify the OAuth config structs. I have 7 separate *OAuthConfig structs that are 90% identical. A trait-based approach would reduce duplication.

2. Use Tantivy's query parser for scoring. My current search iterates all documents with substring matching. It works for desktop-scale data, but Tantivy's built-in BM25 scoring would be more sophisticated and faster for large indexes.

3. Plan for token refresh from day one. Some providers (Slack, Notion, GitHub) give non-expiring tokens. Others (Google, Microsoft) require refresh token flows. This divergence created special cases throughout the codebase.

The Stack

Framework: Tauri 2 (Rust backend + native webview)
Frontend: React 19 + TypeScript + Tailwind CSS
Search Engine: Tantivy (Rust, full-text search)
OAuth: oauth2 crate + PKCE
TLS: rustls + rcgen (for Slack)
File Watching: notify crate with debouncer
File Parsing: quick-xml (DOCX/XLSX), encoding_rs (Shift-JIS)

Try It

If you're tired of searching 5 different places for one file: omnifile.app

Free tier covers local search. Pro ($129 lifetime) unlocks all cloud integrations.

I'd love to hear from the dev.to community:

Which cloud integrations matter most to you?
Would you use a CLI version alongside the GUI?
Any clever search UX ideas?

Drop a comment or find me on GitHub.

Built as a solo project with Tauri + Rust. The entire app idles at ~30MB RAM. Every search query stays on your machine — no server, no telemetry.

How I Built an AI Pipeline That Turns GitHub Repos into Demo Videos

Kazutaka Sugiyama — Thu, 26 Feb 2026 05:10:59 +0000

You know that moment when you finish building something cool, push it to GitHub, and then realize... nobody's going to read your README?

I've been there too many times. So I built RepoClip — a tool that takes a GitHub URL, analyzes the source code with AI, and generates a 60-second promo video with narration, images, and music. Automatically.

In this post, I'll walk through the architecture: how I orchestrate 6+ AI services in a single pipeline, the technical decisions that actually mattered, and the mistakes I made along the way.

The Pipeline at a Glance

GitHub URL → Code Fetch → Gemini Analysis → Parallel Asset Gen → Remotion Render → MP4

Simple on paper. In practice, it's 13 orchestrated steps, each of which can fail in creative ways.

Why Inngest for Orchestration

The first decision was how to manage a pipeline where each step depends on the last, calls to external APIs can take 30+ seconds, and failures need targeted retries.

I went with Inngest over a simple queue for one reason: step-level isolation. Each step.run() is independently retried and logged.

export const generateVideo = inngest.createFunction(
  { id: "generate-video", retries: 1 },
  { event: "video/generate.requested" },
  async ({ event, step }) => {
    const code = await step.run("fetch-github-code", async () => {
      return await fetchGitHubCode(githubUrl, accessToken);
    });

    const videoConfig = await step.run("analyze-with-gemini", async () => {
      return await analyzeWithGemini(code, repoUrl, commitHash, customPrompt);
    });

    const assets = await step.run("generate-assets", async () => {
      const [images, narrations] = await Promise.all([
        generateImages(videoConfig.scenes, aspectRatio, visualStyle),
        generateNarrations(videoConfig.scenes, projectId, videoConfig.voice),
      ]);
      return { images, narrations };
    });

    // ... render step
  }
);

If Gemini fails, it retries that step — not the whole pipeline. If rendering fails after assets are already generated, those assets are preserved.

This also enabled a selective refund strategy: credits are only refunded if the render step fails, because at that point we've already consumed API calls.

Teaching Gemini to Think Like a Video Producer

The hardest part wasn't calling the API — it was prompt engineering for consistent, structured output.

Gemini 2.5 Flash analyzes the repository code and returns a VideoConfig JSON: title, scenes, narration scripts, image prompts, voice selection, and styling. Here's what I learned:

The Sandwich Technique

Custom user instructions (like "make it sound enthusiastic" or "use anime style visuals") get placed both before and after the code content in the prompt. This "sandwich" structure significantly improved instruction adherence — placing them only at the beginning caused Gemini to "forget" them after processing thousands of lines of code.

Language Detection ≠ Prompt Language

A Japanese developer writing a custom prompt in Japanese might still have an English-language repository. The system detects the repository's language from README content, code comments, and UI strings — not from the custom prompt language. This was a subtle but important distinction.

Image Prompts Stay English

Regardless of the detected language, all imagePrompt fields are generated in English. Why? Flux.2 (our image model) performs significantly better with English prompts. The narration and titles are in the detected language, but image generation always goes through English.

Parallel Asset Generation

Once Gemini returns the video structure, we generate images and narrations in parallel for all scenes:

const [images, narrations] = await Promise.all([
  // All 5-8 images generated simultaneously via Fal.ai
  Promise.all(scenes.map(scene => generateImage(scene.imagePrompt))),
  // All narrations generated simultaneously via OpenAI TTS
  Promise.all(scenes.map(scene => generateNarration(scene.narration))),
]);

This cuts asset generation time from ~60s (sequential) to ~12s. The tradeoff is higher burst API usage, but for a credit-based SaaS the speed improvement is worth it.

Audio Duration: The Surprisingly Hard Problem

To compose the video, I need to know exactly how long each narration clip is. My approach:

Primary: Parse the actual MP3 with music-metadata to get precise duration
Fallback: Estimate from word count at 130 words/minute

The fallback exists because music-metadata occasionally fails on certain MP3 encodings. A 3-second minimum prevents empty scenes.

Remotion for Programmatic Video

Remotion lets you write video compositions as React components. Each scene is a <Sequence> with calculated frame offsets:

{scenes.map((scene, index) => {
  const startFrame = calculateStartFrame(index);
  const durationFrames = scene.audioDuration * fps;

  return (
    <Sequence key={scene.id} from={startFrame} durationInFrames={durationFrames}>
      <SceneSlide scene={scene} style={style} />
      <Audio src={scene.audioUrl} />
    </Sequence>
  );
})}

Ken Burns Effect in React

Every scene uses a slow zoom (1x → 1.08x) over its duration to keep static images visually engaging:

const scale = interpolate(frame, [0, durationInFrames], [1, 1.08], {
  extrapolateRight: "clamp",
});

Small detail, but it makes the difference between "slideshow" and "video."

Responsive Across Aspect Ratios

RepoClip supports 16:9, 9:16 (Reels/Shorts), and 1:1 (social). Font sizes and layout scale based on viewport dimensions:

const isPortrait = height > width;
const fontSize = Math.round(width * (isPortrait ? 0.056 : 0.033));

This approach avoids maintaining separate templates per ratio.

Error Handling: The 80% of the Work

Every external API fails differently. Here's my retry strategy:

Stage	Retries	Backoff
GitHub Fetch	3	Exponential (1s → 2s → 4s)
Gemini Analysis	2	Fixed 5s
Image Gen (per image)	3	Fixed 2s
TTS (per scene)	2	Fixed 2s
Video Render	1	None

Why exponential for GitHub but fixed for AI services? GitHub rate limits respond well to backoff. AI services either work or they don't — waiting longer rarely helps.

Each failure is wrapped in a PipelineError that captures the stage name, a user-friendly message, and the raw error for Sentry. This lets me show users "Image generation failed, retrying..." instead of a cryptic 500.

Things I'd Do Differently

1. Cache more aggressively. I cache Gemini analysis by repo+commit hash, but I should also cache at the asset level. Re-generating images for a retry is wasteful.

2. Start with webhooks, not polling. Remotion Lambda supports webhook notifications, but I started with polling (every 3s, max 200 attempts). Polling is simpler to implement but wasteful. I'm migrating to webhooks now.

3. Don't underestimate prompt testing. I spent more time tuning Gemini prompts than writing actual application code. If you're building AI features, budget 40% of development time for prompt iteration.

The Stack

For anyone curious about the full stack:

Framework: Next.js (App Router) + TypeScript
Orchestration: Inngest
Code Analysis: Gemini 2.5 Flash
Image Generation: Flux.2 via Fal.ai
Narration: OpenAI TTS
Video Rendering: Remotion Lambda
Database/Auth/Storage: Supabase
Payments: Lemon Squeezy
Deployment: Vercel

Try It Out

If you want to see what this produces, try it on your own repo: repoclip.io

The free tier gives you 2 videos/month — enough to test it on your side projects and see how the pipeline handles your codebase.

I'd love feedback from the dev.to community, especially on:

What kind of repos produce the best/worst results?
Is 60 seconds the right length, or would shorter/longer be better?
Any feature ideas for the roadmap?

Drop a comment or find me on GitHub. Happy to discuss the architecture in more detail.

Built as a solo dev project. The entire pipeline from URL input to rendered MP4 takes about 2-3 minutes. Still feels like magic every time.