Zan - Zari Group

Shalem is a React Native/Expo app (Supabase backend, Anthropic Claude for content generation) currently shipping English-only. Story content is being translated separately; this role owns making the app itself function correctly in additional languages — UI, content delivery, AI-generated text, and audio.

What you'll actually be doing

• Extract ~150 screens/components' hardcoded English strings into a proper i18n catalog (react-i18next or similar) and build a working language switcher (the current Settings → Language screen is a non-functional stub)
• Wire the existing but unused translations JSON field on the stories table into every place that serves story content (match-stories, create-sharing, deliver-path-day Supabase edge functions)
• Add a stored user-language preference and thread it into the Claude prompts that generate reflections, bridge text, and Path day content, so AI output responds in the user's language
• Evaluate and implement a strategy for semantic story matching across languages (currently English-only OpenAI embeddings) — either per-language embeddings or a hybrid English-match/localized-display approach
• Coordinate per-language ElevenLabs audio generation for the app's 4 voices and QA the output
• Localize push notification, email, and in-app subscription/cancel-flow copy
• Test end-to-end in each target language before rollout

Required skills

• React Native / Expo — strong, hands-on (this is not optional; most of the work is here)
• TypeScript across a real codebase, not toy projects
• Supabase (Postgres, RLS, Edge Functions in Deno/TypeScript)
• Experience shipping i18n in a mobile app — string extraction, locale switching, RTL/formatting edge cases
• Comfortable working with LLM APIs (Anthropic Claude) — prompt structure, not model training
• Git workflow discipline; ability to work from a spec without heavy hand-holding

Nice to have

• Experience with OpenAI embeddings / vector search (pgvector)
• ElevenLabs or other TTS API integration
• RevenueCat
• Hebrew or other RTL language familiarity (bonus given the app's content domain)

Application process

Candidates who pass the initial interview will be asked to complete a take-home technical assignment before an offer is made:

• A small sample React Native/Expo repo with ~10 screens, requiring you to: wire up i18n, extract hardcoded strings into an English + Spanish catalog, build a working language switcher, and connect it to a Supabase field storing translated content.
• The deliverable must run on a physical device or a real device build (EAS dev build / expo run:ios / expo run:android) — an Expo Go simulator screenshot or recording will not be accepted. Submit a screen recording of the language switch working on that build, plus a PR with your code.
• Expected time: 3–5 hours.
• This assignment is unpaid and is the final step before an offer decision.

This is a backend role. You won't build screens, and you don't need frontend experience. The mobile team will add a language picker and pass a locale to the backend. Everything behind that is yours: the data model, content pipelines, LLM generation, retrieval, audio, notifications, and making sure all of it holds up in production.

What you'll build

1. The language data model

• Design how language lives in the database: user language preference, per-story translations, fallback chains (e.g. pt-BR → pt → en), and versioning so a translation is marked stale when its English source changes.
• stories.translations (jsonb) already exists and nothing reads it yet. Decide whether it stays, or whether we move to a dedicated story_translations table, and write down why.
• Everything ships as new, reversible migrations. We never edit an existing migration.

2. The content translation pipeline

• Our library has already been translated into several languages using the Anthropic Batch API, with a two-pass generate-then-review process. Move this into the repo so it's idempotent, re-runnable and cheap, and so it handles only the stories that changed.
• Build a glossary and style layer: Hebrew terms, names of sages and sources, and terms that must never be translated. Add automated QA checks (completeness, glossary adherence, length drift, broken formatting) plus a sampling workflow for native-speaker review.

3. Generation in the user's language

• Reflections, bridge text, the three practices (Echo, Naming, Walking) and Path arcs are generated by Claude through shared prompt modules in our Supabase edge functions. Make them produce native, natural output in the target language. That means writing in the language directly, not translating English after the fact. Our existing rules must still hold, e.g. each practice carries a Hebrew term with its meaning explained, now explained in the user's language.
• Build a per-language evaluation harness so we can check quality before a language goes live and catch regressions when prompts change.

4. Multilingual matching

• Today, language-validation detects the language of the user's input and blocks anything that isn't English. Replace that gate with detection and routing.
• Story matching uses OpenAI text-embedding-3-large over pgvector. Measure how well non-English input retrieves the right English-indexed stories. Then decide between cross-lingual matching, per-language embeddings, or a hybrid, and back the decision with numbers.

5. Audio

• Stories and reflections are read aloud by ElevenLabs voices. Audio is currently stored per voice (audio_urls), so it has to become per voice and per language. Pick voices for each language, and plan batch pre-rendering, storage, cost and backfill.

6. Server-side copy

• Move push notification copy (including our Shabbat-aware scheduling), transactional and lifecycle emails, and database-driven home-screen messages out of the code and into a locale-aware string system with proper plurals and date formats.

7. Safe rollout

• Several app versions are live at the same time, and older builds can't be changed. Every change you make must stay backward compatible: English stays the default, current RPC signatures stay the same, and each language can be switched on independently behind a flag.
• Track cost and quality for each language: tokens, TTS credits, fallback rate and generation failures.

Our stack

• Backend: Supabase: Postgres (RLS, RPCs, pgvector, jsonb, pg_cron) and 50+ Deno/TypeScript edge functions
• AI: Anthropic Claude (Messages and Batch APIs, prompt caching), OpenAI embeddings, ElevenLabs TTS
• Data/scripts: Python and Node
• Other: RevenueCat, Resend, Expo Push/FCM. The app is Expo/React Native, but you won't need to work in it.

You'll be a fit if you have

• 5+ years of backend engineering, with strong PostgreSQL: schema design, migrations on live data, RLS, stored functions, and performance tuning.
• Production TypeScript (Deno or Node) and solid Python for data pipelines.
• Shipped LLM features to production, beyond prototypes: prompt design, structured output, batch processing, cost control, and above all evaluation. You know how to tell whether output in a language you don't speak is good.
• Built backend internationalization before: locale negotiation, fallback chains, ICU/CLDR plurals and dates, and translation workflows with versioning.
• Worked with embeddings and vector search, and can design a retrieval evaluation.
• Care about keeping production running: backward compatibility, feature flags, and rollouts that can be undone.
• Write clearly. Decisions here get written down before they get built.

Nice to have

• Experience with ElevenLabs or other TTS pipelines.
• Supabase-specific experience.