DEV Community: Nuco Z

How I Remove People From Photos Without Ruining the Background

Nuco Z — Thu, 27 Aug 2026 08:44:36 +0000

Have you ever taken a photo that was almost perfect, only to notice someone you didn't want in the background?

A stranger walking through the shot.

Someone standing behind you.

A person appearing in the corner at exactly the wrong moment.

The frustrating part is that the photo itself is usually fine. You just want to remove one thing.

But removing a person is only half of the problem.

The harder part is making the background look natural afterward.

I’ve been working on a simple way to handle this using AI, and along the way I found a few things that make a surprisingly big difference.

Start with the original photo

The first thing I recommend is using the highest-quality version of the original image you have.

It might sound obvious, but the surrounding image gives an AI removal tool important information about what should replace the person.

A person standing in front of a plain wall is relatively straightforward.

A person standing in front of a complicated background is a completely different problem.

Before editing, I usually keep the original image untouched and work on a separate copy.

Select the entire person

One of the easiest mistakes is selecting only the obvious part of the person.

If you want to remove someone, try to include their entire body.

That means their head, hair, body, hands, legs, shoes, bags, and loose clothing.

Otherwise, you may end up with something strange like a hand or shoe remaining in the final image.

At the same time, don't make the selection unnecessarily huge.

If there is another person standing nearby, selecting too much can affect parts of the image you actually wanted to keep.

Give the selection enough room, but stay aware of what's around it.

Don't forget the shadow

This is probably the detail people notice only after they have already removed the person.

Imagine removing someone from a beach photo.

The person disappears.

But their shadow is still sitting on the sand.

Something immediately feels wrong.

The same thing can happen with shadows on roads, floors, walls, or other surfaces.

So before removing someone, look around their feet and underneath their body.

Ask yourself:

What else in this photo exists because this person is here?

Sometimes removing the shadow or reflection makes as much difference as removing the person itself.

Be careful when people are close together

Removing one person from a crowded photo is much harder than removing someone standing alone.

If two people are next to each other, a large brush can easily include part of the person you want to keep.

The same problem can happen around faces, hands, bags, signs, railings, windows, and other objects.

For these situations, I prefer using a more controlled selection.

The goal isn't to make the biggest possible selection.

The goal is to tell the AI exactly what needs to change.

Look at the background, not just the person

After the removal is finished, don't immediately decide that the result is good just because the person is gone.

Look at the background.

Does the ground still look natural?

Did a straight line suddenly move?

Is a texture repeated?

Did something near the person change unexpectedly?

Does the surrounding area still make sense?

I like to check the image at two different levels.

First, look at the entire photo normally.

Then zoom into the edited area.

The first view tells you whether the image feels natural.

The second helps you find small problems.

Some backgrounds are much easier than others

AI image removal works particularly well when there is useful information surrounding the object being removed.

Simple backgrounds such as sky, walls, roads, sand, grass, and floors can be easier to reconstruct.

Complicated backgrounds are more difficult.

For example, imagine someone standing directly in front of a sign.

The entire middle section of the sign is hidden by the person.

There may be no visible information showing what was actually behind them.

An AI model can create a plausible continuation, but it cannot know with certainty what was originally there.

This is an important thing to understand about AI image editing.

The goal is often to create something that looks natural, not to recover pixels that no longer exist.

What I use for quick edits

For a simple removal, I don't really want to open a full image editor and spend several minutes setting everything up.

Usually I just want to upload an image, mark the unwanted area, and see the result.

That's why I built ImgEraser.

It focuses on one simple workflow: upload an image, brush over the person or object you want to remove, and let AI reconstruct the selected area.

You can try it here:

https://imgeraser.com/

The interesting part isn't just the AI model.

The editing workflow matters too.

If the selection is wrong, even a good model can produce a bad result.

If the selection is accurate and there is enough surrounding information, the result can be much more convincing.

What if the first result isn't good?

Don't keep editing the already-edited image.

