DEV Community: PENG YONG

I built a face-rating tool that never sees your photo — here's what I learned about on-device ML

PENG YONG — Wed, 14 Oct 2026 01:11:19 +0000

Why I Built This

A friend told me his face shape was better than mine.

I'm not going to argue with him — I have no data. So I went looking for one of those "what's your face shape" tools. Every single one wanted me to upload a photo of my face. To a server. Run by someone I don't know.

Look, I'm a developer. I know what happens to uploaded images. I've written the code that stores them. I did not want a photo of my own face sitting in someone's bucket with a Date.now() filename and an ACL I can't see.

So I built the version I wanted: one that measures your face and never uploads it. Not "we delete it after 24 hours" — the photo literally never leaves the browser tab. It goes into a canvas, MediaPipe reads it locally, and that's the end of it.

It's called FaceRuler. It's free. There's no sign-up — that part wasn't a growth decision, I was just too lazy to build auth for a tool that doesn't need an account.

The Stack

Next.js 16 (App Router)
MediaPipe FaceLandmarker — 478 landmarks, compiled to WASM; the model is ~3.6 MB and both it and the WASM runtime are served from my own origin
Cloudflare Workers via OpenNext, D1 for the few tables I actually need
A hosted checkout for the paid deep report (the free report is the whole measurement, not a teaser)

The part that matters: there is no server-side inference. Nothing to opt out of, nothing to trust me about. The network tab stays quiet.

