DEV Community: Nuco Z

Building a Low-Cost AI Brainrot Video Pipeline on Cloudflare

Nuco Z — Sat, 18 Jul 2026 10:13:19 +0000

Short-form video tools often look like a single button, but the product experience is really a small distributed system. A useful pipeline has to accept messy inputs, turn them into a script, generate media, report progress clearly, and keep the cost of each render predictable.

I am building BrainrotKit around that problem. The goal is not to hide the workflow behind a magic button. The goal is to make each stage understandable enough that a creator can review the result and decide whether it is worth generating the next stage.

1. Start in the browser when the browser is good enough

PDF parsing and OCR do not always need a paid server. A browser can extract text from many PDFs locally, and an OCR library can handle image-based notes without sending the original file to a backend. This reduces latency, lowers storage requirements, and gives users a simpler privacy story.

The important boundary is quality. If the browser cannot confidently extract the content, the UI should say so and ask for a clearer file. Quietly passing a bad OCR result to a language model only creates a more expensive bad result.

2. Separate planning from media generation

The text model should produce a compact, structured plan before an image or video model is called. A useful intermediate object contains:

a one-sentence hook;
the narration script;
a visual description for each beat;
the target duration;
a short caption and title.

This separation makes retries cheaper. If the image looks wrong, regenerate the image prompt instead of paying to rewrite the entire script. It also makes the system easier to debug because every output has a visible input.

3. Use a job state machine, not a spinner

Media generation is asynchronous. A request can move through "queued", "planning", "generating-image", "generating-voice", "generating-video", "ready", or "failed". The frontend should display the current stage, an estimated next action, and a useful error when something goes wrong.

A generic spinner is not enough for a ten-second wait. Users should know whether the system is still planning, waiting for a provider, or retrying a failed asset. This is also where idempotency matters: refreshing the page must not create a second paid job accidentally.

4. Track credits at the product layer

Provider prices change, so the product should not expose raw API costs as if they were permanent. I prefer a simple credit ledger: each operation reserves credits, the worker records the actual result, and unused reservations are released when a job fails before generation.

Short drafts are useful here. A five-second render is a cheaper way to validate a prompt than a fifteen-second render, and the UI can make that tradeoff explicit before the user starts.

5. Keep the user in the review loop

An AI video is not finished just because the provider returned a file. The creator still needs to check pronunciation, pacing, captions, and whether the visual actually supports the idea. The product should make preview, download, retry, and delete actions obvious.

That is the thinking behind BrainrotKit: a focused AI brainrot video workflow for turning text, notes, and PDFs into short-form concepts while keeping the intermediate steps visible. The meme layer can be playful; the engineering underneath should be boring, observable, and cost-aware.

A practical first release

For a small team, the first production version can stay intentionally narrow:

browser-side extraction for text and PDFs;
one text model for script planning;
one image provider and one video provider;
durable project and credit records;
clear loading states and failure messages;
a short export before longer generations.

This is enough to learn where users actually get stuck. The first principle is to measure the complete user journey, not just whether an individual model call succeeded. When the workflow is understandable, creators can make better decisions and the platform can improve without wasting their budget on invisible retries.

Building a Small Static Game Wiki with Next.js and Cloudflare Workers

Nuco Z — Wed, 01 Jul 2026 03:35:02 +0000

I recently put together a small static guide hub for CookieRun Classic: CRClassic.wiki. It is a simple content site, but the deployment path had a few details that are easy to miss when combining Next.js static export, Cloudflare Workers Static Assets, sitemap generation, and game-guide SEO.

This is a short technical note on what ended up mattering.

The site shape

The site is not an app dashboard. It is a focused information hub with separate pages for player intent:

codes and redeem steps
beginner route
cookie, pet, and treasure tier pages
PC setup
reroll and meta notes
a central wiki hub

That split helps because each URL answers a different question. A player searching for a redeem flow does not need to land on the same page as someone comparing Cookie upgrades.

Static export was the right fit

For this kind of site, static output keeps the deployment simple:

// next.config.mjs
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
}

export default nextConfig

The Cloudflare Workers config points directly at the generated out folder:

{
  "name": "cpclassic",
  "compatibility_date": "2026-07-01",
  "assets": {
    "directory": "./out",
    "html_handling": "auto-trailing-slash",
    "not_found_handling": "404-page"
  }
}

The small metadata details mattered

The site needed normal page metadata, but also page-specific Open Graph images so each guide has a relevant preview instead of one generic logo.

A few details I made sure to include:

canonical URLs for every route
robots.txt and sitemap.xml
max-image-preview: large for Google image previews
page-specific og:image and Twitter card images
a real favicon instead of relying only on 32px PNG files

The public sitemap is here: https://crclassic.wiki/sitemap.xml

Content pages need more than lists

For game-guide pages, a plain tier table is rarely enough. The more useful structure is:

who should use this option
when to upgrade it
when to stop investing
what mistakes to avoid
what related page to read next

That is the approach I used on the Cookie Run Classic Tier List: the page includes rankings, but the real value is upgrade logic and account-stage guidance.

Takeaway

For a small wiki, the technical stack can stay boring. The hard part is making each page answer a real search intent and making sure crawlers can clearly see the URL, canonical, sitemap entry, image preview, and internal links.

If you are building a similar static guide hub, I would start with the content architecture first, then wire the metadata and deployment around that structure.

How I Built a Fan Guide Hub for BOMBANANA!

Nuco Z — Fri, 26 Jun 2026 07:23:19 +0000

I recently put together a fan guide hub for BOMBANANA!, a new co-op bomb defusal game where three players have to coordinate under different communication limits.

The site is here:

https://bombanana.online/

Why I built it

The game is funny and chaotic, but the learning curve is mostly about communication. New players do not only need a list of rules. They need a content structure that answers practical questions:

What does each role do?
Which player should speak first?
How should the team describe modules?
What should a beginner team practice in the first session?

That shaped the site architecture more than keyword research alone.

Content structure

I split the guide into a few core sections:

Role guides: https://bombanana.online/roles
Module guides: https://bombanana.online/modules
First-session guide: https://bombanana.online/beginners/how-to-play
Team callouts: https://bombanana.online/communication/team-callouts

The goal is to make the site useful during actual gameplay, not just readable as a long article.

What I learned

For a small game guide site, the best pages are not always generic “ultimate guide” pages. The highest-value pages are often specific resources that players can use immediately:

a checklist
a module walkthrough
role-specific advice
short callout systems
screenshots that match the game state

Next steps

I am continuing to improve the guide with more screenshots, better internal links, and clearer module pages as more players search for help around the demo and full release.

If you are building a small content site for a game, my main takeaway is simple: organize by the player’s next decision, not by what looks like a clean blog category.

I Built a Task Bar Hero Item Database and Drop Finder

Nuco Z — Tue, 09 Jun 2026 09:37:49 +0000

I Built a Wiki for Task Bar Hero After Getting Tired of Looking Up Item Drops

While playing Task Bar Hero, I kept running into the same questions:

Where does this item drop?
Is it tradable?
Does it actually sell on Steam?
Is farming it worth the time?

The information existed, but it was scattered across Discord messages, Steam discussions, and spreadsheets.

So I decided to build a dedicated wiki and tool site.

The Goal

I wanted a single place where players could:

search any item
see drop locations
check Steam Market availability
compare farming routes
access item-specific tools

The project eventually became:

https://taskbarhero.nanobananas.me

Building the Item Database

The first challenge was structuring item data.

Every item page needed:

rarity
level
category
drop sources
market status
related items

Instead of writing pages manually, I generated them from a structured dataset and created static routes with Next.js.

Example item page:

/items/minor-ruby

Creating a Drop Finder

The most-used feature became the Drop Finder.

Instead of navigating through multiple pages, players can search an item directly and immediately see:

where it drops
which stages contain it
farming options

This ended up being much faster than searching through community posts.

Handling Steam Market Pages

One unexpected SEO issue involved Steam Market data.

Some items are technically tradable but have no active market listings.

Initially I generated market pages for every item.

The result:

thousands of low-value pages
thin content
poor index quality