Go back to the original.

Then change the selection.

If part of the person is still visible, make the selection slightly larger.

If something nearby was accidentally changed, make it smaller.

For complicated images, you can also think about different parts of the image separately instead of trying to solve everything with one enormous selection.

And always keep the original

I know this sounds obvious, but don't overwrite your original photo.

Keep the original and save the edited version separately.

That way you can compare the two versions or try another approach if the first result isn't what you wanted.

The best AI edit is the one nobody notices

This is probably the part of AI image editing that I find most interesting.

The best result isn't necessarily the one that looks the most "AI generated."

Actually, it should be the opposite.

If someone looks at the finished photo and doesn't notice that anything was changed, the edit has done its job.

That's the idea behind ImgEraser.

Not trying to replace a professional image editor.

Not trying to add hundreds of editing controls.

Just making one annoying photo-editing task a little easier.

If you have a photo with an unwanted person or object in it, try it with your own image:

https://imgeraser.com/

I'm especially interested in the difficult cases.

Crowded backgrounds, reflections, detailed patterns, overlapping people, text, and anything else that produces an unexpected result.

Those cases are much more useful than a perfect example because they show where the experience still needs improvement.

Your AI Summary Is Not Evidence: Building a Timestamped YouTube Research Workflow

Nuco Z — Mon, 10 Aug 2026 11:41:20 +0000

A two-hour interview can be easy to summarize and surprisingly hard to cite.

That gap matters more than it first appears. A fluent AI summary may tell you what a video was about, but it does not automatically tell you where a claim came from, which words were actually spoken, or whether a number was copied correctly. For research, study notes, subtitle work, and content repurposing, the useful artifact is not just a summary. It is a summary with a path back to the source.

This is the workflow for turning YouTube captions into evidence that can be searched, checked, and exported.

Summary and evidence are different artifacts

A summary is an interpretation. A transcript is a record of the words available in a source. They solve different problems.

When a model summarizes a long video, it may compress several statements into one sentence, omit a qualification, or merge two speakers. That can be fine for discovery. It is risky when the result becomes a quote, a statistic, a product requirement, or a paragraph that someone else needs to audit.

The safest sequence is:

Search the transcript to find the relevant passage.
Read the surrounding caption segments.
Jump to the original timestamp.
Use the verified passage as the evidence for your summary.

Search in text, decide with context, verify in video.

That extra loop is small. It is also the difference between the model saying something and the source supporting it.

Start with the caption track

YouTube videos do not all expose the same transcript data. A public video may have creator-uploaded captions, automatically generated captions, multiple language tracks, or no accessible caption track at all.

A reliable workflow needs to preserve that distinction. Manual captions and automatic captions should not be presented as identical sources. Automatic captions are useful, but names, numbers, accents, and technical terms deserve a timestamp check.

There is another important boundary. Retrieving an existing caption track is not the same as downloading the video or audio and running a new speech-to-text job. If the captions already exist, moving the text is usually faster, lighter, and easier to audit.

YT to Text is designed around that boundary. Paste a public YouTube URL, and it opens the caption track that YouTube makes available. There is no video or audio upload step.

Videos can still be unavailable. Private, removed, restricted, still-live, or caption-free sources may not provide a usable transcript. Repeating the request cannot manufacture a missing track, so the honest result is an unavailable source.

Search exact phrases before broad topics

Long transcripts become practical when they behave like searchable documents.

Start with the most specific term you know, such as a surname, product name, uncommon technical phrase, or short quote. If it does not appear, shorten the query one word at a time. A narrow search gives you a smaller set of passages to verify.

When a match appears, do not copy only the matching line. Read at least one segment before and after it. Captions are split for timing, not for meaning. The sentence you need may continue in the next cue, and the speaker's qualification may be in the previous one.

This is also where transcript search beats scrubbing. A video player is a linear interface. Research is not. Searching the text lets you move directly to the relevant moment, then use the video for the final judgment.

Keep the timestamp attached

