DEV Community: Lucas Santos Rodrigues

A PlayStation 1 burger: posterized fog, ordered dithering and vertex jitter in pure CSS

Lucas Santos Rodrigues — Mon, 03 Aug 2026 13:56:04 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Two comfort foods collided here.

One is Méqui — what every Brazilian actually calls McDonald's. Not a fancy dish: the burger you begged your parents for on a Sunday afternoon.

The other is the way games looked when I was a kid. Chunky low-poly geometry, colours banding because there weren't enough of them, dithering scattered over every gradient, coloured fog swallowing the far plane, and that faint wobble PSX hardware had because it snapped vertices to integers.

So: a comfort-food burger, rendered like it's running on 1998 hardware.

🔗 Live · Source (MIT)

Demo

Scroll and it comes apart, labelling itself as it goes:

Journey

Upfront: the burger's geometry is SVG, not CSS shapes — ~370 polygons emitted by a build-time script I wrote. Every look on this page, though, is CSS: the fog, the grain, the outlines, the motion. That's the part worth showing, because most of it is four lines each.

Posterization is just gradients with hard stops

Banding is usually the enemy. Here it's the entire point. Every colour stop is doubled so there's no interpolation between bands:

.fx--fog {
  mix-blend-mode: screen;
  opacity: 0.5;
  background:
    radial-gradient(58% 44% at 12% 8%, #ff2d95 0 6%, #a8215f 6% 13%,
      #5a1140 13% 22%, #0000 40%),
    radial-gradient(52% 40% at 88% 22%, #16d6ff 0 5%, #0f88b8 5% 12%,
      #0a4a70 12% 21%, #0000 38%);
}

#ff2d95 0 6%, #a8215f 6% 13% — each colour holds flat, then snaps. Stack four of those and you get coloured fog that looks quantized to an 8-bit palette.

Ordered dithering is two conic gradients

My favourite four lines on the page. A 2px checkerboard and a 3px checkerboard, offset from each other, blended over everything:

.fx--dither {
  mix-blend-mode: overlay;
  opacity: 0.22;
  background-image:
    conic-gradient(from 90deg at 1px 1px, #0000 25%, #000 0),
    conic-gradient(from 90deg at 1px 1px, #fff0 25%, #fff 0);
  background-size: 2px 2px, 3px 3px;
  background-position: 0 0, 1px 1px;
}

Two coprime grid sizes never line up, so the interference reads as ordered dither instead of a visible checkerboard. It breaks up the fog's bands and puts "low-resolution render" grain back into an otherwise perfectly crisp vector page.

Vertex jitter needs steps(), and that's the whole joke

PSX consoles had no sub-pixel precision, so geometry shimmered. The charm is in not interpolating — a smooth version of this just looks like drift:

@keyframes psx-jitter {
  0%   { translate: 0 0; }
  16%  { translate: 0.9px -0.6px; }
  33%  { translate: -0.7px 0.5px; }
  50%  { translate: 0.4px 0.9px; }
  66%  { translate: -0.9px -0.4px; }
  83%  { translate: 0.6px 0.7px; }
}
.burger-jitter { animation: psx-jitter 1.1s steps(1, jump-none) infinite; }

steps(1, jump-none) holds each keyframe and snaps to the next. Sub-pixel amounts, but your eye catches it instantly.

One light, five tones

The cel shading isn't hand-picked colour. The generator computes a normal per face, dots it with one warm key light, then quantizes the result to a 5-step ramp mixed toward that light and a single cool ambient.

Quantization is what makes it read as cel-shaded — the banding falls out of the renderer instead of being painted on top. And because all seven ingredients derive from the same two colours, they look like one render instead of seven stickers.

Black outlines, no soft edges, no round corners

PSX-era art has hard everything. No border-radius anywhere — corners are chamfered with clip-path: polygon(). No blurred shadows — box-shadow: 8px 9px 0 with zero blur. Text outlines are a ring of eight zero-blur text-shadows rather than -webkit-text-stroke.

The one that fought me

The big MÉQUI wordmark uses background-clip: text for its cel-shading bands, plus a stack of drop-shadow() filters for the outline. It rendered solid black: Chrome drops the text clip when a filter lands on the same element.

The fix was to stop asking one element to do two jobs — solid colour and the text-shadow ring on the base element, gradient clip on an ::after with content: attr(data-txt) sitting exactly on top.

Motion

The layers separate with a CSS scroll-driven animation on a named view-timeline, ranged contain 0% → contain 100% — which, for a section taller than the viewport, is exactly the window where its sticky child is pinned. No scroll listeners, no library. It's wrapped in @supports (animation-timeline: view()) with a real fallback, since Firefox doesn't ship it yet.

The page carries one line of runtime JS: the CSS import Vite needs as an entry point.

Thanks for reading! The fog and dither snippets are genuinely drop-in — steal them.

Méqui — the story of McDonald's in Brazil, told by a burger that comes apart as you scroll

Lucas Santos Rodrigues — Mon, 03 Aug 2026 13:53:16 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

In Brazil, nobody says "McDonald's". They say Méqui.

On August 30th, 2019, the company quietly changed the sign on two restaurants to read MÉQUI, issued no press release, and let the country figure it out. The mystery spread on its own. The nickname stuck so hard it went on the packaging, the tray liners and the menu.

So the comfort food I picked isn't a dish. It's the burger every Brazilian kid grew up begging for on a Sunday — and the 46 years of history stacked behind it.

🔗 Live site · Source

The page is one continuous scroll: a hero, a giant SVG burger that comes apart layer by layer as it travels down the screen, then a timeline from the first store in Copacabana in 1979 to the day the sign changed.

It's written in Portuguese on purpose. The whole piece is about a country renaming a global brand in its own accent — translating it would defeat the point.

Demo

The burger arrives assembled:

…and comes apart as it descends, labelling itself on the way down:

The one trick worth stealing

The separation is a CSS scroll-driven animation anchored to a named view-timeline. The section is 460svh tall and holds a position: sticky child:

.stage      { view-timeline-name: --burger; block-size: 460svh; }
.stage__pin { position: sticky; inset-block-start: 0; block-size: 100svh; }

.bx-layer {
  animation: peel linear both;
  animation-timeline: --burger;
  animation-range: contain var(--a) contain var(--b);
}

The part that made it click: for a subject taller than the viewport, the contain range runs from "the section's top edge meets the top of the screen" to "its bottom edge meets the bottom of the screen" — which is, point for point, exactly the window in which the sticky child is pinned. So contain 0% → contain 100% means "animate only while the burger is parked on screen", with no magic numbers.

Each layer gets its own range, offset 5% from the one above. That stagger is the whole reason the sandwich opens top-down instead of all at once.

One more thing that surprised me: no timeline-scope is needed. The SVG layers are descendants of .stage, and timeline name lookup already walks up the ancestors.

Accessibility and the Firefox problem

Scroll-driven animations are Baseline: limited — Chrome/Edge 115+ and Safari 26+ have them; Firefox is still preview-only. So every scroll-driven rule lives inside @supports (animation-timeline: view()), with a not (...) branch that collapses the 460svh section back to auto height, un-sticks the pin, and shows the burger assembled with all labels visible.

I tested that branch by forcing the @supports query to fail: nothing is hidden, and nobody scrolls through 460svh of nothing.

Other things I cared about:

prefers-reduced-motion kills the PSX jitter, the fog and the scanlines. The layer separation stays, because it's the content of the section and the user drives it directly — but the travel is damped to 40% so it isn't a full-screen sweep.
On narrow screens the side labels don't fit, so they disappear and the layers come back as a real text list at the bottom of the stage.
Skip link, semantic landmarks, no heading-level skips, gold focus rings that survive every background in the palette, scroll-margin so anchor targets don't hide behind the fixed header.
The burger SVG is role="img" with a <title>/<desc>; the fog, dither and scanline overlays are aria-hidden and pointer-events: none.

Journey

Two bugs are worth confessing.

The wordmark rendered black. I had background-clip: text for the cel-shading bands plus a filter: drop-shadow() stack for the outline. Chrome loses the text clip when a filter is on the same element. Fix: split the job — solid colour and a text-shadow ring on the base element, gradient clip on an ::after with content: attr(data-txt).

Horizontal scroll on mobile. The stage's grid column was sizing to the SVG's natural width — 509px inside a 369px viewport. I reached for overflow-x: clip on html and it did not stop the viewport scrolling. The actual fix was grid-template-columns: minmax(0, 1fr), because auto tracks grow to max-content. Clipping was treating a symptom.

The whole page ships one line of runtime JavaScript — the import of the CSS that Vite needs as an entry module. Everything else, including the burger, is CSS.

MIT licensed. Fork it, take the contain trick, ignore my colour choices.

I generated 207 MCP tools from an OpenAPI spec. Generating them was the easy part.

Lucas Santos Rodrigues — Thu, 30 Jul 2026 00:23:08 +0000

Every MCP server I've read that wraps a third-party REST API has the same shape: someone picked fifteen or twenty endpoints that seemed useful, hand-wrote a Zod schema for each, and shipped it.

That works for about three months.

Then the API adds a field, deprecates an enum value, renames a query parameter. The wrapper doesn't notice, because nothing in it is connected to the API's own description of itself. The schemas drift. The model starts getting rejected by the upstream API for reasons it can't see, and you get to debug an LLM guessing at a shape that stopped being true in February.

The other failure is quieter. You need endpoint twenty-one — the one about persistent disks, or scaling, or environment groups — and the author skipped it. Now you're back to curl, except the agent is holding half the context and you're holding the other half.

I wanted neither, so I built render-useful-mcp: an MCP server for Render where every API tool is generated from Render's own OpenAPI document. All 207 endpoints, no curation.

The generating part took a weekend. Everything after that was the actual work.

Make the generator refuse to guess

The tempting way to write a spec-to-tools generator is to make it forgiving. Skip what you can't parse, fall back to { type: "object" } when a $ref gets hairy, log a warning and move on. You get 207 tools on the first run and feel great.

You also get tools that lie. A parameter typed as a free-form object when the API actually wants one of four enum values is worse than no tool at all — the model will confidently produce garbage, and the failure surfaces three layers away from the cause.

So the generator is fail-closed. It aborts the build, loudly, on:

An operation whose tag doesn't map to a known toolset. Render added a resource category and I haven't classified it yet. That's my problem to solve, not something to paper over.
A tool name collision. Two operations deriving the same name means my naming scheme is wrong.
A cyclic $ref it can't flatten. JSON Schema handles recursion; the "just inline everything" shortcut doesn't. Better to know.
A path parameter that doesn't appear in the URL template, or appears in the template but isn't declared. Either direction means I'd build a URL wrong at runtime.

CI runs the generator. A spec change that the generator can't handle correctly fails the build instead of shipping a subtly broken tool. That's the entire value proposition — a hand-written wrapper cannot have this property, because there's nothing to check it against.

The payoff is that Render's own constraints reach the model intact. Enums stay enums. String patterns stay patterns. Required fields stay required. The model gets rejected by my schema, locally, with a readable message, instead of by Render's API after a round trip.

The problem nobody warns you about

207 API tools plus 4 workflow tools plus a meta-tool is 212 entries in tools/list.

You cannot ship that.

Every tool definition — name, description, full input schema — goes into the model's context on every single turn. 212 of them is tens of thousands of tokens spent before the user has typed anything. Worse than the cost is the dilution: a model choosing between 212 near-neighbours picks wrong far more often than one choosing between fifteen. Complete coverage, delivered naively, makes the server less useful than the curated subset I was trying to beat.

The fix is to separate what the server can do from what it exposes.

The 207 tools are grouped into 17 toolsets by the tag on their originating operation: services, postgres, disks, blueprints, logs, metrics, webhooks, network, maintenance, workflows, and so on. Everything is on by default, because a server that hides capability by default is a server that fails silently for the person who needed the hidden thing. But one environment variable narrows it:

RENDER_MCP_TOOLSETS=services,logs,metrics

Now the model sees a few dozen tools instead of 212, chosen by you, for the job you're actually doing. There's a RENDER_MCP_READ_ONLY=true on top of that, which drops every mutating operation — the right default for anything you'd point at production.

The interesting constraint is that this selection is read once, at startup, and never changes. I'll come back to why.

Four tools that aren't in the spec

Generated tools are a faithful mirror of the API, which means they inherit the API's ergonomics. Some sequences that are one thought for a human are four calls for an agent, and agents are bad at four-call sequences.

So there are four hand-written tools on top:

render_find_service — you know the service as "the api", Render knows it as srv-d1a2b3c4e5f6g7h8i9j0. Fuzzy-matches by name and returns close alternatives when there's no exact hit, instead of failing.
render_wait_for_deploy — blocks until a deploy reaches a terminal state, so the agent stops re-polling in a loop and burning turns.
render_service_status — one call that answers "is this thing healthy?" by combining service detail, latest deploy, and recent error logs. This is the tool I use most.
render_recent_logs — the log query you actually want, without constructing a filter object by hand.

This is the split I'd defend generally: generate the surface, hand-write the intent. The spec knows what the API can do. Only you know what people are trying to accomplish with it.

Keeping up with an API you don't control

A GitHub Action runs weekly. It fetches Render's current OpenAPI document, regenerates the catalogue, and diffs the result against what's committed.

If the tool set is unchanged, it exits quietly. No noise. If something changed, it opens a PR with the diff and a summary — and flags whether the change is breaking, meaning removed operations or tightened constraints, versus additive.

Small detail with a lesson in it: Render's OpenAPI document isn't served from a stable URL. The documented .json and .yaml endpoints 404. So the fetcher extracts the spec from the docs HTML and validates the extracted result before handing it to the generator, because scraping something structural without validating it is just a slower way to be wrong.

If you're building anything similar against an API whose spec isn't formally published: assume the retrieval path will break, and make it fail loudly when it does.

The 2026-07-28 rewrite

MCP's 2026-07-28 revision turned the protocol's core stateless — request/response, no session handshake, no long-lived connection. Great for anyone deploying to serverless. For a stdio server like mine, the migration was smaller than expected but forced one real design decision.

Under the new model, list endpoints don't vary per connection. tools/list responses carry cache hints — a TTL and a scope — so clients can treat the tool list as a cacheable resource rather than re-fetching it every turn. Mine ships a 5-minute TTL.

That's fundamentally incompatible with a tool list that mutates mid-session. The earlier design let the model call render_toolsets to enable a toolset at runtime, emitting notifications/tools/list_changed so new tools appeared immediately. Clever, and now wrong: you cannot advertise a list as cacheable and then change it underneath the cache.

So the enabled set became immutable for the process lifetime, and render_toolsets was demoted to reporting — it tells you which toolsets exist and which are on, and tells you to change the env var and restart. Less magical, correct, and honestly easier to reason about. The server declares no listChanged capability at all, and a test asserts that.

The general lesson: caching semantics and runtime mutability are the same design decision wearing two hats. Pick one.

Try it

npx render-useful-mcp

It needs RENDER_API_KEY. It's on npm and in the MCP Registry, published with OIDC trusted publishing and provenance attestation — no long-lived npm token exists to steal. There's a Claude Code plugin in the repo. No telemetry, no analytics, no backend; the process contacts exactly one host, and your key is never written to disk and is redacted from log output.

Positioning, honestly: Render maintains an official MCP server, hosted, with OAuth, and if it covers what you need you should use it. Their docs are upfront about the boundaries — creation for a subset of service types, and for existing resources only deploys and environment variables. Mine covers the operational surface outside that: scaling, disks, blueprints, environment groups, custom domains, webhooks, maintenance, workflows. I'm not affiliated with Render.

MIT. Issues and PRs welcome, particularly from anyone who has fought the tool-count problem and solved it differently — I don't think static toolsets are the last word on it.

github.com/LuSrodri/render-useful-mcp

How I Rebuilt Educando.app's Core: Tavily + GPT-5.4 nano Search Pipeline

Lucas Santos Rodrigues — Sun, 19 Apr 2026 02:22:50 +0000

After a security incident forced Educando.app offline, I took the opportunity to rethink the entire product. The original version was a Gemini-powered activity generator for Brazilian teachers. The new version is an intelligent content repository with a semantic search pipeline. This post is about the technical decisions behind that rebuild.

Why the Generator Had to Go

The original architecture was simple: user submits a prompt → Next.js API route → Gemini Flash → response streamed to the UI. It worked, but it had two structural problems.

First, a compromised API key triggered unauthorized generation at scale. The key was client-accessible during an early dev iteration and never fully locked down server-side. Lesson: even keys that "should" be server-only need to be audited regularly — especially when Vercel environment variable scoping can be misconfigured silently.

Second, the value was never in real-time generation. Teachers don't want to prompt an LLM. They want to find a good activity fast, trust it, and use it. A repository with good search solves that better than a generator.

The New Search Pipeline

The core is a three-layer pipeline:

User query → Tavily search → GPT-5.4 nano evaluation → ranked JSON → UI

Layer 1: Tavily

Tavily handles the actual search. It returns structured results with titles, descriptions, and URLs. The query goes in raw — no preprocessing — and Tavily does the semantic heavy lifting.

Layer 2: GPT-5.4 nano evaluation

Each result batch gets passed to GPT-5.4 nano with a structured prompt asking it to score and rank the results as JSON. The model evaluates relevance, content quality, and match to the Brazilian curriculum (BNCC codes). The prompt enforces strict JSON output — no preamble, no markdown fences — so the response can be parsed directly.

const evaluationPrompt = `
You are evaluating educational activity search results for Brazilian teachers.
Score each result from 0-10 based on: relevance, pedagogical quality, BNCC alignment.
Return ONLY a JSON array: [{ "index": 0, "score": 8, "reason": "..." }, ...]
Results: ${JSON.stringify(searchResults)}
Query: "${userQuery}"
`

GPT-5.4 nano is the right model here — it's fast, cheap, and the task is classification/ranking, not generation. No need for a larger model.

Layer 3: Supabase cache

Results are cached in Supabase keyed by a normalized query hash. Cache hit = skip Tavily + GPT entirely. This keeps costs predictable and latency low for repeated queries.

const queryHash = createHash('md5').update(normalizedQuery).digest('hex')
const cached = await supabase
  .from('search_cache')
  .select('results')
  .eq('query_hash', queryHash)
  .single()

if (cached.data) return cached.data.results

A separate search_telemetry table logs every query and click for future ranking improvements.

Content Schema

The old schema was flat — just the generated text blob. The new schema is structured:

create table activities (
  id uuid primary key default gen_random_uuid(),
  title text not null,
  theme text not null,
  short_description text,
  long_description text,
  bncc_codes text[],
  type text,
  image_url text,
  created_at timestamptz default now()
);

BNCC codes are the Brazilian national curriculum identifiers (e.g. EF05LP01). Having them as a queryable array field lets the search layer filter by curriculum alignment without relying purely on semantic matching.

Image Processing with Replicate + Qwen

Activity thumbnails go through a qwen/qwen-image-2-pro pipeline on Replicate. The model handles resizing, quality normalization, and description extraction — the output feeds back into the activity metadata for better search indexing.

Abuse Prevention

The original version had FingerprintJS + IP hashing. It was complex and brittle — VPN, browser switch, new tab, and the identity broke.

The new version uses Cloudflare Turnstile at the edge combined with server-side rate limiting per IP. Turnstile runs before the request hits the Next.js API route, so abuse is stopped at the CDN level. Simpler, more reliable, and no client-side fingerprinting library to maintain.

No auth in this version. The Saved Activities feature is scoped to v2, which will include Supabase Auth + Google SSO. There was no reason to ship an auth system without a paywall to motivate it.

Stack

Next.js + TypeScript — unchanged
Supabase — database, cache, telemetry
Tavily — search
GPT-5.4 nano — result evaluation and ranking
Replicate (Qwen) — image processing
Cloudflare Turnstile — abuse prevention
Vercel — deployment

What's Next

The premium tier — download/print behind a paywall, Supabase Auth, Google SSO — is designed but not yet shipped. The repository needs enough content before a paywall makes sense.

The security incident was painful. Rebuilding was the right call.

Building an image processing pipeline with the Watermark Removal API

Lucas Santos Rodrigues — Sat, 18 Apr 2026 18:26:00 +0000

If you work with product photos, real estate listings, or any user-generated content at scale, chances are you've dealt with watermarked images. Removing them manually doesn't scale. This post walks through building a simple but production-ready image processing pipeline using the Goodbye Watermark API — available on RapidAPI.

The API accepts an image (URL or base64), runs it through an AI inpainting model, and returns a clean PNG. No UI, no manual steps — just HTTP.

What we're building

A pipeline that:

Takes a list of image URLs
Sends each one to the Watermark Removal API
Saves the cleaned images to disk

Simple, composable, and easy to drop into any existing workflow.

cURL

Before writing any code, let's confirm the API works:

curl -X POST \
  https://goodbye-watermark-api.p.rapidapi.com/api/v1/remove-watermark \
  -H "x-rapidapi-key: YOUR_RAPIDAPI_KEY" \
  -H "x-rapidapi-host: goodbye-watermark-api.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{ "image": "https://example.com/photo-with-watermark.jpg" }'

You'll get back:

{
  "success": true,
  "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...",
  "format": "png"
}

The image field is a data URI. From here, you can decode the base64 and write it to disk.

Node.js pipeline

import fs from "fs";
import fetch from "node-fetch";

const RAPIDAPI_KEY = process.env.RAPIDAPI_KEY;

const images = [
  "https://example.com/product-1.jpg",
  "https://example.com/product-2.jpg",
  "https://example.com/product-3.jpg",
];

async function removeWatermark(imageUrl) {
  const res = await fetch(
    "https://goodbye-watermark-api.p.rapidapi.com/api/v1/remove-watermark",
    {
      method: "POST",
      headers: {
        "x-rapidapi-key": RAPIDAPI_KEY,
        "x-rapidapi-host": "goodbye-watermark-api.p.rapidapi.com",
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ image: imageUrl }),
    }
  );

  const data = await res.json();
  if (!data.success) throw new Error(data.error);
  return data.image; // data URI
}

function saveDataUri(dataUri, filename) {
  const base64 = dataUri.replace(/^data:image\/png;base64,/, "");
  fs.writeFileSync(filename, Buffer.from(base64, "base64"));
}

async function runPipeline() {
  for (let i = 0; i < images.length; i++) {
    console.log(`Processing image ${i + 1}/${images.length}...`);
    try {
      const result = await removeWatermark(images[i]);
      saveDataUri(result, `output-${i + 1}.png`);
      console.log(`✓ Saved output-${i + 1}.png`);
    } catch (err) {
      console.error(`✗ Failed: ${err.message}`);
    }
  }
}

runPipeline();

Python pipeline

import os
import base64
import requests

RAPIDAPI_KEY = os.environ["RAPIDAPI_KEY"]

images = [
    "https://example.com/product-1.jpg",
    "https://example.com/product-2.jpg",
    "https://example.com/product-3.jpg",
]

def remove_watermark(image_url):
    response = requests.post(
        "https://goodbye-watermark-api.p.rapidapi.com/api/v1/remove-watermark",
        headers={
            "x-rapidapi-key": RAPIDAPI_KEY,
            "x-rapidapi-host": "goodbye-watermark-api.p.rapidapi.com",
            "Content-Type": "application/json",
        },
        json={"image": image_url},
        timeout=60,
    )
    data = response.json()
    if not data.get("success"):
        raise Exception(data.get("error", "Unknown error"))
    return data["image"]  # data URI

def save_data_uri(data_uri, filename):
    base64_data = data_uri.split(",", 1)[1]
    with open(filename, "wb") as f:
        f.write(base64.b64decode(base64_data))

for i, url in enumerate(images):
    print(f"Processing image {i + 1}/{len(images)}...")
    try:
        result = remove_watermark(url)
        filename = f"output-{i + 1}.png"
        save_data_uri(result, filename)
        print(f"✓ Saved {filename}")
    except Exception as e:
        print(f"✗ Failed: {e}")

PHP pipeline

<?php

$apiKey = getenv("RAPIDAPI_KEY");

$images = [
    "https://example.com/product-1.jpg",
    "https://example.com/product-2.jpg",
    "https://example.com/product-3.jpg",
];

function removeWatermark(string $imageUrl, string $apiKey): string {
    $ch = curl_init("https://goodbye-watermark-api.p.rapidapi.com/api/v1/remove-watermark");
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_POST           => true,
        CURLOPT_TIMEOUT        => 60,
        CURLOPT_HTTPHEADER     => [
            "x-rapidapi-key: $apiKey",
            "x-rapidapi-host: goodbye-watermark-api.p.rapidapi.com",
            "Content-Type: application/json",
        ],
        CURLOPT_POSTFIELDS => json_encode(["image" => $imageUrl]),
    ]);

    $response = json_decode(curl_exec($ch), true);
    curl_close($ch);

    if (!$response["success"]) {
        throw new Exception($response["error"] ?? "Unknown error");
    }

    return $response["image"]; // data URI
}

function saveDataUri(string $dataUri, string $filename): void {
    $base64 = explode(",", $dataUri, 2)[1];
    file_put_contents($filename, base64_decode($base64));
}

foreach ($images as $i => $url) {
    $num = $i + 1;
    echo "Processing image $num/" . count($images) . "...\n";
    try {
        $result = removeWatermark($url, $apiKey);
        $filename = "output-$num.png";
        saveDataUri($result, $filename);
        echo "✓ Saved $filename\n";
    } catch (Exception $e) {
        echo "✗ Failed: " . $e->getMessage() . "\n";
    }
}

Error handling tips

The API returns structured errors on non-2xx responses:

{ "success": false, "error": "human-readable description" }

A few things worth handling in production:

429 — you've hit your plan's rate limit. Add a delay between requests or upgrade your plan.
500 — upstream inference failure. Safe to retry with exponential backoff.
503 — the API is temporarily down. Hit /api/v1/ping to check status before retrying.

What's next

This pipeline covers the basics. From here you can:

Process local files — read from disk and send as base64 instead of URL
Fan out in parallel — use Promise.all in Node.js or ThreadPoolExecutor in Python for faster batch processing
Upload to CDN — pipe the output directly to S3, Cloudflare R2, or any storage provider instead of saving to disk

Try it

The Goodbye Watermark API is live on RapidAPI with a pay-per-use model — no subscription lock-in.

👉 goodbye-watermark-api on RapidAPI

See more here: Goodbye Watermark

How to Use Replicate the Right Way in Your Next.js App (And Ship a Real Product With It)

Lucas Santos Rodrigues — Mon, 06 Apr 2026 23:52:21 +0000

Most tutorials show you how to call Replicate. Few show you how to use it well inside a real production app. This article covers the mistakes I made and the patterns that actually work — using Goodbye Watermark as a real-world case study.

What Is Replicate, Really?

Replicate is a cloud API that lets you run AI models — image generation, video, audio, vision — without owning a single GPU. You send an HTTP request, a model runs on their infrastructure, and you get the result back.

The business model is pay-per-prediction: you're charged for the time the model actually runs, not idle time. That means cold boots don't affect your cost — only your latency.

1. Understand the Prediction Lifecycle Before Writing Any Code

Every Replicate call creates a prediction — an object with a lifecycle:

starting → processing → succeeded (or failed / canceled)

starting: model is booting (cold start happens here)
processing: predict() is actively running
succeeded: output is ready — but files are deleted after 1 hour

That last point is critical. If you're not saving outputs immediately, you'll lose them. More on that below.

2. Polling vs. Webhooks: Choose the Right Strategy

Replicate gives you three ways to handle async predictions:

Polling (simplest, fine for most apps)

// Create the prediction
const prediction = await replicate.predictions.create({
  model: "owner/model-name",
  input: { image: imageUrl },
});

// Poll until done
let result = prediction;
while (result.status !== "succeeded" && result.status !== "failed") {
  await new Promise((r) => setTimeout(r, 1000));
  result = await replicate.predictions.get(result.id);
}

Works well for short-lived predictions (under ~15s). Simple to implement. The tradeoff: you're making repeated requests even when nothing has changed.

Webhooks (better for longer or background tasks)

const prediction = await replicate.predictions.create({
  model: "owner/model-name",
  input: { image: imageUrl },
  webhook: `${process.env.VERCEL_URL}/api/webhooks`,
  webhook_events_filter: ["completed"], // only fire when done
});

Replicate POSTs to your URL when the prediction finishes. No polling loop. If there are network issues, they retry automatically.

Use webhooks when:

Predictions take more than ~10-15 seconds
You want to persist results to a database
You're building background processing flows

Tip: Add query params to your webhook URL to carry context:

https://yourapp.com/api/webhooks?userId=abc123&predictionType=watermark

When to use each

Scenario	Use
Fast model, UX waits for result	Polling
Slow model, fire and notify	Webhooks
Background job, store to DB	Webhooks
Quick prototype	Polling

3. Cold Starts Are Real — Here's How to Handle Them

When a model hasn't been used recently, it needs to "boot up." This can add several seconds of latency on the first request after idle time.

For casual traffic: Cold boots are fine. You only pay for actual compute, not boot time.

For production apps with consistent traffic: Use a Deployment with minInstances: 1:

// Via the Replicate dashboard or API:
// Create a deployment for your model with min_instances = 1
// This keeps the model warm 24/7

This costs more (you're paying to keep the instance warm) but eliminates cold start latency entirely.

For Goodbye Watermark, I don't use a deployment because the traffic is spread across the day and a few seconds of latency on first boot is acceptable. But if you're building something with strict SLA requirements — use deployments.

4. Save Outputs Immediately — They Expire in 1 Hour

This is the gotcha that trips up everyone:

Input and output files are automatically deleted after 1 hour for any predictions created through the API.

If your app doesn't save the result right after succeeded, it's gone. Your options:

Option A: Stream back to the client immediately

// Next.js API route
export async function GET(request: Request) {
  const output = await replicate.run("owner/model", { input });
  return new Response(output); // stream back to client
}

Option B: Save to your own storage (Supabase Storage, S3, etc.)

const output = await replicate.run("owner/model", { input });
const response = await fetch(output[0]); // download from Replicate
const buffer = await response.arrayBuffer();
await supabase.storage.from("outputs").upload(`${userId}/${id}.png`, buffer);

For Goodbye Watermark, I stream the result directly back to the client. The user downloads it immediately. No storage needed, no expiry problem.

5. Next.js Config: Don't Forget This

If you're displaying output images from Replicate in a Next.js <Image> component, add this to your config or you'll get a domain error:

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "replicate.delivery",
      },
      {
        protocol: "https",
        hostname: "*.replicate.delivery",
      },
    ],
  },
};

