Senior Python Backend Engineer / Infrastructure Architect

We have an existing B2B SaaS platform built with Next.js, Supabase/PostgreSQL, Stripe, and Vercel. The application is already in production with several organisations using separate workspaces, and we are preparing to onboard more customers. As part of a recent security and reliability review, we identified several areas where the Backend has grown organically with the product and now needs a more deliberate architecture. This is not a greenfield build and we are not looking to rewrite the application. We are looking for a senior Backend engineer who can review the existing architecture, identify the important reliability and security risks, and help us establish a stronger Backend foundation before customer volume increases. Current Stack - Next.js / TypeScript - Supabase / PostgreSQL - Supabase Auth and RLS - Stripe subscriptions - Stripe webhooks - Vercel We are open to introducing Python / FastAPI for Backend services where it provides a clear architectural benefit. Our tenant model is approximately: `organisation → members → projects → records` Users may belong to multiple organisations, with owner, admin, and member permissions. The Problem Most of the application originally communicated directly with Supabase, with some privileged operations later added through Next.js API routes and server actions. As the product has grown, we now have business-critical operations involving organisation provisioning, permissions, billing, subscription state, and other privileged workflows spread across different parts of the application. We are concerned that too much responsibility currently sits inside the application/API layer without a clearly defined Backend trust boundary. We have also started seeing reliability issues around asynchronous operations. The most visible example is Stripe. Stripe webhooks update subscription state stored against an organisation. During testing, replaying and retrying webhook events resulted in our PostgreSQL subscription state becoming inconsistent with Stripe. We manually corrected the affected record, but we do not want to rely on manual intervention as customer volume grows. We need someone who can investigate the underlying architecture rather than simply patching the individual webhook. What We Need Reviewed Backend Architecture Review the current API routes, server actions, database access patterns, and privileged Supabase operations. We want to understand: - Which operations should remain protected directly by PostgreSQL RLS - Which operations should go through controlled Backend services - Where service-role access is currently used - Whether client-supplied organisation/project IDs are being trusted in privileged operations - Whether tenant context is consistently derived from authenticated identity - Whether business-critical operations should be moved out of the Frontend/Next.js application layer - Where transactional boundaries are currently missing We are particularly interested in avoiding a situation where a privileged server-side Supabase client unintentionally bypasses the tenant protections established by RLS. Stripe & Billing Reliability Our Stripe integration needs a deeper reliability review. Please review: - Webhook signature verification - Event persistence - Duplicate webhook delivery - Idempotent event processing - Out-of-order events - Retry behaviour - Customer/subscription → organisation mapping - Upgrade/downgrade/cancellation transitions - Failed and recovered payments - Concurrent subscription updates - Protection against stale events overwriting newer billing state - Reconciliation between Stripe and PostgreSQL We would like the billing state in our database to be recoverable and deterministic even when Stripe retries or delivers events in an unexpected order. Background Processing Some operations currently happen synchronously during API requests or webhook execution. We would like you to identify which operations should move to asynchronous processing. Depending on the findings, this may include introducing a lightweight worker/queue architecture for: - Stripe event processing - Billing reconciliation - Organisation provisioning - Notifications - External integrations - Scheduled maintenance tasks We are open to Redis/Celery, SQS, or another appropriate architecture. We care more about operational simplicity and reliability than introducing infrastructure unnecessarily. PostgreSQL / Data Integrity We also want the Backend reviewed from the database perspective. This includes: - Transaction boundaries - Foreign-key and uniqueness constraints - Tenant-aware data integrity - Race conditions - Idempotency keys - Organisation ownership relationships - Privileged database functions - SECURITY DEFINER functions where appropriate - Auditability of important state changes RLS is already being reviewed separately, so this role is not simply an RLS audit. We need someone who understands how PostgreSQL security, application authorization, and privileged Backend operations should work together. Observability & Recovery One concern from the Stripe issue was that we discovered the inconsistency manually. We would like better visibility into critical Backend workflows. Please review or recommend: - Structured logging - Webhook processing history - Failed-job tracking - Retry visibility - Error monitoring - Correlation IDs - Audit logs - Health checks - Alerting for unrecoverable failures The goal is to know when a critical workflow fails rather than discovering corrupted or stale state later. How We Would Like to Start Please do not immediately rewrite or migrate the Backend. We would prefer to begin with a short architecture review. First, review the existing: - Database schema - Backend/API routes - Server actions - Supabase access patterns - Service-role usage - Stripe integration - Deployment/infrastructure - Current error handling and logging Then provide a concise technical assessment covering: 1. Critical Backend/security risks 2. Billing and asynchronous-processing reliability issues 3. Database/data-integrity risks 4. Recommended architecture changes 5. What should be fixed immediately 6. What can remain as-is for now After we agree on the findings, we would like you to implement the critical changes. We prefer incremental improvements over unnecessary rewrites. Ideal Experience We are looking for someone with strong production experience in: - Python - FastAPI - PostgreSQL - Supabase - Multi-tenant SaaS architecture - Stripe Billing / webhooks - REST APIs - Background jobs / queues - Redis and/or AWS messaging infrastructure - Docker - AWS or comparable cloud infrastructure - Authentication and authorization architecture - Production monitoring and reliability Experience working on existing SaaS applications that already have customers is more important to us than building greenfield prototypes. When Applying Please briefly describe: 1. A production multi-tenant SaaS Backend you have worked on and how tenant boundaries were enforced. 2. A payment or webhook system where you had to handle duplicate events, retries, or inconsistent state. 3. How you would design Stripe webhook processing so that replaying the same events cannot corrupt the current subscription state. 4. How you decide whether business logic belongs in PostgreSQL/RLS, an API service, or an asynchronous worker. Please also mention the Python Backend stack you are most comfortable working with. No agencies, please. We would prefer to work directly with the engineer reviewing and implementing the architecture. Deliverables - Backend architecture review - Review of privileged Supabase/database access - Stripe webhook reliability assessment - Recommended Backend architecture - Implementation of agreed critical fixes - Background processing/retry architecture where necessary - Automated reliability and tenant-boundary tests - Logging/monitoring improvements - Brief technical documentation If the initial architecture review goes well, we expect additional Backend and infrastructure work as we continue onboarding customers.