DEV Community: neo xia

Why marketplace product photos get rejected: white-background image requirements, and a 1-minute browser fix

neo xia — Sun, 04 Oct 2026 16:00:57 +0000

If you sell on marketplaces — Amazon, Shopify, Etsy, app stores, or any product directory — you have probably had a listing image rejected or down-ranked for one reason: the background.

Disclosure: I build CleanWhiteBG, a free browser tool for exactly this problem. This post explains the requirements themselves; the tool is one way to hit them. No signup, no watermark, and images never leave your device.

Why "white background" is a hard requirement

Most marketplaces normalize their catalog grids around a consistent look. A white (or pure transparent) background lets them:

Composite your photo into any layout — tiles, carousels, comparison tables — without visible seams.
Pass automated checks: several pipelines measure background uniformity and reject images with busy or colored backgrounds.
Keep perceived quality high: studio-white reads as "professional" at thumbnail size, where most buying decisions happen.

What the requirements usually say

The wording varies, but the checks look like this:

The product fills 80–90% of the frame.
The background is pure white (#FFFFFF) or transparent PNG.
No watermarks, logos, or inset text on the image.
Sharp edges — no halo or color fringing left behind by a bad cutout.

Point 4 is where DIY jobs fail: a tolerance-based "magic wand" removal leaves gray fringes around hair, glassware, or jewelry, and reviewers (human or automated) notice.

The 1-minute fix in the browser

Open https://cleanwhitebg.com
Drop the product photo in (nothing is uploaded — it runs locally in your browser via WebGPU/WASM).
Pick the mode: Fast for everyday shots, Precision for complex edges like hair or jewelry.
Download the flattened white-background PNG and upload it to the marketplace.

Because the processing is local, it also works for images you would rather not upload to a cloud service — product shots under NDA, unreleased packaging, client work.

Checklist before you re-upload

[ ] Product fills the frame, centered
[ ] Background is exactly #FFFFFF (pick the white-flatten option, not transparent)
[ ] Zoom to 200% and check edges for fringing
[ ] No leftover watermark from stock previews

That is the whole loop. If you batch 50 SKUs a week, the difference between a 5-minute-per-image desktop workflow and a 30-second browser one adds up fast.

Feedback welcome — especially edge cases where the cutout struggles (glass, fur, reflective packaging).

Four Marketplaces, One Listing Workflow: What Amazon, eBay, Etsy and Shopify Expect From Your Copy

neo xia — Sat, 03 Oct 2026 19:38:42 +0000

If you sell on more than one marketplace, you already know the copy you write for Amazon doesn't survive a trip to Etsy. Same product, different rules — and the rules are not cosmetic.

I build listing tools for a living, and here's the cheat sheet I wish someone had handed me before I rewrote the same SKU four times.

What each platform actually expects

Amazon — Titles get truncated hard on mobile, and Rufus surfaces content that answers buyer questions directly. Front-load the searchable keywords; save the adjectives.

eBay — Title length is capped at 80 characters, and buyers filter by item specifics. Condition-forward descriptions reduce disputes.

Etsy — Buyers respond to the maker story and materials. Tags are multi-word phrases, and the tone is handmade, not corporate.

Shopify — Your own brand voice applies, and the most common failure is shipping the manufacturer's thin spec sheet as a product description.

Why paste-reformatting breaks down

The usual loop looks like this: ask a general AI writer for copy, paste the answer into the marketplace form, then fix the character limit, reorder the bullets, rewrite the description, and swap images by hand. Every SKU repeats the loop, and the loop scales with your catalog.

What we built instead

AI Product Page Optimization is a Chrome extension that reads the live listing page you already have open, detects which marketplace you're on, and generates copy that respects that platform's rules. One install covers Amazon, Shopify (including custom domains), eBay, and Etsy. Optional image enhancement runs in the same pass, and results land on a review dashboard so nothing publishes until you approve it.

Pricing facts

Text optimization costs 1 credit; successfully enhanced images cost 2. New accounts get 5 free credits, no card required. Subscriptions start at $19.9/month.

If you manage listings across channels: which platform's rules eat most of your time? Comments are open.

Ship an Editor, Not a Generator: Designing Review-First AI for Marketplace Listings

neo xia — Fri, 02 Oct 2026 19:25:32 +0000

Most AI writing tools optimize for one moment: the instant text appears. But for marketplace sellers, that moment is the least important part of the workflow. What matters is everything after — reading the suggestion, comparing it to the original, and deciding what actually goes live on Amazon, Shopify, eBay, or Etsy.

That gap is why we built AI Product Page Optimization around an editor, not a generator.

The trust problem with generated text

A generated title is a guess. A reviewed title is a decision. Sellers don't publish what an AI writes — they publish what they approve. So the core UX question isn't "how good is the model?" but "how fast can a seller judge the output?"

Our answer: every optimization run lands on a web dashboard as a before/after comparison. Original on one side, suggestion on the other. The seller edits, accepts, or discards. Nothing touches the listing until a human says so.

The loop: extract → draft → review → publish

The Chrome extension reads the live product page the seller already has open — Amazon, Shopify (including custom domains), eBay, or Etsy — using structured data plus platform-specific selectors. The AI drafts rewrites that respect each channel's constraints: Amazon's mobile truncation, eBay title length, Etsy's handmade tone, Shopify brand voice.

Then control moves to the dashboard:

Before/after comparison for every field
History of past runs, reusable across SKUs
Optional public share links for team feedback

Paste-ready output, human-approved.

Why the same pass handles images

Copy alone rarely fixes a weak listing. The same run can enhance product photos or swap backgrounds — and keeping the original image is free. That pricing detail matters more than it sounds: it makes "do nothing" a legitimate choice, which keeps the review loop honest.

What we learned

Constraints are features. Character limits and platform tone rules make suggestions more useful, not less — they turn generated text into paste-ready text.
Review speed beats generation speed. A suggestion that takes 30 seconds to judge is worth more than three alternatives that take 10 minutes to compare.
History turns AI output into an asset. Sellers who can reopen last month's runs stop treating AI as a slot machine.

If you sell across marketplaces and want to see the review-first flow yourself, the extension is free to try — 5 credits on signup, no credit card: https://aiproductpageoptimization.com

Reading any marketplace product page from a Chrome extension: JSON-LD first, selectors second

neo xia — Thu, 01 Oct 2026 19:35:47 +0000

If you have ever tried to build a tool that "reads" a product page — an Amazon listing, a Shopify storefront, an eBay item, an Etsy shop page — you already know the problem: every marketplace renders the same conceptual data (title, bullets, description, images, price) in completely different DOM shapes.

We ran into this while building AI Product Page Optimization, a Chrome extension that reads the product page you already have open and returns marketplace-ready title, description, and image suggestions in about 30 seconds. This post is the technical breakdown of how the reading step works. (This article is disclosed as AI-assisted; the extraction design and constraints below are from our actual implementation.)

Start with JSON-LD, always

Most marketplaces embed structured data in the page. Before touching a single DOM selector, we look for application/ld+json blocks and parse them for Product-shaped objects:

const ldjson = Array.from(
  document.querySelectorAll('script[type="application/ld+json"]')
).map((s) => {
  try { return JSON.parse(s.textContent); } catch { return null; }
}).filter(Boolean);

Why JSON-LD first:

It survives layout changes. Amazon can reshuffle its DOM next week; the Product schema block rarely moves.
It normalizes the shape. A title is a name, images are an image array, and offers carry price/currency regardless of which marketplace you are on.
It handles encoding edge cases (HTML entities, unicode in internationalized catalogs) better than regex-over-HTML ever will.

But JSON-LD is never the whole story. Marketplaces routinely put richer or more current data in the DOM than in their structured data: bullet points that are not in any schema field, variant-specific copy, A/B-tested titles.

Selectors as a scoped fallback

After JSON-LD, we apply platform-specific DOM selectors to fill the gaps — and the key word is scoped: we detect the marketplace from the URL first, then load only that platform's selector set.

The four surfaces we read today:

Amazon — deep, nested DOM with frequent class-name churn; stable attributes and landmark patterns beat styling hooks
Shopify (including custom domains) — the most uniform target; Shopify themes share enough structure that extraction is reliable even on stores with custom themes
eBay — item-specific layouts where the description block is seller-authored HTML, which changes the parsing strategy entirely
Etsy — listing copy with a distinct handmade/creative tone that also matters downstream for generation

Constraints matter more than extraction

Reading the page is half the job. The other half is knowing what each marketplace will accept when you write the optimized copy back:

Amazon truncates aggressively on mobile — character limits are hard product constraints, not suggestions
Shopify storefronts often carry thin manufacturer text that needs brand-voice cleanup rather than keyword stuffing
eBay titles have a hard length cap, and condition-forward descriptions convert better
Etsy rewards handmade-tone phrasing with stronger search phrases — generic copy reads as dropshipping

One more detail that surprised us: output language follows the detected page language. Cross-border catalogs mix English with other locales, and returning English suggestions for a Japanese listing page is worse than useless — it breaks the seller's workflow.

MV3 practicalities

Two things worth knowing if you build this on Manifest V3:

The extraction needs to run in the page context (JSON-LD and DOM both), so your content script is the workhorse; the service worker only orchestrates.
Keep the extension stateless about page data — read the live page on demand, send only what the user approves onward. It keeps you compatible with platform policies and keeps the data footprint small.

Review before publish

We deliberately never auto-paste anything. Extracted data and generated suggestions land on a web dashboard with a before/after comparison, history, and optional share links — the seller copies and publishes only what they approve. Optimization is credit-based (text 1 credit, AI-enhanced image 2, keeping an original image is free; a typical product page uses about 5 credits, and new accounts start with 5 free credits).

If you are building anything that reads product pages — price trackers, feed tools, listing optimizers — the pattern is the same: structured data first, scoped selectors second, platform constraints third, and a human review step before anything goes back to the marketplace.

Try the extension: aiproductpageoptimization.com

Rehearse the conversations you dread: what building an AI practice simulator taught me

neo xia — Wed, 30 Sep 2026 17:46:17 +0000

Most of us prepare for big conversations by... not preparing. We rehearse a few lines in our heads, maybe mutter them in the shower, then walk into the meeting and freeze.

I built cosskill to fix that. It's an AI communication simulator: you rehearse high-stakes conversations — salary negotiations, performance feedback, difficult personal talks — by actually talking with realistic AI personas before they happen.

What practicing looks like

Pick a scenario: asking for a raise, delivering hard feedback, saying no to your boss, or an entirely personal one.
The AI plays the other person. It pushes back, changes tone, and asks the questions you're afraid of.
You talk it through, out loud, then look back at what worked and where you got stuck.

Three things I learned building and using it

Rehearsal beats research. Reading ten articles about negotiating doesn't help much when the other person says "we'll see." Practicing your counter-move does. A simulator gives you the counter-move.

The second attempt is where the skill is. The first run through a scenario is rough. By the third replay the rhythm changes — you stop defending and start steering. That's the whole point of practice.

Saying it out loud matters. Typing an argument is easy. Speaking it to an AI boss that interrupts and pushes back is a different skill — and the one you actually need in the room.

Try it

cosskill is free to try: a few messages without an account, more after sign-in, all personas and scenarios included. Unlimited use is on Pro.

If you have a hard conversation coming up, rehearse it first at cosskill.com. Two of our guides go deeper: how to ask for a raise and how to give negative feedback.

How We Built an AI Listing Optimizer for Amazon, Shopify, eBay & Etsy (Chrome Extension Architecture)

neo xia — Tue, 22 Sep 2026 19:46:39 +0000

Multi-channel sellers live in a painful loop: copy a listing into ChatGPT or Jasper, get decent text, then spend another 20 minutes reformatting it for Amazon's character limits, eBay's title rules, or Etsy's story style — per SKU, per channel. Amazon-only tools don't follow them to Shopify. Generic AI writers ignore marketplace rules.

We built AI Product Page Optimization to close that gap, and this post walks through how it works and the architecture behind it.

The core idea: run on the live page

Instead of another dashboard with CSV imports, the tool is a Chrome extension that runs on the product page you already have open. It:

Detects the marketplace from the URL (Amazon, Shopify — including custom domains, eBay, Etsy)
Extracts title, bullets, body copy, and images using structured data (JSON-LD) plus platform-specific DOM selectors
Generates rewrites that respect each channel's constraints
Returns results to a web dashboard for before/after review before anything is published

A typical run takes about 30–60 seconds per product page.

Platform-aware rules, not generic copy

The interesting part isn't the LLM — it's the constraints we bake in:

Amazon: mobile truncation limits and Rufus-friendly phrasing
Shopify: brand-voice cleanup for thin manufacturer text
eBay: title length limits and condition-forward descriptions
Etsy: handmade tone with stronger search phrases

Output language follows the detected page language, which matters for cross-border catalogs that mix locales.

Architecture

Extension: Manifest V3, dynamic script injection for live-page extraction
Web app: Next.js, React, Tailwind CSS
Backend: Cloudflare Workers, D1 (SQLite), R2 for image storage
AI: LLMs for copy optimization; image models for enhancement or background changes (keeping the original image is free)
Auth & billing: Google sign-in or email magic link; Creem for subscriptions and credit top-ups

Pricing model

Text optimization costs 1 credit; successfully enhanced images cost 2. A typical product page uses about 5 credits. New users get 5 free trial credits with no credit card required; paid plans start at $19.9/month.

If you sell on any of these marketplaces and want to try the workflow: https://aiproductpageoptimization.com

Feedback welcome — especially from anyone who maintains listings across multiple platforms.

I built an AI simulator for the conversations people avoid

neo xia — Tue, 22 Sep 2026 17:43:48 +0000

The hardest conversations in your life don't get retries. A salary negotiation, critical feedback to a teammate, a breakup, telling your boss you're quitting — you get one take, live, with a real person whose reaction you can't control.

So most of us rehearse in the shower, say the wrong thing anyway, and then spend weeks replaying it.

I kept running into this problem as a founder, so I built cosskill: an AI communication simulator where you rehearse high-stakes conversations with realistic AI personas before they happen. This post is about what the product does, and what I learned building it — including the parts that surprised me.

What rehearsing actually looks like

You pick a scenario (negotiate a raise, deliver negative feedback, end a relationship, quit gracefully), pick a persona, and talk. You can type or speak. The AI doesn't roleplay a pushover — it pushes back, interrupts, gets defensive, and responds like an actual person would.

Then you get an evaluation of the conversation: what landed, what didn't, and how it moved. You can rewind to any point and try the moment again — including the hardest 30 seconds.

There are 20 personas across operators, strategists, philosophers, and psychologists, plus a mission mode with live meters that track how the conversation is going.

Pricing, plainly: it's free to try — 3 messages without an account, 10 after signing in, with all personas and scenarios available. Pro is $12.90/month or $129/year for unlimited.

Three things building it taught me

1. A roleplay bot that agrees with you is useless

Early versions were too polite. The "other side" folded too easily, and practicing against it trained avoidance, not skill. The single biggest product decision was making personas that genuinely push back. If your rehearsed opener survives a realistic counterparty, it'll survive a real one — or at least you'll know what the counter-move looks like.

2. The rewind is the feature

Live conversations don't have undo. That's exactly why practice should. Being able to redo the worst moment of a conversation — immediately, with a persona that reacts differently each time — is where most of the learning happens. Repetition builds fluency; fluency is what keeps you articulate when you're actually nervous.

3. Feedback has to be concrete

"You did great!" is worthless. The evaluation had to name specific moves: you opened with an apology that undercut your ask; you stated your number once and then kept talking; you de-escalated a personal attack without conceding the point. Concrete diagnosis is what you can act on in the retry.

A 10-minute rehearsal you can do today

Pick the conversation you've been avoiding.
Write down your ask in one sentence, with your number/decision stated once.
Run the scenario with a persona that will push back.
When it goes sideways, rewind and redo that moment — don't restart the whole thing.
Read the evaluation, adjust one thing, run it once more.

If you want a deeper framework, we published free guides like How to Have a Difficult Conversation and How to Negotiate Your Salary.

Honest limits

An AI persona is not your manager, your partner, or your teammate. It can't predict how a specific person will react, and it shouldn't be a substitute for real advice on legal, medical, or financial decisions. What it can do is take the edge of panic off — you walk into the real conversation having already heard the pushback, so you're responding instead of improvising.

That's the whole bet: fluency comes from rehearsal, and hard conversations deserve a rehearsal.

If you try it, I'd genuinely like to hear what the AI pushed back with — that's the part we iterate on fastest.

cosskill: https://cosskill.com — free to try, no account needed for the first few messages.

White or Transparent? A Practical Guide to Product Image Backgrounds

neo xia — Sun, 20 Sep 2026 03:14:32 +0000

Most product grids don't look broken because of bad photography. They look broken because the backgrounds don't agree with each other.

One card with a warm beige backdrop in a row of pure-white cards reads as a mistake, even when that photo is technically the better shot. Designers tend to blame the layout. The layout is usually fine. The background is the variable nobody specified.

This guide covers what the major platforms actually require, when transparent beats white, and a checklist you can hand to whoever produces the images.

Why background choice is a layout decision

A product grid is a repeated component. Its visual rhythm depends on every cell sharing the same visual weight, and background colour is one of the strongest contributors to that weight.

Three things break the rhythm:

Mixed backgrounds. Lifestyle, studio-grey, and pure-white images in one row. Each is fine alone; together they look unplanned.
Mixed crops. A product that fills 60% of one frame and 90% of the next makes the grid look like it has two different paddings.
Mixed colour temperature. White balance drift across a photo set reads as inconsistent backgrounds even when every image is nominally "on white".

None of these are solved in CSS. You can letterbox, crop, or apply a filter, but you cannot recover a consistent background from inconsistent source images. The decision has to happen before the asset reaches the component.

That is the useful reframe: a white background is a specification, in the same way a spacing scale or a type ramp is. It belongs in the design system, not in a photographer's judgement call.

What the platforms actually require

If your product appears on a marketplace, the specification is not yours to choose.

Amazon requires main images on a pure white background — RGB 255, 255, 255 — with the product occupying 85% of the frame. Amazon states the reason directly: a consistent background gives buyers a consistent experience across search results and detail pages.

Google Merchant Center is slightly more permissive but adds a trap worth knowing. Its image link guidance says to "use a solid white or transparent background", noting that these ensure the image "works with a variety of design elements", and that staged or lifestyle images which clearly show the product are also acceptable.

Then comes the note that catches people out:

Don't use a transparent background for images with light colors because they might show with a black background.

That single sentence explains a whole class of bug reports. A transparent PNG of a white ceramic mug looks correct in a design tool with a light canvas and disappears into a dark-mode card. Google is also tightening image size requirements: at least 500 x 500 pixels for all products from January 31, 2027, with 1500 x 1500 or above recommended for best performance.

The practical takeaway is that "white" and "transparent" are not interchangeable defaults. They are two different specifications that suit different surfaces.

White or transparent: choosing per surface

Use this as a decision rule rather than a preference.

Choose white when:

The image will appear on a marketplace listing or shopping feed.
The image sits in a grid alongside other products.
The product itself is light-coloured and needs a defined silhouette.
The image may be shared, screenshotted, or reposted somewhere you don't control.

Choose transparent when:

The image sits on a known, controlled background colour that you can guarantee.
The product is dark or mid-tone, so it will never vanish into a light surface.
The asset is a UI element — an icon, a badge, a floating product in a hero section.
You genuinely need it to composite over more than one background.

Avoid transparent when the product is white, cream, pale grey, or glass. This is the case Google's note warns about, and it is common in homeware, ceramics, cosmetics, and packaging.

If you need both, generate both. Producing a white-background master and a transparent derivative from the same source image is cheaper than re-shooting later, and it removes the temptation to use one asset in the wrong place.

A checklist for a consistent grid

Hand this to whoever produces or edits the images.

Define the background value once. If you are not bound by a marketplace, pick a single value — pure white or a specific light neutral — and write it down.
Check the actual pixels, not the impression. Sample a corner of each image. A set that "looks white" often contains several different values.
Standardise the product's share of the frame. Match the ratio across the set so the grid has even optical padding.
Normalise colour temperature across the batch. Correct the set together rather than image by image.
Export both masters. Keep a white-background version and a transparent version at the largest size you need.
Test the transparent version on a dark surface before shipping it. This is the step that catches the disappearing-mug bug.
Name files by variant. A predictable suffix for background and size saves an enormous amount of guesswork later.

Conclusion

The background of a product image is a design token that happens to live in a bitmap. Treating it as one — with a defined value, a defined crop ratio, and a defined set of exports — removes the most common source of visual noise in product grids, and it keeps you compliant with the marketplaces that enforce their own specification.

Transparent is not more sophisticated than white, and white is not lazier than transparent. They are two specifications for two different surfaces. The mistake is not choosing; it is leaving it unspecified.

Disclosure: I build CleanWhiteBG, a free tool that replaces an image background with white in one click. It is one way to produce the white-background master described above; the checklist stands on its own regardless of which tool you use.

FAQ

Is a white background better than a transparent one for product photos?

It depends on the surface. Marketplaces such as Amazon require pure white for main images, while Google Merchant Center accepts either solid white or transparent. For grids and feeds, white is the safer default because it is self-contained; transparent only works reliably when you control the background it will sit on.

Why does my transparent PNG look wrong in dark mode?

Because there is nothing behind the product. A transparent image inherits whatever is underneath it, so a light-coloured product can lose its edges against a dark card. Google's Merchant Center guidance flags exactly this risk. Export a white-background version for any surface you do not control.

What resolution should product images be?

Google Merchant Center requires at least 500 x 500 pixels for all products from January 31, 2027, and recommends 1500 x 1500 pixels or above for best performance across listing formats. Amazon requires the product to occupy 85% of the frame, so start from a larger master and crop rather than upscaling a small file.

We put an ONNX background-removal container behind a Next.js Worker on Cloudflare

neo xia — Thu, 17 Sep 2026 04:48:33 +0000

We put an ONNX background-removal container behind a Next.js Worker on Cloudflare

Disclosure: I build CleanWhiteBG, the tool described here. This post is about the infrastructure, not a pitch — every number below comes from the running code.

Background removal looks like a one-liner in a demo: load an image, run a segmentation model, get a mask. In production it turns into a queueing problem, a cold-start problem, and a "why is my Worker crashing with error 1101" problem.

Here is what our stack actually looks like after a few rounds of getting it wrong.

The constraint that shapes everything: 30 seconds of CPU

Cloudflare Workers give you a hard CPU budget per invocation. We set ours to 30,000 ms in wrangler.jsonc:

"limits": { "cpu_ms": 30000 }

On top of that, waitUntil does not buy you a background thread that can run for a minute. Work that outlives the response is not reliable work. So you cannot simply accept an upload, run a 10-second inference in the background, and return 202 Accepted with a promise to email the user later.

Our answer was to split the pipeline so that the expensive part runs inside a request the client is still holding open, and the client drives the state machine.

Submit, then poll

POST /api/tool/background-to-white does almost nothing:

Check the per-IP rate limit.
Parse the multipart body.
Validate the MIME type (JPEG, PNG, WebP) and a 10 MB size ceiling.
Write the original to R2.
Create a job row in D1 and return the jobId.

That round trip is about a second. The actual inference happens later, when the client polls GET with that job id. The first poll that "claims" a queued job is the request that actually runs the container inference, with a long-poll budget of 20 seconds and a 3-second client interval.

It is a slightly unusual shape — the work happens in the GET, not the POST — but it means every request stays inside its CPU budget, and a dropped client connection just leaves the job to be reclaimed later.

Cold starts: loading a model while the health check is watching

The "Fast Cloud AI" path runs BiRefNet-lite exported to ONNX, served by ONNX Runtime on CPU inside a Cloudflare Container.

The container is a python:3.12-slim image with the model baked in at build time:

RUN pip install --no-cache-dir onnxruntime==1.21.1 Pillow==11.0.0 numpy==2.2.6 flask==3.1.1 gunicorn==23.0.0
RUN pip install --no-cache-dir huggingface_hub==0.34.4 && \
    python3 -c "from huggingface_hub import hf_hub_download; hf_hub_download(repo_id='onnx-community/BiRefNet_lite-ONNX', filename='onnx/model.onnx', local_dir='/app/models')"

Two decisions here matter more than they look.

First, the model is in the image, not fetched at boot. Pulling it from Hugging Face on every cold start adds seconds you cannot control and a failure mode you cannot fix at 2 a.m.

Second, gunicorn binds the port before the model finishes loading. If you load the model in the module body, the HTTP port stays closed while ONNX Runtime reads weights, and the platform's health check fails before your service ever answers. Instead we load it in a background thread and have requests wait:

session = None

def load_model_async():
    global session
    session = ort.InferenceSession("/app/models/birefnet_lite.onnx",
                                   providers=["CPUExecutionProvider"])

def ensure_model(timeout: float = 60.0):
    # block until the background load finishes, retry synchronously once on timeout
    ...

The port is ready in milliseconds, health checks pass, and the first real request just waits a little longer.

Even so, a genuinely cold container means pulling the image, starting the process, and loading the model — we measured that in the low tens of seconds. That is far too slow to sit behind a user's click.

So we hide it: the tool page pings GET /api/warm when it mounts and when the user starts choosing a file. That call is idempotent — it asks the Durable Object to start the container and returns immediately if it is already running. The cold start happens during the several seconds a human spends browsing for a photo, not after they hit submit.

The landmine: do not name an R2 binding `IMAGES`

This one cost us a production incident, so it is worth repeating.

OpenNext's /_next/image handler treats env.IMAGES as a Cloudflare Images binding and calls .input() on it. If you also have an R2 bucket bound as IMAGES, the runtime gets a bucket where it expects an image service, and the Worker dies with error 1101 — a crash, not a caught exception.

Our binding is therefore called R2_UPLOADS, with a comment in wrangler.jsonc so nobody "tidies" the name later:

{ "binding": "R2_UPLOADS", "bucket_name": "cleanwhitebg-images" },
{ "binding": "IMAGES" }   // Cloudflare Images binding for /_next/image — fixed name

The general lesson: binding names are part of the framework's API surface, not your namespace.

Not every edge needs the same model

A small ONNX model is fast and cheap and handles most photos. It is also visibly worse on the cases people actually care about — flyaway hair, jewellery, fur, anything translucent with a busy background.

Rather than run one big model for everything and pay for it on every request, we route on the quality parameter the user picked:

standard → the self-hosted BiRefNet-lite container, CPU, cheap, fast.
quality → pre-process only when needed (downscale beyond 2K, pad when the aspect ratio is extreme), then hand off to a larger hosted model and poll its progress.

Same API, same job table, two very different cost profiles. The user chooses the tradeoff, and we do not pay the expensive path for a passport photo that did not need it.

Cleanup is a cron, not a best-effort delete

Uploaded images are stored in R2 and the public promise is that they are gone within two hours. We do not rely on the request path to guarantee that. A Cron Trigger sweeps expired uploads every 15 minutes, and a second cron (every minute) resumes orphaned batch jobs:

"triggers": { "crons": ["*/15 * * * *", "* * * * *"] }

If cleanup only ran when a request happened to finish successfully, a crash would leave user images sitting in a bucket indefinitely. A cron makes the retention promise independent of traffic.

What I would tell someone starting today

Decide early whether your work fits in one request. If it does not, design the job table and the polling contract before you write the model code.
Load models in a background thread so health checks pass. A container that never becomes healthy is worse than a slow one.
Bake weights into the image. Network fetches at boot are a reliability tax with no upside.
Read the framework's binding names. IMAGES is taken.
Hydrate the expensive resource before the user needs it, during a gap where they are already waiting on something else.
Make retention a scheduled job, not a side effect.

The whole thing is a Next.js 16 app running through OpenNext on Workers, with D1 for job state, R2 for objects, and one Python container doing the segmentation. It is several moving parts — but each one is doing a job the others genuinely cannot.

FAQ

Why not run the ONNX model inside the Worker itself?
Workers do not ship a general-purpose CPU inference runtime for arbitrary ONNX models, and even if you got one working, the 30-second CPU ceiling and memory limits make it a poor fit for a 1024×1024 segmentation pass. A container gives us the real runtime and lets the Worker stay a router.

Why does the client poll instead of the server pushing?
Because the work is tied to a request's lifetime. Long-polling keeps the inference inside a request that is still open, which is the only place we can safely spend that CPU. A push model would need the work to outlive the response, which is exactly what we cannot rely on.

Is the inference running on a GPU?
No — CPU only, ONNX Runtime with CPUExecutionProvider. That is why the model is the "lite" variant and why the expensive edge cases are routed to a hosted model instead.

What happens if a user closes the tab mid-job?
The job stays in D1 in a claimed state. A stale-claim timeout lets a later poll or the batch cron reclaim it, so abandoned work gets cleaned up rather than stuck forever.

Next.js 16 on Cloudflare Workers: what broke and what didn't

neo xia — Wed, 22 Jul 2026 03:23:39 +0000

I shipped a Next.js 16 app on Cloudflare Workers via OpenNext. Not a demo. A real product with streaming chat, server components, D1 at the edge, and anonymous user sessions.

Here is what broke, what barely worked, and what turned out to be surprisingly fine.

The stack

Next.js 16.2 (App Router)
@opennextjs/cloudflare 1.19
D1 for SQLite at the edge
Streaming chat via the AI binding (DeepSeek-V3 through a Workers proxy)
React 19
Tailwind CSS 4
No auth wall, no OAuth, no database on the origin

The site runs a few thousand sessions a week across ~30 persona pages, blog posts, guides, and learning content. Most pages are statically generated. The chat interaction is server-rendered components with streaming responses.

What worked surprisingly well

Static generation and ISR

Pages, blogs, guides, persona pages — everything that does not need user-specific rendering — runs as static HTML at deploy time.

Next.js 16 with generateStaticParams and fetch caching worked without modification. OpenNext handles the Cloudflare output format. The build step produces something Workers can serve. Revalidations are limited to Workers' cache API, but since most content changes at deploy time, I never hit that limit in production.

The one caveat: revalidateTag() does not work the same way in a Workers runtime. Tags are Node.js memory constructs, and Workers are stateless. If you depend on tag-based revalidation for content updates, you need to either trigger deploys or accept stale-while-revalidate behavior from the CDN.

D1 at the edge

D1 was the least surprising part of the stack. SQL queries from Next.js route handlers feel like calling a regular database. Sessions store in D1, messages store in D1, and the latency is low enough that restoring a full chat thread from 30 messages takes under 200ms cold.

The only sharp edge: D1 connections count against your Worker's concurrent request limit in development. With Next.js making its own fetch calls for compilation, I hit the D1 connection ceiling faster than expected. The fix was moving wrangler dev to use --experimental-json-config early, but the dev experience for D1 + Next.js hot reload is still rougher than it should be.

Streaming chat responses

The app streams model responses token by token. In dev, this was unreliable — the stream would drop mid-response on roughly 1 in 15 requests. I spent two days tracing it before realizing it was a local wrangler dev issue with HTTP chunked transfer encoding, not a production problem.

In production, streaming over Workers works. The AI binding handles the model request inside the Worker, and the response streams back through the Next.js route handler to the client without a hitch.

Anonymous user sessions

The product ships without required sign-in. Users get a UUID from crypto.randomUUID() stored in localStorage, sent as X-User-Id on every chat request. On the server, D1 writes sessions against that ID.

Workers not having durable session state actually helps here. The identity arrives in headers. No sticky sessions. No session table. The Worker pulls the user ID, checks D1 for existing sessions or quota limits, and proceeds.

What broke

Middleware and edge runtime mismatch

Next.js 16 middleware runs on every request. On Cloudflare Workers, middleware executes in the edge runtime, not the Node.js runtime. This means any middleware that imports crypto or uses APIs outside the Workers subset will fail at request time, not at build time.

I had a middleware that checked rate limits using a counter in D1. Simple enough. But the D1 binding is not available in the middleware context through OpenNext the way it is in route handlers. I had to move rate limiting to a Cloudflare WAF rule instead of doing it in Next.js middleware. Not a dealbreaker, but the middleware → Workers gap is larger than the documentation suggests.

`next/image` and Workers

Static images work fine. Dynamic image optimization through next/image does not, because Workers lack the image processing libraries that Node.js uses.

The fix: I pre-processed all images at build time and served them as static assets. No runtime optimization needed. For an app with fewer than 50 unique images, this was trivial. For an app with user-uploaded content, it would be a hard problem.

Environment variables in client components

Environment variables prefixed with NEXT_PUBLIC_ are baked into the client bundle at build time. That works fine. But runtime environment variables accessed through process.env in server components behave differently in Workers.

Cloudflare Workers use a env binding, not process.env. OpenNext bridges this, but the bridge is not seamless. Variables I set in wrangler.toml were available in the Worker context but not through the process.env API that Next.js server components expect at runtime. The workaround was importing the Cloudflare bindings through the @opennextjs/cloudflare types and passing them explicitly.

The first-deploy cold start

First deploy after building with OpenNext takes roughly 45-60 seconds for the first Worker request. After the initial cold start, response times drop to normal.

This is a known Workers characteristic compounded by Next.js route chunking. The more routes your app has, the more chunks the Worker needs to load on the first request. My app has about 30 routes. A smaller app with 5 routes would cold-start faster.

Subsequent deploys are faster because Cloudflare caches the compilation output. But the first deploy of the day always has a cold start window.

Streaming + D1 in the same route handler

This one was subtle. A route handler that reads from D1 and then streams a response — for example, loading session history and then starting the chat stream — sometimes lost the D1 response before the stream completed.

The issue: Workers terminate the request context after the response is sent. If you read from D1 inside the same handler that starts a streaming response, the D1 bindings can close before the stream finishes if the stream outlasts the initial response resolution.

The fix: resolve all D1 reads before starting the stream. Load session data early, store it in a closure, then begin streaming.

// Before: D1 read interleaved with streaming
export async function POST(req: Request) {
  const session = await db.prepare("SELECT * FROM sessions WHERE id = ?").bind(sessionId).first();
  const stream = await ai.beta.chat.completions.create({ model, messages, stream: true });
  return new Response(streamToReadableStream(stream));
}

// After: resolve D1 reads first, then stream
export async function POST(req: Request) {
  const session = await db.prepare("SELECT * FROM sessions WHERE id = ?").bind(sessionId).first();
  const messagesWithHistory = [...(session.messages || []), ...newMessages];
  const stream = await ai.beta.chat.completions.create({ model, messages: messagesWithHistory, stream: true });
  return new Response(streamToReadableStream(stream));
}

Straightforward fix once I recognized the pattern. Cost me two evenings of debugging before I found it.

What I am still watching

ISR revalidation at scale. I have not reached the threshold where Workers cache API limits matter. If the app grows to hundreds of content pages with frequent revalidations, I may need to revisit the caching strategy.
D1 row limits. A few thousand sessions with 10-15 messages each is well under D1's limits. If the app crosses 100k+ sessions, I will need either a message archiving strategy or a move to R2 for stored messages.
OpenNext churn. The OpenNext → Cloudflare pipeline changes version to version. Two minor bumps have already required wrangler.toml changes. The stack is stable enough for production but not mature enough to set and forget.

The honest take

Next.js 16 on Cloudflare Workers works for a real production app. The static generation path is smooth. D1 is solid. Streaming is fine after you learn the D1-resolution-before-stream rule.

The rough edges are in the gaps between ecosystems: middleware runtimes, environment variable access patterns, and image optimization. Each gap has a workaround, but the workarounds are not always documented.

The OpenNext team has done the heavy lift of bridging Next.js to Workers. The remaining friction is mostly about accepting that you are on a serverless platform with different constraints than Vercel. Once you internalize those constraints — resolve D1 first, pre-process images, avoid Node.js APIs in middleware — the stack holds.

For a production app with streaming chat, anonymous sessions, and static content: cosskill.com. The stack file is pinned on the repo if you want the full picture.

Why I Chose DeepSeek Over GPT-4 for a Free AI Conversation App

neo xia — Mon, 22 Jun 2026 06:43:39 +0000

I did not choose DeepSeek because I think GPT-4 is bad. I chose it because I was building a free app, and free apps teach you what actually matters pretty fast.

The question was simple: how do I keep sessions cheap enough that people can practice a lot without me lighting money on fire?

The answer pushed me toward DeepSeek-V3 (and later R1 for specific tasks).

The real constraint was volume

The app is a conversation practice tool. People come in to rehearse hard talks, not to admire the model.

A single practice session runs 8-15 turns. Each turn is roughly 300-600 tokens in, 100-300 out. Multiply that by five sessions a week per active user and the costs start compounding.

Here is what the math looked like when I was choosing (mid-2026 pricing):

Model	Input cost (per 1M tokens)	Output cost (per 1M tokens)	Cost per 10-turn session (est.)
GPT-4o	$2.50	$10.00	~$0.04-0.06
GPT-4 Turbo	$10.00	$30.00	~$0.12-0.18
DeepSeek-V3	$0.27	$1.10	~$0.004-0.007
DeepSeek-R1	$0.55	$2.19	~$0.008-0.012

At scale, the difference between $0.005 and $0.05 per session is the difference between running a free product and needing a paywall after three conversations. I wanted people to come back daily without hitting a wall.

What DeepSeek handled well

It stayed in character for 10-15 turns. It pushed back when the user got vague. It followed persona heuristics (numbered if/then rules in the system prompt) about as reliably as GPT-4o did for our use case.

For salary negotiation rehearsal, the model needs to say "that's not in the budget" and hold that position for three more turns while the user tries different approaches. DeepSeek-V3 did this. Not perfectly, but reliably enough that sessions felt real.

It also made the app easier to run as a free product. People can try, fail, reset, and try again without me worrying about per-session cost.

Where GPT-4 was still better

GPT-4 (and 4o) is smoother with nuanced emotional wording. When a conversation gets subtle, loaded with subtext, or requires picking up on implied meaning, GPT-4 catches more.

For the breakup text persona, GPT-4o noticed when a user's "kind" message was actually passive-aggressive. DeepSeek missed that about 20% more often in my informal testing across ~100 sessions.

But polish was not the main bottleneck for this product. The main bottleneck was getting people enough reps to build actual comfort with discomfort.

The tradeoff I actually cared about

Do I want one beautiful session, or ten useful ones?

For this app, ten useful ones. Every time.

So I took the cheaper model, put the engineering effort into the prompt architecture (persona seed, heuristics, mode wrapper, boundaries), and accepted that 85-90% quality at 10x the volume was a better product than 95% quality at 1x.

The model matters. The scaffolding around it matters more.

What I changed to make DeepSeek work

A few things made the choice viable:

Tighter system prompts. DeepSeek drifts more with long, loose instructions. Shorter seed, more numbered rules.
Lower temperature (0.55 for roleplay, 0.2 for scoring). Kept persona variation without character breaks.
Max reply length cap in the mode wrapper. DeepSeek's default is wordier than GPT-4o, so I had to constrain it explicitly.
Built retries into the flow. A bad response does not kill the session; the user gets a fresh turn.

The last one is underrated for any practice app. The experience should not feel fragile.

My actual takeaway

If you are building a free AI app, the best model is not always the smartest one. It is the one that lets people come back tomorrow.

Not bragging rights. Not benchmark charts. Whether the app stays affordable enough to be used like a tool instead of a demo.

For cosskill, DeepSeek made more sense. It let me build something people use five times a week instead of once and forget. Which is usually the whole game for a practice product anyway.

If you want to see the product, it is at cosskill.com.

I built an AI conversation simulator because I kept chickening out of real talks

neo xia — Mon, 01 Jun 2026 03:43:42 +0000

Last year I needed to ask for a raise. I knew my number, I'd read the guides, I had bullet points in my notes app. Then my manager said "let's chat about your goals for next quarter" and I said "sounds great, looking forward to it" and hung up. Never brought up money.

Same thing kept happening elsewhere. Coworker taking credit for my work, I said nothing. Relationship that should've ended months earlier, I kept postponing. I always knew what to say. I just couldn't say it with someone actually looking at me.

So I started building a thing to practice on. That thing became cosskill.

What it actually is

You pick a persona, tell it the situation in a sentence, and start talking. The persona doesn't help you. It holds position and pushes back. You practice not folding.

Think of it as a flight simulator for hard conversations. You rehearse until your opener comes out steady, then go do the real thing. 20 personas across five categories:

Operators (Musk, Jobs): first-principles thinking, harsh product feedback
Strategists (Trump, Buffett): treat everything as a deal or a bet
Relationship (Ex, Coworker): breakups, workplace friction, family money
Philosophy (Socrates, Aurelius, Confucius, Sun Tzu, four more): each tradition frames problems differently
Psychology (Rogers, Rosenberg, Ellis, Frankl, Kahneman, Jung): therapeutic frameworks on real situations

These aren't celebrity impressions. The Buffett persona won't hype your startup idea. It'll ask "what's the downside?" and keep asking until you have something concrete.

Tech stack

Next.js 16 on Cloudflare Workers. DeepSeek for inference. Cloudflare D1 (SQLite at edge) for the bits that need to persist. No user accounts, chat history lives in localStorage.

Monthly cost stays low enough that the free tier (10 messages/day) doesn't worry me.

Why I made these choices

DeepSeek instead of GPT-4/Claude. Each conversation is 10-30 messages. At GPT-4 pricing a free product bleeds money. DeepSeek gives maybe 90% of the quality for a fraction of the cost on this specific task, which is maintaining persona consistency across a back-and-forth.

No accounts. Every signup form is friction between "I need to practice this talk" and actually practicing it. If I add a login wall, some percentage of people close the tab and go back to rehearsing in the shower. I'd rather have them practice.

Cloudflare Workers instead of Vercel. D1 is genuinely good for this. One database at edge, no connection pooling, no separate DB service. DX is slightly worse for Next.js specifically but the deploy simplicity makes up for it.

Personas that resist instead of a chatbot that helps. A generic AI assistant will agree with you. That's the problem. You don't need agreement. You need someone saying "that's not in the budget" while you practice not conceding immediately. Each persona has hardcoded positions and pushback patterns. They're useful by being difficult.

What I actually learned building this

Prompting a persona to stay in character is a solved problem. The hard part was figuring out what "practice" means for conversations.

Scripts don't work because they sound robotic and shatter on contact with a real human. Free-form chatting doesn't work because there's no improvement loop. What actually works: have one sentence you want to say, say it to something that pushes back, adjust based on what happens, try again. The first two minutes of any hard conversation set the rest. So you practice those two minutes.

After a few runs, people say the real conversation feels less scary. Not because they memorized a script. Because they already heard the worst response and survived. "That's not in the budget" doesn't feel like a gut punch when you've heard it four times from an AI and practiced not caving.

Where it's at

Early. Traffic is growing organically. The pages that get the most hits are salary negotiation practice and breakup text help. Draw your own conclusions about what people actually struggle with.

Free tier handles most users. Pro ($9.90/month annual) is for people who want unlimited messages and custom personas.

Go try it

cosskill.com. No signup, just pick a persona and start. If you have a salary conversation coming up, try Buffett. Need to set a boundary with a coworker, try the Coworker persona. Want someone to tear your startup pitch apart, try Jobs.

Genuinely curious: what conversations do devs specifically need to practice that I haven't thought of? And what persona doesn't exist yet but should?

DEV Community: neo xia

Why marketplace product photos get rejected: white-background image requirements, and a 1-minute browser fix

Why "white background" is a hard requirement

What the requirements usually say

The 1-minute fix in the browser

Checklist before you re-upload

Four Marketplaces, One Listing Workflow: What Amazon, eBay, Etsy and Shopify Expect From Your Copy

What each platform actually expects

Why paste-reformatting breaks down

What we built instead

Pricing facts

Ship an Editor, Not a Generator: Designing Review-First AI for Marketplace Listings

The trust problem with generated text

The loop: extract → draft → review → publish

Why the same pass handles images

What we learned

Reading any marketplace product page from a Chrome extension: JSON-LD first, selectors second

Start with JSON-LD, always

Selectors as a scoped fallback

Constraints matter more than extraction

MV3 practicalities

Review before publish

Rehearse the conversations you dread: what building an AI practice simulator taught me

What practicing looks like

Three things I learned building and using it

Try it

How We Built an AI Listing Optimizer for Amazon, Shopify, eBay & Etsy (Chrome Extension Architecture)

The core idea: run on the live page

Platform-aware rules, not generic copy

Architecture

Pricing model

I built an AI simulator for the conversations people avoid

What rehearsing actually looks like

Three things building it taught me

1. A roleplay bot that agrees with you is useless

2. The rewind is the feature

3. Feedback has to be concrete

A 10-minute rehearsal you can do today

Honest limits

White or Transparent? A Practical Guide to Product Image Backgrounds

Why background choice is a layout decision

What the platforms actually require

White or transparent: choosing per surface

A checklist for a consistent grid

Conclusion

FAQ

We put an ONNX background-removal container behind a Next.js Worker on Cloudflare

We put an ONNX background-removal container behind a Next.js Worker on Cloudflare

The constraint that shapes everything: 30 seconds of CPU

Submit, then poll

Cold starts: loading a model while the health check is watching

The landmine: do not name an R2 binding IMAGES

Not every edge needs the same model

Cleanup is a cron, not a best-effort delete

What I would tell someone starting today

FAQ

Next.js 16 on Cloudflare Workers: what broke and what didn't

The stack

What worked surprisingly well

Static generation and ISR

D1 at the edge

Streaming chat responses

Anonymous user sessions

What broke

Middleware and edge runtime mismatch

next/image and Workers

Environment variables in client components

The first-deploy cold start

Streaming + D1 in the same route handler

What I am still watching

The honest take

Why I Chose DeepSeek Over GPT-4 for a Free AI Conversation App

The real constraint was volume

What DeepSeek handled well

Where GPT-4 was still better

The tradeoff I actually cared about

What I changed to make DeepSeek work

My actual takeaway

I built an AI conversation simulator because I kept chickening out of real talks

What it actually is

The landmine: do not name an R2 binding `IMAGES`

`next/image` and Workers