Small thing, but it will bite you in production.

6. Error Handling That Doesn't Suck

Real-world Replicate usage needs to handle:

Network timeouts
Model errors (bad input format, unsupported file type)
Rate limits (429)
Prediction timeouts (30 min hard cap)

try {
  const prediction = await replicate.predictions.create({ ... });

  if (prediction?.error) {
    return NextResponse.json({ error: prediction.error }, { status: 500 });
  }

  // poll with timeout safety
  let result = prediction;
  const deadline = Date.now() + 60_000; // 60s max wait

  while (result.status !== "succeeded" && result.status !== "failed") {
    if (Date.now() > deadline) {
      return NextResponse.json({ error: "Prediction timed out" }, { status: 504 });
    }
    await new Promise((r) => setTimeout(r, 1500));
    result = await replicate.predictions.get(result.id);
  }

  if (result.status === "failed") {
    return NextResponse.json({ error: "Model failed" }, { status: 500 });
  }

  return NextResponse.json({ output: result.output });

} catch (err) {
  return NextResponse.json({ error: "Unexpected error" }, { status: 500 });
}

Set your own deadline. Replicate's hard limit is 30 minutes, but your users don't want to wait more than ~60 seconds for most tasks.

7. Rate Limits to Know

From Replicate's docs:

Create prediction: 600 requests/minute
All other endpoints: 3000 requests/minute

