Backend / Server Developer

PROJECT CONTEXT We're building an app with an AI advisor as its main interface: users describe their skincare need in natural language, and the AI recommends freshly mixable cosmetics. The AI reasoning runs via the OpenAI API (EU instance, Ireland). Between the app and OpenAI, we want our own EU backend that controls consent, user memory, context minimisation and safety — so that long-term user knowledge stays with us and OpenAI receives only the minimum context needed per request. App development, AI conversation logic and content are staffed separately; we're looking for the backend/server side. TASK Build a modular backend service on an EU VPS that acts as the controlling layer between the app and OpenAI. This is expressly NOT just VPS setup and forwarding, but the following privacy and safety layers: API/Backend gateway — all app requests run through the backend; external API keys live server-side only. Consent & privacy layer — checks, before any processing/storage, which consents exist (separate flags for AI processing, health-data processing, health memory), including withdrawal, timestamps, versioning. Data model with three separated data classes — Account Data (identity/commerce) / AI Memory (preferences, formula history) / Sensitive Memory (special categories). Clear rules on what may be passed to OpenAI. Context builder / privacy proxy — before EVERY OpenAI call, assembles a minimal, purpose-bound context and removes unnecessary identifiers (the central privacy mechanism). Health-data protection — Beta: a signal-word filter that detects health terms before forwarding and handles them (block / map to a non-medical category). Term list maintainable separately from the code. The exact fork (map vs. transmit with consent) is set by our legal side — implement per their decision. AI provider connector — encapsulates OpenAI behind an internal interface (configure and document the EU instance/Ireland, check zero-data-retention, no training opt-in); provider swappable later (preparation for later self-hosting). Safety/compliance layer — checks AI outputs before display against a rule set we provide (no diagnosis, no healing claims, only approved formulas, ingredient limits). Memory writer — after conversations, writes back only structured, permissible facts (not the whole chat log). Deletion/withdrawal logic — across all storage locations (primary DB, caches, summaries), with a documented strategy for backups too. Event tracking (server-side part) — in coordination with the app developer on ONE shared event schema: link between shop order ↔ app account (critical), reorder + reorder_interval_days, cohort fields (purchase date, acquisition channel, device ID) on every event, churn signals. Not recoverable later — must be live at launch. TECH STACK (guideline, Beta) EU VPS or comparable EU cloud instance, properly hardened Docker / containerisation Backend service (modular monolith — layers logically separated, not necessarily separate servers) PostgreSQL TLS/HTTPS via reverse proxy Secrets management for API keys Backups, monitoring, access control Logging WITHOUT unnecessary prompt or health content MUST-HAVE SKILLS Solid backend development (e.g. Node/TypeScript, Python or comparable) with production database and API design (PostgreSQL) Experience with GDPR-relevant data processing: consent logic, data minimisation, deletion/retention concepts, access control Integration of external LLM APIs (OpenAI or similar), incl. retention/region config Server hardening, secrets management, TLS, reverse proxy, container deployment Clean, documented work (the backend must be extendable and handover-ready later) NICE TO HAVE Experience with AI/LLM privacy architectures (context building, PII minimisation) Handling of special data categories (Art. 9 GDPR) Shopify integration / e-commerce data flows (for the order–app link) Prior experience with later self-hosting of LLMs (not Beta, but the direction) EXPRESSLY NOT PART OF THE BETA Self-hosted LLM, complex vector database, extensive RAG, separate medical classification model, microservice architecture. (Comes later — but the architecture should not block it.) INTERFACES / HANDOVERS App developer: shared event schema; the app provides onboarding-funnel events, the server provides order/reorder/cohort events. Align early. AI conversation: the backend supplies the context, the conversation logic uses it. Legal side (internal DPO/lawyer + IT-law firm): provide the decision on the health-data fork; the safety rule set comes from the cosmetics safety assessor. The developer implements the specifications and does not make the legal decisions. EFFORT GUIDELINE ~7–12 developer-days for a solid Beta; 2–4 weeks for a tested, production-ready version — depending on the existing stack and safety requirements. SELECTION CRITERION (recommended) Have candidates comment on the architecture document. The right person independently asks the right questions — about the context builder, consent separation, deletion strategy across all storage locations, and OpenAI's EU/retention configuration. Anyone who just answers "set up a VPS and forward, no problem" has not grasped the actual task. DELIVERABLES Working, hardened EU backend service with all the layers above Documentation of the architecture, data flows and OpenAI configuration Evidence/documentation of the EU-instance and retention settings Tested deletion/withdrawal function across all storage locations Coordinated, working (server-side) event tracking