A transcript without timing is convenient until you need to check it.

Keep the original timestamp beside important passages. This lets you answer practical questions quickly:

Did the speaker say 15 or 50?
Was the claim about the product, the market, or a hypothetical?
Did the sentence belong to the host or the guest?
Was the word an industry term or an automatic-caption error?

Timestamp verification is not only for journalists. It helps students cite lectures, editors prepare subtitles, researchers collect quotes, and content teams turn interviews into accurate briefs.

For a short note, a clean reading view is comfortable. For a claim that will be published, the timestamp is part of the evidence.

Pick an export format that matches the next task

TXT, SRT, and VTT are different working formats, not decorative file extensions.

TXT is the simplest option for reading, notes, search, and AI prompts. Use it when the words matter more than timing.

SRT is built for subtitle cues with sequence numbers and start/end times. It is a natural handoff to video editors and subtitle tools.

VTT is designed for web video and the HTML track element. Use it when captions will be attached to a browser-based player.

If you are preparing a transcript for an AI assistant, start with clean TXT for the main context and preserve a timestamped copy for verification. One source should be enough to produce all three exports. Re-submitting the same video just to change the format is unnecessary.

Give AI an evidence layer

A language model is useful after the source has been made searchable, not instead of that step.

For a long interview, split the transcript into logical sections. Keep timestamps on claims that may need checking. Ask the model to separate direct evidence from interpretation and to cite the relevant timestamp when it makes a factual statement.

A practical prompt can be simple:

Summarize this section in five bullets. For every factual claim, include the source timestamp. Mark anything that is an interpretation or an uncertain automatic caption.

The prompt is not a guarantee of accuracy. It is a reminder that the transcript remains the evidence layer and the model remains the analysis layer.

There is a more detailed version of this workflow in this guide for preparing a YouTube transcript for Claude.

Privacy belongs in the workflow

Transcripts can contain client names, unpublished research, or quotes that are not ready to share. A useful tool should make the working state private by default.

YT to Text keeps transcript workspaces private and removes anonymous job history after 24 hours. You can start without an account and complete up to three successful transcript requests per day. Failed requests do not consume the successful allowance.

Those product limits are intentionally visible. A trustworthy workflow should tell you when it can retrieve captions, when it cannot, and what happens to the working data.

You still need to respect copyright, platform rules, and the purpose of the original source. A transcript makes a video easier to analyze. It does not transfer ownership of the speaker's words.

The reusable loop

The complete process is short:

Copy the public YouTube URL.
Check that an accessible caption track exists.
Note the language and whether the captions are manual or automatic.
Search for an exact phrase.
Read the surrounding context.
Verify important lines at the original timestamp.
Export TXT, SRT, or VTT for the next task.
Keep the source URL with your notes.

The first-principles idea is to move the smallest useful representation of the source. If captions already exist, do not download a full video just to recover its words. Retrieve the text, preserve the timing relationship, and return to the source when accuracy matters.

That is how a transcript stops being a wall of text and becomes a dependable research surface.

Why a YouTube transcript tool should preserve the path back to the source

Nuco Z — Sun, 09 Aug 2026 14:15:53 +0000

There is a deceptively simple version of a YouTube transcript tool.

Accept a URL. Fetch some caption text. Put the result in a large text box. Add a copy button. Done.

That version works until someone tries to use the transcript for real work.

A researcher finds a number but cannot tell where it appeared in the video. An editor receives plain text but needs timed cues. A student searches a long lecture and sees one match without the explanation around it. An automatic caption misspells a name, yet the interface gives no clue that the line should be checked.

The difficult part is not turning captions into characters. It is preserving enough structure that those characters remain useful and trustworthy.

That became the main product constraint behind YT to Text, a private workspace for captions already available on public YouTube videos.

This article explains the decisions behind that constraint and the broader engineering lesson they reveal.

Begin with the user’s next action

It is tempting to define a transcript product by its input and output.

The input is a YouTube URL. The output is text.

