I built a $1 face search with Next.js 16, and my free demo mode was quietly costing me money

Serhii Lyzun — Wed, 21 Oct 2026 07:03:55 +0000

Hi DEV 👋 I'm Serhii, and this is my first post here.

For the last six months I've been building FaceSift, a small web app that does reverse face search: you upload a photo of a face and it shows where that face appears online. People mostly use it to check a dating match, to find out whether someone is using their photos, or to look up a profile that seems fake.

I don't run my own face recognition. FaceSift wraps the FaceCheck.ID API. What I built is everything around it: upload, consent, payment, result masking, and a lot of edge cases I didn't expect.

The stack:

Next.js 16 (App Router, Turbopack), TypeScript, Tailwind v4
Zod v4 to validate the vendor's API responses
MySQL on Aiven for orders and search state
NOWPayments for a $1 crypto payment per search
next-intl for 5 languages, heic2any for iPhone photos

I want to share three lessons from it. None of them is about face recognition. They're all about wrapping a paid third-party API, which a lot of us end up doing.

1. My "free" demo mode was spending real credits

FaceSift has a Demo / Live toggle. Demo is free and lets people see the flow before paying. The FaceCheck API has a demo: true flag, and the docs present it as a testing mode, so I used it for the free tier.

Then I checked the credit balance against my logs. Demo searches were spending the same 3 credits as live ones. Every visitor who tried the free mode was costing me money.

The fix was to stop calling the vendor in demo mode at all. The route returns a canned response after an artificial delay, so the UX still feels like a real search:

// app/api/search/route.ts
const DEMO_SEARCH_DELAY_MS = 3000;

if (requestedDemo) {
  await new Promise((resolve) => setTimeout(resolve, DEMO_SEARCH_DELAY_MS));
  return NextResponse.json(demoSearchResult); // static JSON mock
}

The upload route does the same thing. Demo mode returns a random UUID as the search id and never uploads the photo anywhere. A nice side effect is that demo users' photos now never leave my server, which is better for privacy too.

Lesson: don't trust a "test mode" flag on a paid API until you've compared your logs with the actual bill. I now log the remaining credit balance next to every live search result, so any drift shows up right away.

2. Fail closed on anything that costs money

My first version decided "demo or live" like this: if the client sends mode: "demo", use the demo path; otherwise use the live one. That's backwards. A missing field, a typo, or a hand-crafted request would end up on the path that spends money.

Now only an explicit "live" counts as live:

// Only an explicit "live" is treated as a credit-consuming request.
// Anything missing or unrecognized falls through to the free demo path.
const requestedDemo = body?.mode !== "live";

The second half of the same mistake: I originally checked payment only when deciding whether to mask the result URLs. By that point the vendor call had already happened. Anyone who replayed a request with mode: "live" could spend my credits and only get masked results back. The attacker gets nothing useful, but I still pay.

The payment check now runs before the vendor is ever called:

const row = orderId
  ? await getSearchByOrderId(orderId)
  : await getSearchByIdSearch(idSearch);

if (!getIsPaidStatus(row?.payment_status)) {
  return NextResponse.json({ error: "Payment not confirmed" }, { status: 402 });
}

const data = await searchOnce(idSearch); // only reached when paid

Yes, HTTP 402 Payment Required is a real status code, and I finally had a reason to use it.

3. "One payment = one search" with a single UPDATE

Every $1 payment buys exactly one search. Users refresh, open two tabs, hit back after paying, and the payment webhook can arrive before or after they return from the checkout page. I didn't want a queue or a distributed lock for a $1 product.

It turned out one conditional UPDATE covers it, because MySQL applies it atomically to the row:

const [result] = await mySqlPool.execute<ResultSetHeader>(
  `UPDATE searches
     SET id_search = ?, payment_status = 'finished'
   WHERE order_id = ?
     AND id_search IS NULL
     AND payment_status IN (${PAID.map(() => "?").join(",")})`,
  [idSearch, orderId, ...PAID]
);

if (result.affectedRows > 0) {
  return { linked: true, alreadyLinked: false };
}

If two requests race, only one of them gets affectedRows === 1. The other sees 0 and is told the credit was already used. The payment_status IN (...) condition also means a partially paid or expired order can never be linked by mistake, whichever code path gets there.

I use the same pattern to mark a search as in_progress. That update also reclaims searches stuck in_progress for more than a few minutes, so a crashed request doesn't burn someone's dollar forever.

A note on ethics

A face search tool can be misused, and I think about that a lot. FaceSift shows a consent screen before any upload. Users have to confirm they're 18+, that they won't use the results to harass, stalk or harm anyone, and that face search is legal where they live. Demo mode never sends the photo to the vendor at all. I'd really like to hear how others building in sensitive areas approach this, because I don't think I've got it all figured out.

What's next

Next I want to write about:

sending GA4 events from a payment webhook without losing the buyer's session, using the Measurement Protocol and after() from next/server
fixing Core Web Vitals when a third-party web component was my LCP element

If you're curious, the app is at facesift.com. Demo mode is free and, as you now know, really doesn't cost anything 😄