DEV Community: Leon

What an AI Rap Video Generator Taught Me About Crawlable React Pages (2026)

Leon — Mon, 02 Nov 2026 03:08:02 +0000

Disclosure: I build MyAIRap.video, a photo-to-Rap tool. This is a development case study from that project, written with AI assistance and checked against our local release records. It is not a claim that server rendering alone produces rankings.

The first useful SEO question for a React product is surprisingly practical: what does a reader get before JavaScript runs?

Our redesigned interface looked complete in a browser. It had examples, pricing and a clear path to the creator. A raw HTML check told a different story: the initial response was a small shell. The words people could see after rendering were missing from the first response.

For an AI rap video generator, that is a product problem as much as a search problem. A visitor needs to understand the input, the resulting video and the purchase model before signing in.

Render the public explanation, keep the private app private

We reused the same React marketing components for pre-rendered public HTML. The homepage, pricing, tutorial and articles now have meaningful headings, paragraphs and links in the first response. Their client-side counterparts use the same route metadata rather than inventing a second title after navigation.

The account and checkout are different. We did not turn private balances or orders into indexable pages. Public explanation and authenticated actions share a design, but they do not share an indexing policy.

This distinction is easy to lose when every URL looks like “just another React route.”

A small acceptance check catches the important failures

For a public route, we check:

The raw response contains exactly one meaningful H1.
Title, description, canonical and language correspond to that route.
Prices visible in HTML come from the retained product catalogue.
Tutorial, examples and article links are real anchors.
The browser does not replace the correct server title with a generic default.
The narrow layout has no document-wide horizontal overflow.

A response-size threshold helped detect the old empty shell, but size alone is not the goal. A large response with duplicated filler would still be a bad page. We check for actual useful content and correct links.

Product claims are part of the rendering contract

Our creator has Mini and Standard, two durations and two resolutions. Existing showcase videos were made with Standard. A marketing page that implies the least expensive option always matches the showcase would create the wrong expectation, however well it rendered.

The same applies to a template button. Today it records interest in an unreleased format; it should not look like a working purchase for exact recreation.

That is why we keep pricing, availability and model caveats in the same acceptance review as headings and metadata. The page is an explanation of the application, not a separate brochure allowed to drift away from it.

What we can and cannot conclude

Raw HTML and browser checks can show that content is available. They cannot show that Google has indexed the latest version, that a keyword will rank, or that an AI assistant will cite it. Those need separate observation windows and real search or referral evidence.

If you are building a similar tool, inspect the response before writing another SEO article. Then check a client-side navigation into pricing and back. The second step catches metadata regressions that a single homepage request misses.

The MyAIRap tutorial shows the actual photo, lyric and video workflow behind this case. The main lesson is portable: make the public explanation readable, and keep the private transaction private.

Building a Browser-Local Moving Checklist Without User Accounts

Leon — Thu, 10 Sep 2026 03:27:47 +0000

Many planning tools begin with sign-up, cloud storage, and collaboration features. For a moving checklist, I wanted to test a narrower idea: can a useful planning tool work without requiring an account?

MovePlaybook is a browser-based moving checklist. A user starts with a move date, reviews a generated task plan, adjusts tasks when circumstances change, and can print or save the plan as a PDF.

The technical constraint was privacy: the product should remain useful even when the plan is stored locally in the browser. That shaped several decisions.

First, task identity needs to be stable. A user may complete, reschedule, hide, restore, or annotate a task, so those changes must attach to a durable task ID rather than a display position.

Second, temporary hiding must not mean deletion. A hidden task is excluded from the active checklist and PDF, but it remains recoverable through a dedicated Hidden view.

Third, schedule changes need explanations. When a user adjusts a date, the interface should distinguish between a recommended date, a tight timing window, a conflict, or something the user must confirm locally.

The product is available at https://moveplaybook.app/

I built it as a practical experiment in local-first planning. I would be interested in how other developers approach versioned browser storage, printable application state, and explainable scheduling rules.

How to convert a folder of PNGs to one PDF without uploading the files

Leon — Sat, 05 Sep 2026 12:48:21 +0000

A simple browser-local PNG-to-PDF workflow

For this kind of job, the useful workflow is straightforward:

Select the PNG, JPG, or JPEG files.
Put the pages in the order they should appear.
Choose a page size and margins if the document needs them.
Export one PDF.

The important detail is where the conversion happens. A browser-local PNG-to-PDF tool processes the images in the browser instead of uploading them to a conversion server. That makes it easier to keep control of source files while still producing one shareable PDF.

When this is useful

This workflow is handy for:

combining screenshots into a bug report or handoff document;
turning scanned pages into one file for email or printing;
arranging portfolio images or design exports in a deliberate order; and
collecting receipts or reference images without making a separate document first.

Before exporting, check the page order and decide whether each page should match the image, A4, or US Letter. A preview is useful here: it catches a stray portrait page, an oversized margin, or a screenshot in the wrong position before the PDF is created.

The tool I use for this

I maintain PNG Binder, a free PNG-to-PDF converter for this specific workflow. It accepts up to 50 PNG, JPG, or JPEG images, lets you arrange them, and creates one PDF locally in the browser. It does not require an account, and the images are not sent to a conversion server.

It creates an image-based PDF, so it does not perform OCR or rebuild text and tables. If that is the kind of result you need, try it and let me know whether page ordering, page settings, or browser compatibility could be improved.

Disclosure: I am the maker and operator of PNG Binder.

A small privacy decision that changed my web calculator

Leon — Thu, 03 Sep 2026 10:00:20 +0000

I built Calculator Toolkit for a narrow moment: someone has a restaurant bill, wants to check the tip and tax math, then needs to split the total with a few people.

At first I treated the no-account requirement as a small feature. It turned out to be the decision that shaped most of the interface.

A saved-history feature would be convenient. It would also mean sign-in, account recovery, data retention, and an extra decision for someone who only wants to settle a dinner bill. I decided that the calculator should run locally in the browser instead. There is no account and no bill-data upload.

That creates constraints. A person cannot return tomorrow and recover an earlier calculation. There is no dashboard where an unclear result can be explained later. The current screen has to do the work. It needs to make the bill amount, tax, tip basis, total, and each person's share understandable before the group pays.

I found that this was less about adding a privacy notice and more about removing places where the product could hide complexity. If the calculation is temporary, the result needs to be legible now. If somebody changes the tip basis, the change needs to be obvious. If one diner pays a different share, the total still has to add up.

I do not think local-only is a universal rule. It is a poor fit for products where history, collaboration, or handoffs are the reason people use the product. For a one-off restaurant calculation, it felt like the more honest default.

I am Leon, the maker of Calculator Toolkit. I would like feedback from other developers: when you remove accounts or saved state from a small tool, which parts of the interface become harder to get right?

Disclosure: This article was drafted with AI and reviewed by Leon.