For most indie apps, you won't hit these. If you do, they return a 429 — build retry logic with exponential backoff.

8. Choosing the Right Model

Replicate hosts thousands of models. Two categories matter:

Official models — maintained by Replicate, always warm, stable API, predictable per-output pricing. Best for production use.

Community models — more variety, charged by compute time, may have cold starts, API can change between versions.

For Goodbye Watermark, I use the Qwen model for watermark removal. The choice came down to output quality and how well it handled semi-transparent watermarks — which are significantly harder than solid text watermarks. Testing a few models on realistic samples before committing to one is worth the extra hour.

Real-World Case Study: Goodbye Watermark

Goodbye Watermark is an AI watermark removal tool built with Next.js + Replicate + Vercel. The full stack is:

Frontend: Next.js + Tailwind CSS
AI: Replicate (Qwen model)
Hosting: Vercel
Payments: Stripe (two credit tiers)

The entire MVP was built in ~1 hour. The hardest part wasn't the UI — it was getting consistent output quality from the model across different watermark types.

Current results:

~150 weekly organic users
$0 paid acquisition
Zero infrastructure management

Replicate made the difference. Running my own GPU inference would have added weeks of setup and ongoing ops overhead. Instead, I spent that time on the UX and monetization.

TL;DR — The Patterns That Matter

