Senior Backend Engineer (Python)

When our state machine is wrong, somebody's money is wrong. That is the entire job description.

Why this role exists

When our state machine is wrong, somebody's money is wrong. That is the entire job description. Supero's core is a set of Python services holding other people's transactional data - orders, payments, inventory, claims, signatures, ledgers - and we need engineers who find that stake motivating rather than terrifying.

What you'll own

• The transactional services. Cart and order. Payment authorize → capture → refund → void. Two-phase inventory reserve-and-commit. Subscriptions with dunning. A double-entry loyalty ledger. Multi-signer e-signature. Approval chains with delegation. You would extend these and make the invariants hold under concurrency - which is the whole job, because when the state machine is wrong somebody's money is wrong.
• Saga compensation - the honest version. An invalid transition is rejected before it mutates anything and returns a 409: that part works and it is real. Compensation - walking a half-finished saga back - is the part that is not finished. It is opt-in per workflow, and a contract suite we keep deliberately red reports broken compensation templates where one wrong key name does not degrade a single step, it abandons the walk-back for every earlier step too. Closing that is one of the two most valuable things an engineer could do here this year.
• Idempotency and correctness. Invoked twice, applied once, because the idempotency key really is a unique partial index and not a hope - the insert itself is the gate, and the race surfaces from the database as a 409.
• The multi-tenant data path. MongoDB (Atlas in production) behind a pluggable backend interface, plus a PostgreSQL backend that models every object of every tenant as one partitioned objects table with a single JSONB document column and no per-schema DDL. Tenancy is carried as the record's address either way. Most teams would have gone schema-per-tenant; we did not, and you will have opinions about that.
• The MCP server. The surface an outside AI agent drives to build on Supero. Every tool you add needs an authorization story, not just a handler - an agent holding a scoped key must not be able to reach past what that key covers. It is the most interesting security problem in the building.

What we look for

• 5+ years of production backend engineering, with real scars from distributed systems: partial failure, retries, ordering, exactly-once fantasies.
• Deep Python - across two eras of it. The newer services (AI, connectors, billing, tenant, analytics) are FastAPI, Pydantic and asyncio. The core API server and control plane are Bottle on gunicorn/gevent - synchronous, greenlet-based, with hand-rolled validation and not a line of async def. You would work in both, and help move the boundary. If that sounds like the interesting part rather than the bad news, good.
• Databases past the ORM. Query plans, isolation levels, indexing strategy, and what a long-running transaction does to everyone else - against MongoDB in production and PostgreSQL/JSONB in the alternate backend and across the connector fleet.
• API contract discipline. You have designed the error responses on purpose. You return 409 rather than 500 and you can say why.
• AI and MCP at depth. This is one of three roles where MCP is a real requirement rather than a curiosity - you would be building the surface that agents drive.

Nice to have

Multi-tenant SaaS at scale. Payments or ledger systems. Having written an MCP server. Having found a security bug in something you owned and written the honest RCA. Event streaming - we have Kafka scaffolding that has never been lit up, and an opinion about whether it should be is welcome.

Your first 90 days

• Weeks 1-2. Ship a fix to a live service. Read the 111-file contract suite until you can say what it does not cover.
• Weeks 3-6. Own one transactional service end to end.
• Weeks 7-12. Take a state machine that is under-tested and close it - with the test that discriminates against the old behaviour, not the one that passes either way.