The scoring is just math (that's the point)

Here's the decision that surprised people most: there is no LLM anywhere in the scoring.

I could have asked a model to "rate this face". I didn't, for two reasons. One, it would mean uploading the photo — dead on arrival. Two, a score you can't reproduce is a score you can't argue with, and people who use face-rating tools argue.

So it's geometry. Every sub-metric is scored with a Gaussian falloff around a reference target:

export const targetScore = (value: number, target: number, tol: number): number => {
  const z = (value - target) / tol;
  return 100 * Math.exp(-0.5 * z * z);
};

Eight sub-metrics (symmetry, facial thirds, FWHR, canthal tilt, jaw ratio, eye spacing, eye aspect, golden ratios) roll up into five weighted dimensions. The weighted overall maps onto the PSL 0–8 scale with a logistic curve anchored so an average face lands at exactly 4.0:

// overall 50 -> exactly 4.0 on the 0-8 scale
export const overallToPsl = (overall: number): number =>
  8 / (1 + Math.exp(-(overall - 50) / 13));

Median at 4.0, not 5 — the PSL scale is deliberately stricter than a casual 1–10 rating, and the percentile uses a normal distribution (mean 4.0, SD 0.9).

Because it's all pure functions, the entire engine is unit-tested (12/12 green) and "recalibrate" is a one-line change instead of a retrain. Same landmarks in, same report out, every single time.

Two things that were harder than they look

MediaPipe coordinates will quietly shrink your face. The landmarks come back normalized: x divided by image width, y divided by image height. Compute a height/width ratio naively and a 3:4 portrait reads about 25% "shorter" than the same face on a square canvas — enough to flip the score. You have to scale the y component back into pixel-equivalent space. Nobody warns you about this one.

A tilted photo shouldn't change your score. So before computing anything, I measure the midline angle from forehead-top to chin and rotate every landmark into a roll-corrected frame. Vertical distances — like the FWHR numerator — fall apart without it.

One more that isn't a bug but deserves to be documented: the academic FWHR ratio (1.85–1.9) is measured on physical photographs. In normalized landmark space, the nasion-to-upper-lip distance runs ~36% of bizygomatic width, so the numbers aren't comparable at all. I calibrated my own center (2.75) from landmark batches instead of pretending the paper value applied.

The front-end bug that ate a whole evening

React 19's synthetic onChange does not fire for programmatically dispatched change events.

My upload component has to work for real users and for my own automated tests, which inject a File via DataTransfer. The synthetic handler was silent in the injected path. Real users would have been fine — which is exactly why it's dangerous. The test would have lied to me.

Fix: drop the synthetic handler, wire a native addEventListener through a ref. Turns out it's more robust for real users too.

And a rule I now enforce everywhere: never put a ref-dependent DOM node inside a conditional render. My result <canvas> lived inside report && (...). Before the first report, canvasRef.current is null, the draw function's guard returns early, and you get… nothing. No error, no output. I hit this exact bug twice, in two different components, before writing it down as a rule.

What's Next

Server-side license verification. Right now entitlements live in localStorage, which means clearing your cache loses your purchase. I say that out loud in the docs instead of hiding it.
A second tool that shares the same credit system.
Quarterly recalibration from anonymous aggregate data.

Try It

It's live and free, no sign-up: https://faceruler.com

Drop in a photo and you get your face shape, a PSL score, a percentile, and all eight metric readings — with the formulas behind each number instead of just a verdict. Your photo stays on your machine; you can watch the network tab if you don't believe me.

Genuinely curious: if you've shipped something where "we don't upload it" is the entire pitch, how did you get people to believe you? I ended up showing the calculation, but I'm not convinced that's the best answer.

Your photo never leaves the browser — building a client-side face analysis app with MediaPipe

PENG YONG — Wed, 14 Oct 2026 00:55:41 +0000

FaceRuler is a free face shape detector and attractiveness test. You drop in one photo, and a few seconds later you get your face shape (one of seven), a score on the PSL 0–8 scale, a casual 1–10 rating, a percentile, and a breakdown of eight facial metrics — all computed on your device. The photo is never uploaded. Not "we delete it after processing" — it never leaves the browser tab.

That single constraint shapes almost every engineering decision in the app. Here's the pipeline, and the parts that were actually hard.

Why on-device at all

Most "rate my face" tools send your selfie to a server and run a model there. That's a big ask: it's a photo of your face, tied to your identity, going to infrastructure you can't inspect. And for this specific product category — attractiveness scoring — the trust problem is the product. If the privacy claim isn't literally, verifiably true, nothing else matters.

So inference runs in the browser with MediaPipe's FaceLandmarker (478 landmarks) compiled to WASM. The model (~3.6 MB) and the WASM runtime are served from our own origin, so there's no third-party request at inference time either.

The pipeline: detect → measure → map

Detect. MediaPipe returns 478 normalized landmarks. We draw them over a canvas as a visual receipt.
Measure. Pure geometry converts landmarks into ratios — facial thirds, FWHR, canthal tilt, jaw ratio, and so on.
Map. A deterministic function turns those ratios into 0–100 sub-scores, then into the PSL 0–8 scale.

No LLM. No "AI vibes". The same landmarks always produce the same report. That's a product decision as much as a technical one: a score you can't reproduce is a score you can't argue with — and this audience argues.

The scoring engine is just math (that's the point)

Every sub-metric is scored with a Gaussian falloff around a reference target:

export const targetScore = (value: number, target: number, tol: number): number => {
  const z = (value - target) / tol;
  return 100 * Math.exp(-0.5 * z * z);
};

Eight sub-metrics roll up into five dimensions with fixed weights — Symmetry 0.2, Proportions 0.25, Structure 0.25, Eyes 0.15, Harmony 0.15. The weighted overall (0–100) maps to PSL with a logistic curve anchored so a perfectly average profile lands at exactly 4.0:

// overall 50 -> exactly 4.0 on the 0-8 PSL scale
export const overallToPsl = (overall: number): number =>
  8 / (1 + Math.exp(-(overall - 50) / 13));

Median at 4.0, not 5. The PSL scale is deliberately stricter than a casual rating. Percentile uses a normal distribution with mean 4.0 and SD 0.9. Because it's all pure functions, the whole engine is unit-tested (12/12 green) and recalibration is a one-line change, not a retrain.

Four things that were genuinely hard

1. Head roll. A tilted photo shouldn't change your score. We measure the midline angle from forehead-top to chin, then rotate every landmark into a roll-corrected frame before computing anything. Vertical distances — like the FWHR numerator — are especially sensitive to this.

2. Aspect ratio silently shrinking the face index. MediaPipe returns normalized coordinates: x divided by image width, y divided by image height. Compute a height/width ratio naively and a 3:4 portrait reads about 25% "shorter" than the same face on a square canvas. We correct by scaling the y component back into pixel-equivalent space.

3. FWHR doesn't mean what the papers say. The academic facial width-to-height ratio (1.85–1.9) is measured on physical photographs. In normalized landmark space the nasion-to-upper-lip distance runs ~36% of bizygomatic width, so the numbers simply aren't comparable. We calibrated our own center (2.75) from landmark batches and documented the mismatch instead of pretending the paper value applied.

4. Harmony is not the average. Averaging sub-scores rewards a face that's mediocre everywhere. We wanted the opposite — consistency. So "Harmony" is derived from the standard deviation of the sub-scores: one dragging feature lowers it.

Front-end lessons that cost the most hours

React 19's synthetic onChange doesn't fire for programmatically dispatched change events. Our upload component has to work both for real users and for automated tests that inject a File via DataTransfer. The synthetic handler didn't fire in the injected path. Fix: drop the synthetic handler and wire a native addEventListener through a ref. Bonus — it's more robust for real users too.

Never put a ref-dependent DOM node inside a conditional render. Our result <canvas> lived inside report && (...). Before the first report, canvasRef.current is null, so the draw function's guard silently returned — no error, no output, just nothing. We hit this exact bug twice, in two different components. The rule we now enforce: ref-dependent nodes are always mounted and toggled with hidden.

A single dependency mismatch can 500 your entire content layer. All MDX pages broke with TypeError: files.map is not a function. Root cause: the lockfile resolved fumadocs-core to 15.8.5 while fumadocs-mdx 11.10.1 expected the 15.7.x interface. Pinning fumadocs-core@15.7.13 fixed it.

Node's undici fetch ignores your system proxy. Server-side OAuth silently timed out and surfaced as a misleading invalid_code. A ProxyAgent global dispatcher for dev fixed it — and no-ops in production on Workers.

Stack

Next.js 16 (App Router), deployed on Cloudflare Workers via OpenNext, with D1 for the license/entitlement tables and a hosted checkout for the paid deep report. MediaPipe runs entirely client-side; the server never sees an image.

Try it

It's live, free, and no sign-up: https://faceruler.com — one photo, on-device, and you get the full breakdown including the exact formulas behind every number.

If you're building something similar — client-side ML, or a privacy-sensitive tool where "we don't upload it" is the whole pitch — I'd love to hear how you handled the trust story.

I built a free image upscaler on Cloudflare Workers — here's what bit me

PENG YONG — Thu, 17 Sep 2026 15:52:45 +0000

I kept running into the same annoyance: screenshots that arrive looking like LEGO, photos that get crushed by messaging apps, and every "fix" behind a signup wall or a subscription. So I built unpixelate.net — upload a pixelated or blurry image, get a sharper one back in seconds. No account, no credit card.

This post isn't a product tour. It's the stuff that actually cost me debugging time: an AI inference API with three hidden traps, a math bug that would have made my own marketing a lie, and a storage quirk where a legal promise ("we delete your images") can silently die while everything returns HTTP 200.

The stack

Next.js 16 (App Router) on Cloudflare Workers via @opennextjs/cloudflare
R2 for image storage (zero egress fees — this matters later)
D1 for billing state, because credits need transactions
Replicate for inference: prunaai/p-image-upscale as the workhorse, Topaz's image-upscale as the paid HD engine
Zero runtime dependencies in the integration layer — the Replicate client and the AWS SigV4 implementation are both hand-rolled on fetch and node:crypto

Why no SDK for Replicate? The client is ~200 lines, and I wanted every header and timeout visible in code review rather than buried in a dependency. This turned out to be the right call, for reasons you'll see.

Trap #1: three things the Replicate docs make non-obvious

A naive client "works" in testing and then fails in production in three separate ways.

1. POST /v1/predictions has no model field. The owner/name shorthand only works for official Replicate models, through a different endpoint. For community models you must send the full 64-character version id. Pin it, and expose a resolveLatestVersion() helper so drift is visible instead of silent:

const created = await fetch("https://api.replicate.com/v1/predictions", {
  method: "POST",
  headers: {
    authorization: `Bearer ${token}`,
    "content-type": "application/json",
    // Blocks for up to 60s server-side — usually returns a finished
    // prediction and the polling loop never runs.
    prefer: "wait=60",
    // Bounds what we're billed for if this process dies mid-prediction.
    // The API enforces a 5s floor on this header.
    "cancel-after": "300s",
  },
  body: JSON.stringify({ version, input }), // version, NOT model
});

2. Output URLs require your auth header. Results are served from replicate.delivery, and a bare fetch(outputUrl) can 401. Every tutorial forgets this. You must send the same bearer token when downloading the result.

3. Predictions are deleted after about an hour. Inputs, outputs, logs — gone. You cannot store the output URL and fetch it later from a queue consumer. The bytes must be copied somewhere durable during the same request that polls them:

// After the prediction succeeds, immediately pull the bytes down
// with a hard ceiling, then upload to R2 ourselves.
const res = await fetch(outputUrl, {
  headers: { authorization: `Bearer ${token}` },
  signal,
});
const chunks = [];
let size = 0;
for await (const chunk of res.body) {
  size += chunk.length;
  if (size > MAX_DOWNLOAD_BYTES) throw new Error("output over ceiling");
  chunks.push(chunk);
}

That ceiling matters on Workers, where memory is capped and a runaway download shouldn't take the isolate down with it.

Trap #2: the 4-megapixel promise

The marketing page says "up to 4 MP output." Sounds like the model's job, right? Ask for 4 megapixels, ship it.

Wrong. The model has two upscale modes and neither does what the label says. I measured against the live API:

source	mode	asked	got	actual MP	ratio
1400x1050	factor	1.65	2308x1732	3.997	0.9987
1600x900	factor	1.65	2640x1484	3.918	0.9994
1400x1050	target	4	—	4.189	1.0473
1600x900	target	3	—	3.144	1.0480

target mode overshoots by ~4.8%, and its schema is an integer, so you can't trim it with a fractional value — the API rejects that with a 422. factor mode lands within 0.2% of what you asked for. So every viable plan uses factor, computed backwards from the budget:

// Aim 1% under the cap. The model rounds output dimensions, so asking
// for exactly 4 MP can land a fraction ABOVE it — which would make the
// advertised "up to 4 MP" claim false. The headroom is free.
const TARGET_MARGIN = 0.99;

export function planUpscale({ sourceMp, maxOutputMp = 4 }) {
  const budget = maxOutputMp * TARGET_MARGIN;
  const ideal = Math.sqrt(budget / sourceMp);
  const factor = Math.min(8, Math.max(1, Number(ideal.toFixed(2))));
  return { mode: "factor", factor };
}

There's a second, quieter decision in there: if the source is already at or above the cap, we reject before spending the user's credit instead of silently handing back a smaller image than they uploaded. "Your input is too big" is a better answer than a silent downgrade.

The pixel art exception

One more wrinkle in that planner. For most images, inventing detail is the product. For pixel art, inventing detail is always wrong — the art is a grid, and the only correct result is that same grid, larger. But the cap-fitting math happily asks for ~8x on a small sprite, and past roughly 8x the model starts hallucinating pixels.

So callers that know the input is pixel art pass an explicit factor: 4 and get exactly 4x. Small special case, but it's the difference between "this tool gets pixel art" and "this tool ruins pixel art" in a screenshot.

Why everything is PNG (and why R2 makes that free)

The default output format is PNG, deliberately. The model synthesizes pixels; re-encoding those to JPEG throws away detail we just paid for. On most hosts, storing larger files also means paying egress every time someone downloads a result — but R2 charges zero egress, so the bigger file costs storage only. This is one of those architecture decisions that's only obvious in retrospect: the storage pricing shaped the image quality policy.

Trap #3: the privacy promise that dies at HTTP 200

The privacy policy promises uploads and results are deleted after at most 14 days. Enforcing that is a cron that sweeps two R2 prefixes (in/ and out/). Boring code — except for one landmine:

S3's DeleteObjects answers HTTP 200 even when individual keys fail to delete. If you only check the status code, the cron logs "success" every night while a growing pile of expired images survives forever. A legal promise, silently broken, with nothing in the logs.

So the retention function collects every per-key failure instead of throwing on the first one, and the callers decide how to escalate:

// Returns { removed, failed } — never trust the HTTP status alone.
const { removed, failed } = await runRetention({ client, days: 14 });
if (failed.length > 0) process.exitCode = 1; // cron invocation shows as failed

I also merged the prefix list into a single module after noticing the local prune script and the Worker cron each held their own copy. That's the exact shape of bug a legal promise dies from: add a third storage prefix, update one caller, and the other silently stops covering it — with no error anywhere.

What I'd tell my past self

Pin model versions and log version drift. "Latest" is not an API contract.
Measure what the model actually returns, not what the schema says. The table above is 15 minutes of curl that saved the honesty of the landing page.
Anytime a legal promise ("we delete after N days") depends on a cron, simulate a partial failure and check that someone notices.
Zero-dependency integration modules are testable against live APIs with no mocking layer, and on Workers, small is a feature.

Try it

The site is live at unpixelate.net — free to start, no signup, JPG/PNG/WEBP. One honest caveat that's on the site too: the AI estimates missing detail. It's a reconstruction, not a forensic restore — a heavily pixelated face won't come back looking exactly like the real person. For screenshots, compressed photos, and text that went soft, though, the difference is night and day.

If you've shipped AI features on Workers, I'd love to hear what bit you — especially around long-running inference on a platform built for short requests. My current answer is Prefer: wait plus a bounded poll, but I don't love it.

I Built an AI Tool for Editing Text Inside Images

PENG YONG — Mon, 07 Sep 2026 14:21:19 +0000

I built EditTextImage, a small AI tool for one specific task: replacing visible text inside an existing image.

The idea came from a familiar annoyance. You have a screenshot, poster, product graphic, or social image that is almost right, but one date, label, price, or typo needs to change. Recreating the asset in Photoshop or another design tool can take much longer than the actual change deserves.

So I wanted to make the workflow deliberately narrow:

Upload an image
Enter the text currently visible
Enter the replacement text
Generate and download the edited result

The goal is not to replace a design workflow. It is to help with small, practical text corrections while keeping the original layout, background, lighting, and typography as close as possible.

What it is useful for

Updating labels or callouts in product screenshots
Correcting dates, times, or sponsor information on posters
Refreshing e-commerce banners and social graphics
Adjusting prices or daily specials on menu boards
Fixing small copy mistakes without recreating an entire image

The editor supports JPG, PNG, and WebP files up to 10 MB. New accounts receive one free credit, and no credit card is required to try it.

A note on the limitations

This is AI-assisted image editing, so it is not magic. Results can need another attempt, especially when text is very small, highly decorative, curved, or tightly integrated with a complex background.

I would rather be clear about that than promise “pixel-perfect” output in every case. The tool works best when the requested change is focused and the original text is readable.

It is also not intended for misleading edits. Please do not use it for government IDs, official documents, currency, copyrighted work you do not own, or any image modification intended to deceive someone.

Why I kept it focused

There are already excellent full-featured image editors. I did not want to build another large creative suite with dozens of controls.

Instead, I wanted to test whether a constrained workflow could reduce the friction of a very common request: “Can we just change this text?”

The product uses AI image editing to handle the visual adjustment, while the interface asks for the original wording and the replacement text to keep the edit specific.

You can try it here: edittextimage.net

I am still improving the result quality and the overall workflow. Honest feedback is especially useful: which image types work well, which ones fail, and what would make this genuinely useful in your day-to-day work?

I Built a Simple Tool to Remove Matcha Filters from Photos

PENG YONG — Fri, 14 Aug 2026 13:08:09 +0000

Hi dev.to community,
I recently built a small web tool called Remove Matcha Filter:
https://removematchafilter.org
The idea is simple: many photos look overly green, soft, or tinted after using a “matcha” style filter. This tool helps remove that color cast and bring the image closer to a cleaner, more natural look.

It is still a focused little project, not a huge product. My goal is to make it fast, easy to use, and useful for people who just want their original photo tones back without opening a heavy editing app.

If you have a photo with this kind of greenish filter, feel free to try it here:
👉 Remove Matcha Filter
I’d also appreciate any feedback on the result quality, UI, or wording. Thanks for taking a look.

I Built a Free NBA-Style Player Builder and Season Simulator

PENG YONG — Wed, 12 Aug 2026 12:49:34 +0000

I’ve been working on a small basketball web game called Build a Hooper.

You can try it here: https://buildahooper.app/

The idea is simple: instead of just picking one ready-made player, you build your own hooper piece by piece.

You spin historic teams, draft legendary players, take one skill from each of them, and then run your custom player through a full 82-game season simulation.

No signup is required to start playing.

Why I made it

A lot of basketball builder games are fun for a few minutes, but they usually stop at the draft card.

I wanted the build to matter after the picks were done.

So in Build a Hooper, the fun is not only “Can I make a stacked player?” but also:

Does this build actually win games?
Is it balanced enough for a full season?
Did I waste too many picks chasing scoring?
Can this player survive playoff-style pressure?
Would I build the same way next time?

That last part matters. I wanted each run to feel replayable, not solved after one try.

How it works

The main draft flow has 13 skill picks.

Each round gives you a team/player pool. You choose a player, then steal one skill from that player to add to your custom hooper.

After the draft, the site simulates an 82-game season and gives you a result based on the player you built.

There are also different draft modes:

Classic: you can see the ratings and make cleaner decisions.
Blind: ratings are hidden, so you have to trust names, roles, and instinct.
Chaos: the available skill board is limited each round, so you can’t always build the exact player you planned.

Classic is probably the best place to start. Blind and Chaos are more interesting once you already understand the system.

What you can try

If you want the fastest path, start here:

Play Build a Hooper

If you want to understand the rules first:

How to Play

There are also a few extra pages if you want to explore more:

What I’m still improving

This is an independent fan project, and I’m still tuning it.

A few things I’m thinking about:

making the simulation feel more transparent
improving the result page
adding more interesting achievement paths
making the leaderboard more fun to chase
balancing draft choices so there are fewer obvious picks

If you try it and something feels confusing, too easy, too random, or just not fun, I’d genuinely like to hear it.

The site is here:

https://buildahooper.app/

Thanks for checking it out.

I Built a Free Text Repeater Tool for WhatsApp – Here's What I Learned About SEO and Cloudflare Pages Deployment

PENG YONG — Tue, 31 Mar 2026 01:26:57 +0000

Why I Built This

A friend kept manually copy-pasting "sorry 🙏" over and over to send dramatic apology messages on WhatsApp. I watched him do it for about 30 seconds before thinking — this is a solved problem.

A few days later, TextRepeater was live.

It lets you type any text, set how many times to repeat it (up to 1000), pick a separator, add emoji scene modes, and apply 15 visual effects — all in the browser, no account, no backend.

The Stack

Deliberately simple:

Next.js 14 with output: 'export' (fully static)
Tailwind CSS for styling
Cloudflare Pages for hosting
GitHub Actions for CI/CD

No database. No API routes. No auth. Everything runs client-side.

Deployment: GitHub Actions + Cloudflare Pages Direct Upload

The interesting part was automating deployment. Cloudflare Pages has a GitHub App integration, but connecting it via API throws a cryptic error:

error code: 8000011 — There is an internal issue with your Cloudflare Pages Git installation.

This happens because the GitHub App OAuth flow requires browser authorization — it can't be done purely through the API.

The workaround: use Direct Upload mode instead of GitHub integration.

Step 1 — Create the Pages project via API (no `source` field)

curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/pages/projects" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "text-repeater",
    "production_branch": "main"
  }'

Step 2 — GitHub Actions workflow

name: Deploy to Cloudflare Pages

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci
      - run: npm run build

      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy out --project-name=text-repeater --branch=main

Every push to main triggers a full build and deploy. Zero manual steps.

Next.js Config for Static Export

For Cloudflare Pages to serve routes correctly:

// next.config.mjs
const nextConfig = {
  output: 'export',
  trailingSlash: true,   // important for Cloudflare routing
  images: {
    unoptimized: true,   // required for static export
  },
}

export default nextConfig

trailingSlash: true is the one that trips people up — without it, direct URL navigation breaks on Cloudflare Pages.

Custom Domain via Cloudflare API

After purchasing the domain, instead of clicking through the dashboard, I wired everything via API:

# 1. Bind domain to Pages project
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/pages/projects/text-repeater/domains" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"name": "textrepeater.top"}'

# 2. Add CNAME record (proxied = orange cloud enabled)
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "CNAME",
    "name": "textrepeater.top",
    "content": "text-repeater-9lr.pages.dev",
    "proxied": true
  }'