Understand the prediction lifecycle — especially the 1-hour file expiry
Use polling for short tasks, webhooks for long/background ones
Use Deployments if cold start latency is a problem for your UX
Save or stream outputs immediately after succeeded
Add replicate.delivery to your Next.js image domains
Set your own deadline — don't wait 30 minutes for a user-facing request
Test multiple models before committing — quality varies significantly

Replicate is genuinely one of the best tools for indie developers shipping AI products fast. Use it well and you can build something real in a weekend.

Built something with Replicate? Drop it in the comments — always curious to see what people are shipping.

I built a free AI tool to remove watermarks from images — here's how it works

Lucas Santos Rodrigues — Tue, 24 Mar 2026 18:25:53 +0000

I got tired of watermarks ruining otherwise perfect images, so I built
Goodbye Watermark — a free AI-powered tool
that removes watermarks from images in seconds.

How it works

Upload your image, and the AI automatically detects and removes the watermark,
reconstructing the background behind it. No manual selection, no Photoshop skills needed.

Tech behind it

Next.js for the frontend
AI inpainting model to detect and fill the watermark region
Fully client-friendly: just upload and download

Why I built it

Most watermark removal tools are either paid, slow, or require desktop software.
I wanted something dead simple that runs in the browser with no friction.

Try it