But users do not arrive because they enjoy transforming URLs into strings. They arrive because another task is blocked.

They need to find a phrase in a lecture, verify a quote from an interview, copy a clean passage into notes, or import captions into an editing workflow.

Once the next action becomes the unit of design, the product requirements change.

Finding a phrase requires search and match navigation. Verifying a quote requires timestamps linked back to the source. Reading requires a clean text view. Editing requires a timed interchange format. Repeated work requires the successful result to remain available without fetching the source again.

The central object is therefore not a text blob. It is an ordered collection of caption segments.

Conceptually, each segment needs at least two pieces of information.

type TranscriptSegment = {
  startSeconds: number;
  text: string;
};

Everything else can be derived from that representation.

A readable transcript groups segments for scanning. A plain-text export joins the text. A timestamped view formats startSeconds. Search maps matches back to their segment. SRT and VTT derive timed cues from the same ordered source.

One retrieval. Multiple useful representations.

Search should preserve context

A naive transcript search can return a count and highlight a matching substring. That is technically correct but often practically weak.

Imagine searching a two-hour interview for a product name. The useful answer is not merely that the name appears four times. You need to move through those four moments, read the sentences around each match, and inspect the matching moment in the original video.

This leads to three small but important rules.

Search the source transcript without rewriting it. Keep an ordered list of match positions. Make every result reversible through its timestamp.

The first rule prevents search from changing the evidence. The second makes next and previous navigation deterministic. The third keeps the transcript connected to the video.

That final connection is easy to underestimate. A timestamp is not decorative metadata. It is a compact provenance link.

When automatic captions turn a technical term into a plausible but incorrect word, the user needs a cheap way to check. A clickable timestamp makes verification one action. Removing timestamps makes verification a second research project.

TXT, SRT, and VTT are different jobs

Export menus often present file formats as a cosmetic preference. In transcript workflows, each format represents a different job.

TXT is for reading, notes, search, and copy. It may be plain or include human-readable timestamps.

SRT is for editing and subtitle upload. It requires sequential cue numbers and time ranges in this form.

1
00:00:02,000 --> 00:00:06,000
The first caption line.

VTT is for web video and browser-oriented caption workflows. It begins with a WEBVTT header and uses a period for milliseconds.

WEBVTT

00:00:02.000 --> 00:00:06.000
The first caption line.

The formatting details look tiny, but tiny protocol differences are where supposedly convenient tools create expensive cleanup work.

There is another edge case. Caption sources often provide the start of a segment without a clean, editor-friendly end time. A formatter still needs to create a valid cue range. The implementation should derive the end from the next segment when possible and enforce a readable minimum duration when consecutive start times collapse together.

That behavior deserves direct tests. Formatting code is deterministic, easy to isolate, and likely to break downstream tools if it changes silently.

The KISS version is not to build three export pipelines. It is to keep one validated segment model and three small pure formatters.

Validation belongs at the boundary

Media metadata from an upstream service should be treated as untrusted input, even when the service is yours.

A successful-looking response can still contain an empty segment array, negative timestamps, missing language metadata, or a malformed job identifier. Allowing that state into the rest of the application spreads defensive checks across every component.

The simpler approach is to validate once at the boundary and fail with useful context.

The validated transcript job can then become the public interface used by search, rendering, download formatting, retention, and any private AI features. Those consumers should not reach into the extractor’s internal response shape.

This keeps the modules loosely coupled. It also makes failures easier to understand.

If retrieval failed, report a retrieval problem. If the video has no available captions, report that boundary. Do not return an empty transcript and hope the UI invents the correct explanation.

An empty successful result is not graceful degradation. It is an ambiguous error.

Do not claim capabilities the source cannot provide

One of the most important product decisions is also one of the least technical.

The free transcript workflow in YT to Text retrieves caption tracks already available for public YouTube videos. It does not generate a new transcription for a caption-free video. It does not present a machine translation as an original caption language. It does not make automatic captions more accurate by displaying them in a polished interface.

