Software Engineer L2 - Provider Network & Real-Time Payments Platform

Valid8 Financial, Inc.; Austin (TX); On-site; USD 150,000 - 230,000; Full time

Job summary

Curative is hiring a forward deployed software engineer to own the provider network platform—the core system that determines which providers a member can see and how payments are handled. You will build, test, and scale ingestion pipelines, matching logic, internal APIs, and admin tooling in a fully remote role.

You will partner with network operations, member services, and product teams to turn requirements into shipped software, set architectural direction, own production, and enable

Qualifications

• 5+ years shipping production software.
• Fluent in Python and TypeScript for large services.
• Strong SQL and relational database fundamentals.
• Experience building data-intensive applications with messy data.
• Comfort with matching/deduplication problems.
• Production cloud experience (AWS, GCP, or equivalent).
• Able to work with non-technical stakeholders and write clear prompts and specs.
• AI-first working style with ability to review AI-generated diffs.

Responsibilities

• Own the provider network platform end-to-end, including ingestion pipelines, matching logic, internal API, and admin tooling.
• Review AI-generated diffs and ensure correctness in production.
• Collaborate with network ops, member services, and product stakeholders to turn requirements into shipped software.
• Define architectural direction and production ownership, with emphasis on latency and reliability.
• Extend and build AI agents to scale operational workflows.

Skills

Production software

Python

TypeScript

SQL

React

Data-intensive systems

Latency and availability

AWS or GCP

AI-first mindset

Code review of AI output

Tools

Python</TypeScript

Job description

Curative is building the future of health insurance with a first-of-its-kind employer-based plan designed to remove financial barriers and make care truly accessible: one monthly premium with $0 copays and $0 deductibles*. Backed by our recent $150M in Series B funding and valuation at $1.275B, Curative is scaling rapidly and investing in AI-powered service, deeper member engagement, and a smart network designed for today’s workforce.

Our north star guides everything we do: healthcare only works when people can actually use it. That belief drives every decision we make: from how we design our plan, support our members, to how we collaborate as a team.

If you want to do meaningful work with a team that moves fast, experiments boldly, and cares deeply, Curative is the place to do it. We’re growing fast and looking for teammates who want to help transform health insurance for the better.

Summary

We are hiring a forward deployed software engineer to be the technical owner of our provider network platform — the core system that decides which providers a member can see, and what happens when that member pays one directly. We pull provider data from many different sources, each with its own gaps and quirks, and turn it into one trustworthy picture of our network: who a provider is, where they practice, and whether they are in network. But not all care fits neatly into a claim: when a member needs to pay a provider directly, they
use their Curative Cash Card, and our platform is what determines, in real time, whether that transaction is covered. You will sit at the intersection of engineering, network operations, and member support — embedded with the people who use the software, not insulated from them. You will hear directly when a provider’s data is inaccurate or a member cannot get care, and ship the fix the same day. You will also monitor data quality, match accuracy, decision latency, and the overall member experience of accessing care. You will be the single technical point of responsibility for this platform. You will partner with network, operations, and product stakeholders to turn their processes into shipped software, set the architectural direction, own production, and represent it in cross-team discussions. A big part of the job is building AI agents that streamline and scale operational workflows.

How we build

At Curative, AI writes most of the code. Engineers direct it. We use agentic AI coding tools as the primary development surface. A senior engineer here routinely runs multiple agents in parallel — one implementing a feature, one resolving review comments, one chasing down a flaky test. The engineer’s job is to set context, make the decisions the AI cannot make, and keep the bar high on what ships. This is not a role for someone who wants to hand-roll every line. It is also not a role for someone who will accept whatever the AI produces. We are looking for the engineer in between: strong enough fundamentals to catch a wrong answer in a few seconds, disciplined enough to review every diff, and ambitious enough to drive several times the output of a traditional IC. On a surface that both defines what the rest of the company believes about our network and runs live at the point of care, that discipline matters more than usual. Strong systems and architecture thinking is important, as is product taste. This is a fully remote position.

What you’ll own

The codebase. Full-stack Python and TypeScript services with genuine data weight and domain complexity — ingestion pipelines, matching logic, an internal API, and the admin tooling operations teams work in every day. You own code review, architectural decisions, and the quality bar. Most commits will be AI-authored, human-directed, human-reviewed. All of them are yours.

The data. Getting messy third-party rosters into one canonical, trustworthy network picture — and keeping it that way. You own the pipelines, the provenance, and the checks that catch a bad file before anyone downstream sees it.

Matching and identity. Deciding when two records are the same provider, and when the business on the other end of a transaction is one we cover. Merge too eagerly and a member is told an out-of-network provider is covered; too cautiously and the data fills with duplicates or we deny care weshould have approved. Tuning that tradeoff, and defending it, is the heart of the role.