👉 goodbyewatermark.com

Would love feedback from the community — especially if you hit edge cases
where it struggles. Drop a comment below!

Why I Built "I Hate Background" — a Privacy-First Background Removal Service

Lucas Santos Rodrigues — Mon, 15 Sep 2025 17:17:56 +0000

I always liked the idea of removing an image background in one click.
But I felt something was missing in most of the well-known services:

Privacy – many tools upload your image to their servers.
Paywall – most limit free images or force subscriptions.
Closed tech – no way to build something on top of it.

So I built I Hate Background – a privacy-first, AI-first tool that runs directly in your browser.
Nothing is uploaded. Your image never leaves your computer.
And it’s totally free to use on the website.

If you’re a developer and want to integrate background removal in your product, there’s also an API (paid, powered by NVIDIA GPUs) for production-level needs: I Hate Background – Rapid API

Why I’m posting here

I’m looking for honest feedback from developers and designers:

Does the site feel fast and simple?
Is the UX clear?
Would you use it for quick edits or in your workflow?
What could be improved (performance, docs, features)?

Want to know more about my project? Starred my public repo: I Hate Background Repo

The Alternative to remove.bg API

Lucas Santos Rodrigues — Mon, 01 Sep 2025 00:35:52 +0000

If you’ve ever needed to remove image backgrounds programmatically, chances are you’ve heard of remove.bg. It’s one of the most popular tools out there — but not the only one.