Those limits need to appear in the product, not just in an internal architecture diagram.

Private, removed, restricted, still-live, and caption-free videos may not produce a transcript. Available languages depend on the caption tracks YouTube provides. Automatic captions can contain errors in names, numbers, punctuation, accents, and technical vocabulary.

The interface labels the selected caption source and encourages timestamp verification for important lines.

This is a general design rule for tools built on upstream data.

Expose the boundary where users make decisions.

If the source is probabilistic or imperfect, hiding that fact does not remove uncertainty. It transfers the uncertainty to the user at the worst possible moment.

Privacy follows data minimization

A public YouTube link is public. A person’s collection of researched videos is not necessarily public.

The caption retrieval task does not require uploading the video or audio. It needs the public video identifier and the available caption source. Collecting the media file would create more transfer, storage, and privacy risk without helping the current task.

So the product does not request a video upload.

The generated workspace is private and is not exposed as a public SEO page. Anonymous history is removed after 24 hours. Private workspace and profile routes should remain outside search indexing.

This choice is useful beyond privacy. It also keeps the public site’s information architecture honest. Public pages explain the product and its formats. Private pages contain user work. Mixing the two can leak user activity while filling search indexes with thin, duplicated transcript pages.

Data minimization is often presented as a compliance exercise. Here it is also the simplest architecture.

Count delivered value, not attempts

YT to Text currently allows three successful transcript jobs before sign-in, and a free account receives five successful jobs per day.

The important word is successful.

An invalid URL, an unavailable video, missing captions, or a service failure does not deliver the thing the user came for. Counting that attempt against the allowance would be easy to implement and hard to justify.

Usage therefore needs to be reserved and recorded around a successful outcome, with idempotency protecting retries from being counted twice.

This is another case where the product principle shapes the data model. If billing or quota state is attached to button clicks, network retries and partial failures become user-facing unfairness. If it is attached to a durable successful job, the rules become much easier to explain.

The third successful transcript also remains usable. A quota boundary should prevent a new job, not retroactively damage the result that crossed the line.

Make transformations traceable

Transcript tools sit inside a larger family of products that compress or transform source material. Summarizers, document parsers, search indexes, analytics dashboards, and AI assistants all do some version of this.

The shared danger is losing the route back.

A summary without citations is quick but difficult to audit. A chart without access to underlying values is persuasive but fragile. A transcript without timestamps is readable but detached from the thing it represents.

The resulting design principle is simple.

Every useful transformation should preserve a cheap path back to its source.

In YT to Text, that path is a timestamp. In another product it may be a document page, a database row, a request identifier, or a source URL. The mechanism changes. The trust model does not.

Compression gives users speed. Traceability gives them agency.

A practical test

If you are building a transcript or media tool, take one real user task and follow it past the first successful response.

Do not stop when text appears on the screen.

Can the user find one exact phrase in a long result? Can they see enough surrounding context to interpret it? Can they reopen the corresponding source moment? Can they export a format their next tool understands? Can they tell when the upstream caption may be incomplete or inaccurate? Does a failed request consume their quota? Is private work accidentally becoming public content?

Those questions reveal more product quality than the size of the text box.

You can try the current workflow at YT to Text. Paste a public YouTube video with available captions, search for something specific, open a matching timestamp, and export the transcript in the format your next task needs. The first three successful transcripts do not require sign-in.

The output is text.

The product is the path that keeps the text useful.

Building a Privacy-First Face Analyzer That Runs in the Browser

Nuco Z — Fri, 31 Jul 2026 07:42:54 +0000

Most AI face analysis products begin with a simple architecture: upload a photo, send it to an API, run a model on a server, and return a score.

That approach is convenient, but it creates a data problem. A face photo is personal data, and many people do not want to upload it just to learn about visible proportions or face shape. When I built LookBlueprint, I started with a different constraint:

The useful first result should be possible without sending the original photo to a server.