The real-time path. A live decision service where latency and uptime are not nice-to-haves — a bad deploy means a member standing at a front desk gets turned away. You own the SLOs, the safeguards, and the discipline of proving a logic change is right before it goes live.

AI leverage. The tooling, prompts, skills, and evals that let one engineer run a surface this size, along with the agents that do operational work on top of it. You will extend the agents we already run in production and build new ones for the review, approval, and triage the team handles by hand today. This is some of the highest-leverage work on the platform, and it is yours end to end.

The internal API. Other teams build on your answers. Your contracts are their dependencies, and your regressions are their incidents.
Detecting misuse. Spotting the patterns that suggest a card is not being used the way it was meant to be, and building the workflow to act on them. Most of this does not exist yet, so you will be designing it rather than maintaining it.

Production. Cloud infrastructure, deploy pipeline, migrations that are safe against a live service, observability, on-call, incident response, and cost. Sensitive data. This platform touches PHI and payment information. You own handling it responsibly, with data-privacy discipline baked in rather than bolted on.

Operational metrics. You watch how the platform performs for the people who depend on it, surface what the data shows, propose changes, and close the loop.

Stakeholders and roadmap. You are the engineer in the room with network ops, member services, and the teams that consume your API. You co‑own the plan, push back when a request will not solve the real problem, and argue for what nobody has asked for yet.

The domain. You will not arrive an expert in provider networks, but within 90 days you will understand the workflows well enough that every prompt you write is loaded with the right context.

What we’re looking for

Foundational skills (non‑negotiable)

You need these because you are the last line of defense on what the AI produces. The bar is not “can write it from scratch in an interview.” The bar is “can read a 400‑line AI‑generated diff and spot the subtle bug in 90 seconds.” On this surface, that bug is often a matching rule that quietly gets it wrong, a migration that is unsafe against a live service, or a query that was fine on dev data and falls over in production.

5+ years shipping production software. Enough reps that you recognize bad code before you can articulate why.

Real fluency in Python and TypeScript. Not “I can read it,” but fluent. You should be at home in a large, long‑lived service and care about keeping it that way.

Enough TypeScript and React to own a frontend. The platform ships internal applications that operations teams live in. You do not need to be a frontend specialist, but these are yours, and the people using them are your stakeholders.

Strong SQL and relational database fundamentals. You can read a query plan, spot an N+1, know when a migration is unsafe at scale, and reason carefully about the joins and aggregations that decide what a record ends up being. You assume every table grows unbounded, because here it does.

Experience building data‑intensive applications. You have built systems that ingest, transform, and reconcile meaningful volumes of messy third‑party data, and you care about getting it right rather than just moving it.

Comfort with matching or deduplication problems. Record linkage, entity resolution, search relevance, identity matching — any domain counts. The interesting part is not the algorithm; it is knowing what a false match costs versus a missed one, and being able to defend where you drew the line.

Experience running something where latency and availability mattered. A request path with a real deadline, an SLO you were accountable for, and the instincts that come with it: timeouts, caching, graceful degradation, kill switches, and careful rollouts.

A correctness mindset. You instinctively reach for the checks, invariants, and audit trails that prove an answer is right rather than plausible. Here, “close enough” means someone gets an unexpected bill or gets turned away at the door.

Systems thinking. You can sketch a service’s architecture on a whiteboard, identify the failure modes, and reason about blast radius — including the kind that spreads to every team that trusts your API.

Production cloud experience (AWS, GCP, or equivalent). You have been on‑call for something real.

Comfort working directly with non‑technical stakeholders. You can run a 30‑minute working session with a network operations specialist or a member services lead, extract the real requirements, and leave them feeling heard, not bulldozed.

Sharp written communication. You will spend more time writing prompts, specs, and PR descriptions than writing code.

Note: Note: prior healthcare, insurance, or payments experience is not required. We care far more about your track record building and operating data‑intensive systems where the output has to be right, and owning a service other people depend on. Any industry counts. What we do look for is genuine interest in messy‑data problems — the kind where the answer is a judgment call and you have to own it.

AI‑first working style (also non‑negotiable)

• You already use Claude Code, Cursor, Codex, or equivalent as your primary development tool — not as a side autocomplete.
• You have opinions about how to structure prompts, when to split work into subagents, and how to keep AI output from drifting.
• You review every AI‑generated diff. You do not merge on vibes.
• You treat the AI as a junior engineer with infinite throughput: high leverage, zero judgement, needs supervision.
• You enjoy building tooling that makes AI more effective on your codebase — skills, evals, fixtures, integrations.
• You see AI leverage as what makes it possible for one engineer to own a full product surface and stay close to users — not as a reason to stay heads‑down in a terminal.