For developers looking for a fast, reliable, and more flexible option, let me introduce you to I Hate Background API: an AI-powered background removal service designed with scalability and performance in mind.

🚀 API Overview

I Hate Background API delivers fast and reliable background removal for images of any size or type.
Powered by cutting-edge deep learning models and accelerated on NVIDIA L4 GPUs, it produces high-quality results in just a few seconds.

⚡ Performance

⏱️ Average processing time: ~4s for 1024×1024 images
🌍 Works with any image size or type (products, portraits, graphics, etc.)
📈 Optimized for scalability and real-time applications

🔑 Key Features

AI precision → accurate edge detection & background separation
High-quality output → keeps fine details sharp, even with complex objects
Flexible input → supports JPEG, PNG, WEBP, and more
Production-ready → scalable API designed for demanding workloads

🛠️ Use Cases

E-commerce → clean product photos with transparent backgrounds
Design & Creative apps → enable users to edit/replace backgrounds instantly
Media & Marketing → automate image pipelines at scale
Automation workflows → integrate background removal into existing tools

📦 Example Request

Here’s how simple it is to use the API:

curl --request POST 
    --url https://i-hate-background-api.p.rapidapi.com/remove-background 
    --header 'Content-Type: multipart/form-data' 
    --header 'x-rapidapi-host: i-hate-background-api.p.rapidapi.com' 
    --header 'x-rapidapi-key: ****' 
    --form file=tree.png