SSL certificate issued automatically within ~2 minutes.

SEO for a Static Next.js Site

Launching a new domain means starting from zero authority. Here's what I set up on day one:

1. Canonical URLs (every page)

export const metadata: Metadata = {
  alternates: {
    canonical: 'https://textrepeater.top/apology-mode/',
  },
}

Without this, search engines might treat http vs https or trailing slash variants as duplicate pages, splitting your ranking signal.

2. robots.txt

User-agent: *
Allow: /

Sitemap: https://textrepeater.top/sitemap.xml

Obvious but easy to forget on a static site.

3. sitemap.xml with lastmod

<url>
  <loc>https://textrepeater.top/</loc>
  <lastmod>2026-03-30</lastmod>
  <changefreq>weekly</changefreq>
  <priority>1.0</priority>
</url>

4. Open Graph + Twitter Card

openGraph: {
  type: 'website',
  siteName: 'TextRepeater',
  url: 'https://textrepeater.top',
  title: 'Text Repeater Online — Repeat Any Text Instantly',
  description: '...',
},
twitter: {
  card: 'summary',
  title: 'Text Repeater Online — Repeat Any Text Instantly',
  description: '...',
},

5. JSON-LD Structured Data

For the homepage:

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify({
      '@context': 'https://schema.org',
      '@type': 'WebSite',
      name: 'TextRepeater',
      url: 'https://textrepeater.top',
    }),
  }}
