Senior Data Engineer — Postgres, PostHog, SQL | Product & Revenue Analytics | Education Saas

We're a mobile and web language-learning app teaching heritage languages to diaspora communities. We're small, profitable enough to be picky, and moving fast. Our product works. Our data layer is what's holding us back. We're looking for one exceptional data engineer to own it — part-time, ongoing, long-term. The honest situation The app grew fast and the database grew with it, unevenly. User profiles and lesson progression live in Postgres alongside events, subscriptions, and experiment assignments. Some of that schema is clean. Some of it is the result of shipping fast, and it shows: inconsistent state on progression records, joins that should be trivial and aren't, and a handful of tables where the source of truth is ambiguous. We're not looking for someone to rewrite everything. We're looking for someone who can diagnose precisely, fix surgically, and then build the reporting layer we should have had a year ago. What you'll actually do Fix the database where user progression and profiles live. Audit the schema, find the integrity problems, propose the smallest correct fix, write the migrations and backfills, and add the constraints and checks that stop the problem recurring. You'll work with our backend engineers on anything that touches application code. Build dashboards we trust. Retention and cohort curves, activation and onboarding funnels, revenue and churn, lesson and content engagement, experiment results. Not vanity charts — dashboards that a founder can open at 7am and make a decision from. Answer hard questions with SQL, fast. "What's D30 retention for users who started with Pashto and hit the paywall in variant B, excluding anyone on a legacy price ID?" You should find that question fun, not frightening — and you should be the kind of person who tells us when the number we asked for isn't the number we actually need. Lay the pipeline foundation. Reliable, modeled, documented tables that join our product data to our payment and analytics sources, so every future question doesn't start from raw tables. dbt or an equivalent approach — we're open on tooling, opinionated on rigor. Our stack Database: Postgres (Neon), accessed via Drizzle ORM Backend: Node.js / TypeScript / Express Frontend: React (web), React Native / Expo (iOS + Android) Payments: Stripe (web) and RevenueCat (mobile) — subscriptions, trials, dunning Product analytics & experiments: PostHog (server-side flag evaluation, persisted variant assignments) Marketing/attribution: GA4 Measurement Protocol, Meta CAPI, UTM short-links, first-touch attribution Email: Brevo Infra: Replit Autoscale, Cloudflare R2 for backups Internal events: a business_events table capturing money-moving events You do not need to have used every one of these. You do need deep Postgres and SQL, and real experience joining subscription/billing data to product data without producing garbage. What we need from you 5+ years doing this work seriously. Senior means you've cleaned up someone else's data model before and know how to do it without breaking production. Expert SQL. Window functions, CTEs, query plans, indexing. You can explain why a query is slow and then make it fast. Postgres depth: migrations, constraints, transactions, backfills on live tables, and the judgment to know when a change is safe. Experience modeling subscription revenue — MRR, churn, trials, refunds, proration, failed payments. Bonus if you've reconciled Stripe and RevenueCat in the same model and know exactly why that's harder than it sounds. BI/dashboard chops in whatever tool you're strongest in (Metabase, Superset, Looker Studio, Hex, Preset, or well-built custom). Comfortable reading TypeScript to understand how data gets written, even if you're not writing app features. You write clearly. You'll be sending us analysis we act on, and we need the assumptions labeled as assumptions. Nice to have dbt or similar transformation framework PostHog specifically, including experiment analysis Python for one-off analysis and scripting Experience at an early-stage consumer subscription app Logistics Part-time and ongoing: 10–15 hours/week, long-term. This is not a one-off project — we want someone who gets to know our data and stays. Hours: You must have at least 3 hours of daily overlap with US Pacific time (UTC-7/-8). Worldwide otherwise. Communication: Strong written English required. You'll be writing analysis the founders read directly. Access: Read-only access to start. Write access to the database after we've worked together and you've earned it. How to apply Skip the template. Applications that open with "I am a highly skilled data engineer with a passion for" get archived unread. Instead, answer these four things in your proposal: Describe a specific database you inherited that was in bad shape. What exactly was wrong, what did you change, and how did you avoid breaking things? You need to report monthly churn for a subscription app where some users pay through Stripe and some through an app store via RevenueCat. Walk us through how you'd model that. What are the three ways this typically goes wrong? What BI tool would you set up for a team of our size and why? What would you refuse to build? Name one dashboard that most startups build that you think is a waste of time. Include one example of a dashboard or data model you're proud of (screenshot with sensitive data redacted, or a description if you can't share). We move fast on good applicants. First conversation is a 30-minute call, then a small paid trial task against real data before we commit to the ongoing arrangement.