Job at a glance
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