/>

For tool pages, use WebApplication with offers.price: '0' — this can show a free badge in rich results.

The "Scene Mode" Idea

The differentiator I'm most proud of is Scene Modes — instead of just repeating text, you pick a context (apology, birthday, anger) and the tool automatically inserts themed emoji patterns throughout your message.

Input:  "I'm really sorry"
Output: "🙏 I'm really sorry 😔 I'm really sorry 💦 I'm really sorry 🥺"

It maps to specific long-tail keywords like "apology text generator" and "sorry message generator for WhatsApp" — much lower competition than "text repeater" alone.

Each Scene Mode is its own page with targeted metadata, giving the site multiple entry points for organic traffic.

What's Next

Completing the remaining Scene Modes (Heart, Anger, Birthday, Like)
Adding more WhatsApp-specific templates
Tracking which visual effects actually get used

Try It

textrepeater.top — free, no sign-up, works on mobile.

If you're building something similar (static Next.js + Cloudflare Pages), the Direct Upload + GitHub Actions approach is the smoothest path I've found. Happy to answer questions in the comments.

DEV Community: PENG YONG

I built a face-rating tool that never sees your photo — here's what I learned about on-device ML

Why I Built This

The Stack

The scoring is just math (that's the point)

Two things that were harder than they look

The front-end bug that ate a whole evening

What's Next

Try It

Your photo never leaves the browser — building a client-side face analysis app with MediaPipe

Why on-device at all

The pipeline: detect → measure → map

The scoring engine is just math (that's the point)

Four things that were genuinely hard

Front-end lessons that cost the most hours

Stack

Try it

I built a free image upscaler on Cloudflare Workers — here's what bit me

The stack

Trap #1: three things the Replicate docs make non-obvious

Trap #2: the 4-megapixel promise

The pixel art exception

Why everything is PNG (and why R2 makes that free)

Trap #3: the privacy promise that dies at HTTP 200

What I'd tell my past self

Try it

I Built an AI Tool for Editing Text Inside Images

What it is useful for

A note on the limitations

Why I kept it focused

I Built a Simple Tool to Remove Matcha Filters from Photos

I Built a Free NBA-Style Player Builder and Season Simulator

Why I made it

How it works

What you can try

What I’m still improving

I Built a Free Text Repeater Tool for WhatsApp – Here's What I Learned About SEO and Cloudflare Pages Deployment

Why I Built This

The Stack

Deployment: GitHub Actions + Cloudflare Pages Direct Upload

Step 1 — Create the Pages project via API (no source field)

Step 2 — GitHub Actions workflow

Next.js Config for Static Export

Custom Domain via Cloudflare API

SEO for a Static Next.js Site

1. Canonical URLs (every page)

2. robots.txt

3. sitemap.xml with lastmod

4. Open Graph + Twitter Card

5. JSON-LD Structured Data

The "Scene Mode" Idea

What's Next

Try It

Step 1 — Create the Pages project via API (no `source` field)