Founding Data and Backend Engineer

You own the data substrate and the batch runtime of a product we are building from scratch. This is a data-specialist seat, not a general backend seat. Routine application development is guided in weekly reviews; what cannot be substituted is your depth in data modelling, set-based computation, and pipeline correctness. You will work self-directed, writing your own specs and decisions, with your tests and documentation carrying the quality bar between reviews.

Responsibilities:

• Third-party data ingestion, done deeply. Webhooks drop silently, so reconciliation against source-of-truth totals is not optional.
• Batch computation over large datasets as set-based SQL, inside fixed nightly windows.
• Multi-tenant isolation as a reliability property. One tenant's bad data must never degrade another tenant's run.
• Backfill and replay as designed capabilities, not emergency scripts.
• Append-only, auditable records. Every automated decision must be reconstructable.
• Vendor API integrations built for failure: circuit breakers, retries, reconciliation.
• The operational substrate: alerting, partitioning, idempotent jobs.

Requirements:

• Around 5 to 8 years building and operating production systems. Years are a proxy; the points below are the bar.
• Deep Postgres: schema design, query plans, batch performance at real scale.
• You have owned data pipelines in production: ingestion, transformation, reconciliation, serving. Not application CRUD against an ORM. Moving and reshaping data is the job you have actually done, whatever your resume calls it.
• You think in sets, not loops. Multi-step SQL transformations, window functions, statistical aggregates (percentiles, distributions), and incremental computation are your native mode, and you have turned raw event or order data into cohort, retention, or funnel metrics.
• Production Python backend experience in any framework. You keep business logic cleanly separated from framework details, which is exactly why the framework does not matter.
• Tests are how you build, not what you add later. Batch jobs and reconciliations especially, where a bug means silently wrong data for weeks.
• War stories: queues backing up, webhooks silently dropping, reconciliations catching data loss nobody noticed.
• Strong written communication. This is a documentation-driven team, and the way we build runs on written specs and decisions.
• Comfortable owning outcomes and building from scratch with minimal supervision.

Good to have:

• Production Django.
• E-commerce or D2C platform experience.
• Streaming or event-architecture experience (Kafka-class systems).
• Familiarity with probabilistic data structures (HyperLogLog, Bloom filters, t-digest).
• Comfort building the occasional server-rendered screen.
• Stack: Python, PostgreSQL, Django, server-rendered frontend (htmx).