This constraint shaped almost every technical decision in the product.

Running the first analysis locally

The free analysis runs in the browser using MediaPipe Face Landmarker and a bundled WebAssembly runtime. The model and runtime are shipped with the application, and the analysis work runs in a Web Worker so the interface remains responsive while landmarks are being detected.

The flow is roughly:

The user selects one clear, front-facing photo.
The browser validates and prepares the image for analysis.
The worker detects facial landmarks and basic image-quality signals.
Pure TypeScript analysis functions convert those landmarks into a versioned face-analysis snapshot.
The UI renders the snapshot into focused results and educational explanations.

The original image is not uploaded for the free result. There is no login requirement for that workflow, and the result is kept temporarily in the browser session.

This is a practical privacy improvement, but it also changes the engineering trade-offs. The model must load reliably on a range of devices, image processing must fit within browser memory limits, and errors must be understandable to a person who is not debugging a machine-learning pipeline.

Measuring structure instead of pretending to measure beauty

A face-analysis score can sound more objective than it really is. I wanted the product to expose measurable references without presenting them as a universal ranking of people.

LookBlueprint separates several types of output:

Visible left-to-right symmetry and pair differences.
Face-shape candidates with confidence percentages.
Vertical thirds and horizontal fifths.
Face length-to-width and facial width-to-height ratios.
Eye-shape references and canthal tilt.
Jawline and lower-face structure.
A separate photo-reliability signal.

The overall rating is not treated as a scientific truth. It combines selected structural signals, while camera reliability remains separate. Natural asymmetry, lighting, head rotation, expression, lens distortion, and landmark quality all affect what can be measured in one photo.

That distinction matters. A result should help someone understand the image in front of them, not tell them what they are worth or reduce a complex person to a number.

The hardest part is measurement quality

Face landmarks are not the same thing as ground truth. A small change in camera angle can change the apparent proportions. Hair can hide the jawline. Low light can reduce landmark stability. A wide-angle selfie can exaggerate the center of the face.

Because of that, the interface explains limitations next to the result instead of hiding them in a legal page. It reports confidence, identifies the photo conditions that affect interpretation, and encourages users to treat the output as a reference from that image.

This also makes the error states important. If a photo does not contain a usable face, the user needs a clear next step: try a brighter, more front-facing image with the face unobstructed. A generic "analysis failed" message is technically accurate but not useful.

A small architecture with explicit boundaries

The application uses a Next.js frontend, a Web Worker for the browser analysis pipeline, and pure analysis modules that transform landmarks into a typed, versioned FaceAnalysisSnapshot.

That snapshot is the boundary between detection and presentation. The worker does not need to know how a result card is rendered, and the UI does not need to know how the model locates landmarks. This keeps the core calculations testable and makes it possible to add focused tools without duplicating the detection pipeline.

The product currently includes focused views for rating, symmetry, face shape, proportions, canthal tilt, jawline, eye shape, and a neutral structure view. It also includes guides covering methodology, research references, accuracy, bias, limitations, privacy, and practical style questions.

What happens when a user wants a report?

The free analysis stays in the browser. For the optional personalized Face Blueprint report, the browser prepares a constrained analysis copy for the report workflow rather than sending the original source file. The copy is limited in size and dimensions, and the report can be delivered as an on-page result, a multi-page PDF, and a keepsake image.

The important product decision is to make that boundary visible. Users should know which workflow is local, which workflow is optional, and what kind of image copy is involved.

Why build it this way?

The first-principles answer is simple: if the product only needs facial landmarks and ratios for its free result, uploading the original photo is not a necessary starting assumption.

Local processing does not solve every privacy or accuracy problem. It does, however, reduce unnecessary transmission, give users a clearer mental model, and force the product to be honest about what one photo can and cannot tell us.

You can try the free browser-based analyzer at lookblueprint.com. The goal is not to produce a definitive judgment. It is to give people a private, understandable way to explore the visible patterns in a photograph.

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.