Within seconds, you’ll get a PNG image with the background removed.

Before

After

🤔 Why use this API?

Whether you’re building an online store, a photo editing tool, or an automation pipeline, I Hate Background API makes it effortless to integrate professional-grade background removal.

With modern GPU acceleration and a robust backend, the API is built to handle production workloads while keeping response times low.

✅ Try it out

👉 You can check the docs and start experimenting here: I Hate Background API

Background removal made simple.
Fast, accurate, and developer-friendly.

See more in I Hate Background Official Website

I Hate Background!

Lucas Santos Rodrigues — Mon, 18 Aug 2025 14:14:15 +0000

I Hate Background! 🚫🖼️

Some time ago, I started exploring AI models for image processing. One of my biggest frustrations was always: "why is it so complicated to remove an image background in a simple and free way?"

That’s how I Hate Background was born → ihatebackground.com/

✨ With this tool, you can remove backgrounds from multiple images at once — just select everything and you’re done!

How does it work?

The system uses advanced AI models for image segmentation, trained on thousands of examples to identify what is background and what is the main object.

Processing happens in the cloud, hassle-free, and in just a few seconds you get the result ready.

Key Features

🔎 Batch background removal (no need to process one by one);
⚡ Simplicity: upload → process → save;
🌱 Open-friendly project, built to help designers, content creators, and curious minds;
💡 Built with Transformers.js and Hugging Face models.