To solve this, I split pages into two categories:

Indexed

Items with actual Steam Market data.

Noindexed

Items without meaningful market information.

Users can still access those pages, but search engines are instructed not to index them.

This significantly improved the quality of pages submitted through the sitemap.

Multilingual SEO

The site also supports multiple languages.

One challenge was that English uses the root path:

/items/minor-ruby

while other languages use locale prefixes:

/zh/items/minor-ruby

To avoid duplicate-content issues I implemented:

canonical URLs
hreflang alternates
locale-specific sitemaps

This keeps language versions connected while allowing search engines to understand the preferred URL structure.

Tech Stack

Next.js
TypeScript
Static Generation
XML Sitemap Generation
Structured Data
Canonical URLs
Hreflang Alternates

What I'd Improve Next

The current roadmap includes:

better farming calculators
richer item relationships
drop-rate analytics
player-contributed data

The project started as a small utility for myself, but it's becoming a useful resource for other players as well.

If you play Task Bar Hero, I'd love to hear what information you find hardest to locate in-game.
That meant internal links, sitemap URLs, canonical URLs, and language switching all had to follow the same rule.

Why I Built It
Game wiki pages are useful, but I wanted something more decision-focused:

“Where should I farm this?”
“Does it have a market price?”
“What drops it?”
“What item should I compare it with?”
So the site is more like a database plus a set of small tools.

What I’m Improving Next
Next things I want to improve:

better farming route recommendations
more market confidence signals
cleaner guide pages
more item comparison tools
better visual summaries for new players
If you play Task Bar Hero or like game-data tools, feedback is welcome.

Main site:

👉 https://taskbarhero.nanobananas.me/?utm_source=devto&utm_medium=post&utm_campaign=500uv_week

# I Built a Cleaner Online Grid Maker Because Most Existing Tools Feel Outdated

Nuco Z — Tue, 19 May 2026 09:11:01 +0000

I’ve been practicing drawing and reference transfers recently, and I kept running into the same issue:

Most online grid makers either:

feel outdated
have poor mobile UX
generate blurry grids
overload the UI with unnecessary controls
or make exporting painful

So I started building my own browser-based grid tool focused on simplicity and speed.

What I wanted to improve

Better visual clarity

A lot of existing tools stack too many settings at once.

I wanted a cleaner workflow where users can:

Upload an image
Adjust grid size
Export instantly

Without needing to learn the interface first.

Faster canvas rendering

One issue I noticed was that large images + dynamic grids can get laggy quickly in the browser.

I spent some time optimizing:

canvas redraw behavior
grid overlay rendering
export sharpness
responsive scaling

Especially for large portrait references.

Better use cases beyond drawing

Interestingly, people started using it for things I didn’t initially expect:

Instagram grid planning
pixel art references
crochet patterns
classroom worksheets
tattoo stencil prep

Which pushed me to make the layout system more flexible.

UX Lessons I Learned

One thing I underestimated:

Users care more about clarity than features.

Removing friction improved the experience far more than adding advanced options.

Things like:

fewer buttons
clearer spacing
instant preview updates
cleaner typography

made a bigger difference than “power features”.

Current Direction

Right now I’m experimenting with:

better mobile support
template presets
sharper exports
dark mode improvements
reusable layouts

Still a work in progress, but it’s been fun building something actually useful for creators.

For anyone curious, the current version is here:

https://gridmakeronline.com/

Would love feedback from people who work with:

drawing workflows
canvas tools
image processing
creator utilities
frontend performance

Curious what features you think these kinds of tools still lack today.

From Side Project to $500/Month: Building a YouTube Tool as a Solo Developer

Nuco Z — Mon, 09 Mar 2026 03:52:06 +0000

TL;DR: I built a YouTube subtitle downloader as a side project. After 6 months and a lot of trial and error, I'm finally hitting $500/month. Here is the raw truth about what I learned.

🎬 The Origin Story

March 2025: I was working on a video project and needed to extract subtitles from 50+ YouTube videos. Manual copying? No way.

I spent 2 hours building a quick Python script to automate it. It worked perfectly. Then I thought: "Others probably need this too."

