I shipped an international dating app with real-time message translation in 50+ languages — here's the stack

Lovenly — Tue, 12 May 2026 06:51:41 +0000

I shipped Lovenly — an international dating app with live message translation in 50+ languages

A while ago, I watched a friend trying to date someone in Tokyo. He spoke no Japanese. She spoke no French. They were doing the DeepL copy-paste dance every night, switching tabs, breaking the flow. He told me "I don't even know if she's funny anymore — the translation kills the timing."

I'm a solo dev. I figured: real-time translation inside the chat shouldn't be a "premium" gimmick — it should be the product. So I built Lovenly (lovenly.online) — an international dating site where the messaging layer is the translation layer.

This post is the honest stack write-up. Brand new in production, so no big traffic numbers to wave around — just the technical choices and what bit me.

The stack

Layer	Choice	Why
Framework	Next.js 16 (App Router, RSC)	Server components let me query Supabase server-side without an API layer. Streaming for `/messages`.
DB + Auth + Storage + Realtime	Supabase (Postgres)	One vendor for the boring parts. RLS policies are non-negotiable for a dating app.
Styling	Tailwind v4	Fast. No CSS-in-JS overhead in RSC.
Translation	Anthropic Claude API (Sonnet)	Better idiomatic translations than Google/DeepL for short, casual messages with slang and emoji — especially FR↔JA, EN↔TH, RU↔ZH.
Payments	Stripe	Subscriptions + tax handled.
Hosting	Vercel (Hobby for now)	Fine until traffic explodes.
Push	Web Push + VAPID + service worker	Native push on iOS PWA + Android Chrome + desktop without paying OneSignal.

The whole thing is TypeScript strict with tsc --noEmit on commit hook.

Architectural decisions that mattered

1. A translation cache table, keyed by `(source_lang, target_lang, body_hash)`

Translation costs are real. A single match between FR and JA can rack up hundreds of messages. So I never translate the same message twice — even across different match conversations. bio_translations table caches every translation forever. The cache is more useful for bios than for chat (bios get re-viewed by many people, chat is unique), but the marginal cost of the table is nothing.

2. Live translation is server-rendered, not streamed token-by-token

I tried streaming. Looked great in dev. In production, the perceived latency was worse because users saw words appearing piecemeal and it broke the "this person sent a message" mental model. Final answer: send → server translates fully → render once. Faster feel even though same total time.

3. Onboarding is brutal on purpose

5 steps: account → preferences → photos (min 1) → bio → publish. Email confirmation + ≥1 moderated photo is required before any like or message can be sent or received. This kills a chunk of signups at the first photo step — and that's intentional. It also kills bots almost entirely.

For beta, I have an is_seed_bot flag with ~25 demo profiles per country to make the discovery feed not empty. They auto-decline matches, never message, never appear in "online now". Demo only, clearly marked in the schema.

4. Anti-scam pipeline lives in the `api_send_message` Postgres RPC

Before a row hits messages:

URLhaus check on every link
Regex scan for IBAN, BTC/ETH/USDT wallets, credit card numbers → blocked
Phone / email / Telegram / WhatsApp → flagged for client-side confirmation
~50 scam keywords (crypto, "wallet", "investment", "send me money") → flagged
Anthropic Claude toxicity assessment, score 0–10. ≥8 blocks. ≥5 flags.

Flagged messages auto-create a row in reports so moderators see them in /admin/signalements immediately. Shipped that one this week — was the missing link between the AI flag and the human review queue.

5. RLS is not "set it and forget it"

Every column-restricted table has a separate with check policy. Biggest gotcha I hit: auth.uid() returns NULL inside the SQL context for some legacy HS256 tokens, even when supabase.auth.getUser() returns a valid user. For sensitive writes the workaround is the service-role client server-side, but always re-verify photo.profile_id === user.id in TS before the write. Defense in depth.

Things I tried that didn't work

CDN-edge translation (Lingva, LibreTranslate): quality is fine for DE↔EN. For VI↔FR or KO↔FR it's unusable. Sticking with Claude.
Swipe-only UI: I built a Tinder-style swipe deck. Kept it as an opt-in mode. International dating users want to read profiles, not flick faces — so grid is the default.
Auto-translate on display by default: people who already speak both languages found it patronizing. Now it's opt-in per conversation with a one-click toggle.

What I'm doing right now

I'm running a launch promo: the first 100 sign-ups get 3 months of Lovenly Plus free (~€12 value). Hard cap, no extension. The counter is live on the landing.

Link: lovenly.online/first

If you're building something with i18n or messaging and you want to compare notes on Postgres RLS edge cases, Claude API caching strategies, or how I handle PII detection in chat — comments below. I read every one.

What's next

Voice messages with transcription + translation (Whisper → Claude → text + audio). Half done.
Match suggestions ranked by language compatibility (currently country + intent + age). Need to factor in shared language pairs.
AdSense Management API integration for the revenue dashboard widget (currently traffic-based estimation).

If you read this far, thank you. Shipped this thing alone, in production, with real users. It's terrifying. If you're doing something similar drop a link in the comments — I'd love to see it.

Cheers,
Gabriel — lovenly.online

DEV Community: Lovenly