What’s next?

I Hate Background started as a personal experiment, but now I’m expanding it into something truly useful for creators, freelancers, and companies dealing with images every day.

The roadmap includes:

An accessible API for integrations.

🔗 Try it for free: ihatebackground.com

I’d love to hear feedback from the community!

👉 What do you miss the most in current background removal tools?

I built a background remover that runs entirely in your browser using Transformers.js

Lucas Santos Rodrigues — Sun, 27 Jul 2025 23:26:05 +0000

I've always wanted to run AI directly in the browser — no servers, no API keys, just local, fast, and private.

Thanks to Hugging Face's Transformers.js, this is now totally possible. And I decided to test it by building a tool that many developers and content creators eventually need: a background remover.

It runs entirely in-browser, using Web Workers and modern JS — no sign-up, no data sent to a server.

⚙️ How it works

Transformers.js provides a simple pipeline for background removal. Here's all you need:

// Initialize the pipeline
const segmenter = await pipeline('background-removal', 'briaai/RMBG-1.4', { dtype: 'fp32' });

// Process the image
const result = await segmenter(imageURL);

// Done ✅ Use the result however you want

I chose the RMBG-1.4 model with fp32 to keep compatibility high across devices (especially CPU) while maintaining solid quality.

I turned this into a real app you can try instantly: Background free.

Want to explore the code? Here’s the source: Look at my GitHub canva-copy repository.

If you’re curious, I also posted about the process in the Hugging Face community: Discuss Thread.