Backend Platform Engineer (AI & Python)

Close runs on Python: Flask web apps, TaskTiger, billions of MongoDB documents, a public REST API that customers and external agents both build on. Four product teams ship features on top of that every week. Backend Platform owns the layer underneath them.

The work is building for other engineers. When a product team adds a new API endpoint, most of what they write isn't their feature — it's wiring: authentication, permissions, rate limiting, the shape the endpoint has to take so it looks like every other endpoint when you squint. Multiply that across telemetry, eventing, database migrations, authorization, and local development, and you get the problem this team exists to solve: make the paved road faster to walk than the trail.

The other half of the team's mandate is the AI development platform. We've built DevDawg, cloud-based development environments preconfigured for our entire application stack and our engineering practices, and Spice, our extension layer on top of a coding agent that runs internal review workflows and root cause analysis. Spice is hooked into GitHub and can already approve mergeable pull requests on its own for simple changes. Expanding what it can safely handle is squarely this team's work.

This is a new team. You would be one of the first hires, and you'd have unusual influence over what the team owns and how it works.

One thing to know up front: we do move people between teams as the work shifts. Most engineers here end up on more than one team over their time at Close — this team is where you'd start, but over time you'll likely have the opportunity to work on many different projects.

This role is open at the Senior and Staff levels. You don't need to pick one when you apply: we'll calibrate together during the process.

You are

• A seasoned Python engineer. Python is our backbone and it matters here more than on most teams — architectural patterns don't port cleanly between languages, and you'd be setting the patterns. Go, Rust, or TypeScript alongside it is welcome.

• Drawn to meta-problems. This team doesn't ship features to customers; it changes how features get built. You like reasoning one level up: what pattern should exist, what decision should nobody have to make twice, what should be impossible to get wrong.

• AI-native in production. You've shipped meaningful LLM-backed or agentic work to real users. For a team building AI tooling that other engineers depend on, this isn't a nice-to-have.

• Working with AI in your day-to-day. You use coding agents in your own workflow and have a real POV on where they help and where they get in the way — because here, that POV becomes the product. We fund best-in-class developer tools and treat experimentation as part of the work.

• Fluent in observability and production practice. Telemetry, metrics, tracing, alerting, Sentry ownership, what production-ready actually means. You've been the person who made a system legible when it broke.

• Opinionated about API design. You've shipped internet-facing APIs and you think about who's on the other end — apps, agents, humans reading docs — and what each needs.

• Battle-tested. You've debugged incidents where latency budgets didn't hold, owned a system everyone else relied on, or carried a pager for something with real customer impact.

• A builder first. You'd rather get a rough v1 in front of five engineers than spend three weeks on abstractions nobody asked for. Adoption is the measure, not elegance.

• Energized by internal customers. Your users sit in your Slack. You'll talk to them directly instead of through a PM, and you'll use most of what you build yourself.

You will

• Expand DevDawg and Spice. Cloud development environments for our full stack, paired with automated review and root-cause tooling that can approve real pull requests. Making that safe enough to cover more of our review surface is one of the team's biggest single bets.

• Build the paved roads for our API layer. REST blueprints, GraphQL schema, OpenAPI, realtime, and the auth and permission plumbing that every endpoint needs. Consistent patterns are what make shared utilities possible in the first place.

• Modernize the backend framework layer. Web and async compute frameworks, performance, and migration paths (Flask → FastAPI, among others) — with clear defaults, examples, and migrations teams can adopt without asking permission.

• Own how we see production. Observability, metrics, alerting, and the readiness bar teams meet before shipping. When the same issues keep showing up in incident reviews, you make sure the underlying cause gets owned rather than re-triaged.

• Ship shared backend services and primitives. Eventing patterns and the event log, database-change safety and migration guardrails, delegated access and auditability, the internal admin framework and support-facing APIs.

• Set the guardrails for coding agents in our backend. Static analysis, linting, hooks, test harnesses — the constraints that make agent-written code safe to merge at volume.

• Partner across the org. Infrastructure owns the substrate (AWS, Kubernetes, datastores); you own the application layer on top.

Tech you'll touch: Python, Flask, FastAPI, GraphQL, TaskTiger, Rust, TypeScript, Kafka, Redis, MongoDB, PostgreSQL, Elasticsearch, Docker, Kubernetes, GitHub Actions — plus whatever coding agent ships next.