Spoiler: That assumption was both right and wrong.

💡 The Idea Validation

What I did right:

Searched "youtube subtitle download" - 10K+ monthly searches. ✅
Checked competitors - they existed (market validation!). ✅

What I did wrong:

Didn't talk to potential users before writing code. ❌
Assumed people would pay immediately. ❌
Ignored the "Red Ocean" warning signs. ❌

Lesson 1: Competition = validation, but you need a unique angle to stand out.

🛠️ Building the MVP

Week 1-2: Basic functionality

Input URL → Download subtitle
Tech: Next.js + Python + Vercel
Cost: $0

Week 3-4: The "Feature Creep" mistake

Added 5 different export formats
Fancy animations
Dark mode

Users: 0

Lesson 2: Ship fast, iterate faster. Nobody cares about dark mode if your core value isn't hitting the mark.

📉 The Reality Check

Month 1 Results:

Traffic: 50 visitors/day (mostly bots)
Revenue: $0
Time spent: 80 hours

The problem: I built a "better mousetrap" in a market full of them. I needed to pivot.

The Turning Point: I added AI-powered summarization. Suddenly, I wasn't just a "downloader"—I was an AI productivity tool.

🚀 Monetization Strategy

What didn't work:

Paywalls: 95% bounce rate.
$9.99/mo subscription: Too expensive for casual users.

What worked:

Freemium: First download is free (no signup). This reduced friction by 80%.
Credit system: Pay-as-you-go model. Users love flexibility.

Conversion rate: 2.5% (Industry average is 2-5%)

📊 Growth Tactics

❌ What Failed:

Paid ads (burned $200, got 2 signups).
Cold emails (0% response).

✅ What Worked:

1. SEO Long-tail Keywords

"how to download youtube subtitles for free"
Traffic: 60% of my total visitors come from organic search.

2. Reddit (The "Careful" approach)

Answering genuine questions in r/SaaS and r/Productivity.
Warning: Don't be spammy. You will get banned.

3. Content Marketing

Wrote a 5,000-word "Ultimate Guide to YouTube Subtitles".
It ranks #3 on Google for specific queries. Traffic: 25%.

💸 Revenue Breakdown (Month 6)

Source	Revenue
Individual users	$320
API subscriptions	$100
Ads (AdSense)	$80
Total	$500/mo

Net profit: ~$435/mo.

🎯 What I'd Do Differently

Talk to users FIRST: Would've discovered the AI angle in Week 1.
Start with paid from day 1: Free users give feedback, paid users give validation.
Focus on ONE channel: Don't spread yourself thin across Twitter, LinkedIn, and Reddit. Master one first.

📈 Key Metrics

MRR: $500
Churn: 15% (Working to improve this)
CAC: $12 (mostly organic)
LTV: $35 (Average user stays 5 months)

🤝 Want to Follow Along?

Check out the tool: ytvidhub.com

Questions for you:

What's your biggest challenge with side projects right now?
Would you pay for a YouTube AI tool?

Drop your thoughts below! 👇

P.S. If you're building something, ship it. Imperfect action > perfect inaction.

I Built a Bulk YouTube Subtitle Extractor as a Solo Dev — Here's My Tech Stack and What I Learned

Nuco Z — Fri, 27 Feb 2026 03:11:58 +0000

Every developer has that one side project that starts as a weekend hack and turns into something real. For me, it was a tool to bulk-extract YouTube subtitles.

It started with a simple frustration: I needed transcripts from an entire YouTube playlist for a research project. YouTube lets you copy transcripts one video at a time. I had 200 videos. That wasn't going to work.

So I built YTVidHub — a web app that extracts subtitles from YouTube videos, playlists, and entire channels in bulk. Paste a URL, pick your format (SRT, VTT, or TXT), and download everything as a ZIP.

Here's what the journey looked like from a technical perspective.

The Tech Stack

I wanted something that could ship fast, handle server-side rendering for SEO, and scale without DevOps headaches. Here's what I landed on:

Framework: Next.js 16 (App Router)
Language: TypeScript
Styling: Tailwind CSS
Database: PostgreSQL + Prisma ORM
Auth: JWT-based (custom, no third-party provider)
AI Features: DeepSeek API for video summarization
Payments: Stripe
Hosting: Vercel
i18n: next-intl (4 languages)

Why Next.js?

Two reasons: SEO and developer experience.

A subtitle downloader tool lives and dies by organic search traffic. Server-side rendering was non-negotiable. Next.js App Router gave me that plus React Server Components, which meant I could fetch data on the server without shipping unnecessary JavaScript to the client.

The file-based routing also made it easy to create dozens of SEO landing pages without a complex routing setup.

Why not use a third-party auth provider?

Cost. As a solo developer bootstrapping with zero funding, every dollar matters. Auth0 and Clerk are great, but their free tiers have limits that would bite me as I scale. A simple JWT + Google OAuth flow took me a day to implement and costs nothing to run.

// Simplified auth flow
const token = jwt.sign(
  { userId: user.id, email: user.email },
  process.env.JWT_SECRET,
  { expiresIn: '30d' }
);

Is it as feature-rich as Auth0? No. Does it work perfectly for my use case? Yes.

The Hard Part: Subtitle Extraction at Scale

The core technical challenge wasn't building the UI — it was reliably extracting subtitles from YouTube at scale.

Challenge 1: YouTube doesn't want you scraping subtitles

YouTube's official Data API doesn't provide subtitle content. You can get video metadata, but not the actual transcript text. The timedtext endpoint that serves subtitles to the YouTube player is undocumented and changes without notice.

My approach: I reverse-engineered the subtitle delivery mechanism and built a resilient fetcher that handles:

Multiple subtitle tracks per video (manual + auto-generated)
Language detection and selection
Rate limiting with exponential backoff
Graceful fallbacks when subtitles aren't available

The key insight was that YouTube serves subtitles as XML, which needs to be parsed and converted to standard formats:

// YouTube serves subtitles as XML like this:
// <text start="1.23" dur="4.5">Hello world</text>

function xmlToSrt(xml: string): string {
  const entries = parseXmlEntries(xml);
  return entries.map((entry, i) => {
    const start = formatTimestamp(entry.start);
    const end = formatTimestamp(entry.start + entry.duration);
    return `${i + 1}\n${start} --> ${end}\n${entry.text}\n`;
  }).join('\n');
}

Challenge 2: Playlist expansion

A YouTube playlist URL doesn't give you all the video IDs upfront. You need to paginate through the playlist API, which returns 50 items at a time. For a channel with 2,000+ videos, that's 40+ API calls just to get the video list.

I built a streaming pipeline that starts checking subtitles as soon as the first batch of video IDs arrives, rather than waiting for the full list. This makes the UX feel much faster — users see progress immediately.

Challenge 3: Bulk downloads without killing the server

When a user requests subtitles for 500 videos, you can't process them all synchronously. I implemented a queue-based system:

User submits playlist URL
Server expands the playlist and returns video list
Client requests subtitles in batches of 10
Each batch is processed in parallel on the server
Results are streamed back to the client
Final ZIP is assembled client-side

This keeps server memory usage flat regardless of playlist size.

SEO: The Make-or-Break for Tool Sites

For a free tool targeting organic traffic, SEO isn't a nice-to-have — it's the entire growth strategy. Here's what I did:

Programmatic SEO pages

I created dedicated landing pages for different search intents:

/youtube-subtitle-downloader — targets the generic search
/bulk-youtube-subtitle-downloader — targets the bulk/power user search
/what-is-an-srt-file — targets informational queries
/guide/* — long-form content for long-tail keywords

Each page has unique content, structured data (JSON-LD), and proper meta tags. Next.js makes this straightforward with generateMetadata:

export async function generateMetadata({ params }): Promise<Metadata> {
  const { locale } = await params;
  const t = await getTranslations({ locale, namespace: 'metadata' });

  return {
    title: t('title'),
    description: t('description'),
    alternates: {
      canonical: buildCanonicalUrl({ locale, pathname: '' }),
      languages: {
        'en': buildCanonicalUrl({ locale: 'en', pathname: '' }),
        'es': buildCanonicalUrl({ locale: 'es', pathname: '' }),
        // ...
      },
    },
  };
}

Internationalization for traffic

Adding support for Spanish, German, and Korean multiplied my addressable search volume by ~3x with relatively little effort. next-intl handles the routing and message loading, and I used AI to help with translations (then had native speakers review them).

What I got wrong

I initially created too many pages targeting similar keywords. Google got confused about which page to rank, and none of them ranked well. This is called "keyword cannibalization" — a lesson I learned the hard way. I'm now consolidating pages and using 301 redirects to focus authority.

Monetization: The Credits Model

I went with a credits-based system instead of a traditional subscription:

Free tier: 5 credits per day (1 credit = 1 video subtitle download)
Daily reward: +3 bonus credits for returning daily
Paid plans: Credit packs via Stripe for heavy users

Why credits instead of subscriptions? Two reasons:

Lower barrier to entry. Users can try the tool without committing to a monthly fee. Most people only need subtitles occasionally.
Natural upsell. When someone hits their limit mid-workflow, the friction of buying credits is much lower than subscribing. They're already invested in the task.

Stripe integration with Next.js was surprisingly smooth:

const session = await stripe.checkout.sessions.create({
  line_items: [{ price: priceId, quantity: 1 }],
  mode: 'payment',
  success_url: `${origin}/pricing?success=true`,
  cancel_url: `${origin}/pricing?canceled=true`,
  metadata: { userId, credits: creditAmount },
});

The webhook handles credit allocation after payment confirmation. Simple, reliable, no subscription management complexity.

Adding AI: The Unexpected Differentiator

The original product was just a subtitle downloader. But I noticed users were downloading transcripts to feed them into ChatGPT for summaries. So I built it in.

Now users can paste a YouTube URL and get:

An AI-generated summary of the video
Key points extraction
A mind map of the content structure

I used DeepSeek's API for this — it's significantly cheaper than OpenAI for long-context tasks, and the quality is excellent for summarization. The cost per summary is roughly $0.002, which makes it viable even on the free tier.

This feature turned out to be the biggest differentiator. There are dozens of YouTube subtitle downloaders, but very few that combine bulk extraction with AI analysis.

Lessons Learned After 3 Months

What worked

Solving my own problem. I built this because I needed it. That meant I understood the user deeply from day one.
Next.js + Vercel. Zero DevOps overhead. I deploy with git push and never think about servers.
Credits model. Lower friction than subscriptions for a tool that people use sporadically.
Internationalization early. Adding i18n from the start was much easier than retrofitting it later.

What I'd do differently

Start with fewer pages. I created 30+ SEO pages before validating which keywords actually had traffic. Should have started with 3-5 and expanded based on data.
Build in public sooner. I spent 2 months building in silence. Sharing progress on Twitter and dev communities from week 1 would have built an audience before launch.
Focus on backlinks from day one. On-page SEO is necessary but not sufficient. Without quality backlinks, Google won't rank you no matter how good your content is.

Numbers (honest)

Monthly visitors: ~600 (growing slowly)
Paying users: A handful
Revenue: Enough for coffee, not rent
Time invested: ~400 hours over 3 months

Is it a success? Not yet. But it's a real product that real people use, and the foundation is solid. The growth curve for SEO-driven tools is slow at first and compounds over time. I'm playing the long game.

If You're Building a Similar Tool

A few tactical tips:

Use Next.js App Router if SEO matters. The metadata API and server components are a huge advantage over client-side frameworks.
Don't over-engineer auth. JWT + OAuth is enough for most indie projects. You can always migrate to a provider later.
Ship the MVP in 2 weeks, then iterate. My biggest regret is spending too long on features nobody asked for.
Track everything from day one. Google Analytics + Search Console + Microsoft Clarity. You can't improve what you can't measure.
Write content that helps people. The best SEO strategy is genuinely useful content. Google is surprisingly good at detecting fluff.

If you're working on a side project or building in public, I'd love to connect. Drop a comment about what you're building — I read every one.

You can check out the tool at ytvidhub.com if you ever need YouTube subtitles in bulk.