Build the rails prescription drugs run on.

What Kanurra is

Between an employer's health plan and the pharmacy sit a few companies: a TPA that administers the plan, a broker who advises the employer, and a pharmacy benefit manager that prices and pays the claim, usually in a way nobody else can check. Kanurra is a platform the TPAs, brokers and partners build on to price, pay and audit those claims in the open. Other businesses will depend on our API, and some of the decisions we make this year we'll live with for a decade.

What's here today

Here is where we are. I've written most of what exists: the partner and member apps, drug pricing on licensed drug data, and the integrations a claim passes through. Today a licensed claims processor runs the real-time step at the pharmacy counter, and we own pricing, reconciliation and the API partners build on. We're early, and you'd be here for the first plans going live. It was built by one person moving fast, and it shows in places. How much of the claim path we bring in-house, and when, is a decision you'll make with me.

The problems

• Same claim, paid once. Pharmacies resubmit, reverse and rebill. Partners retry. Webhooks arrive twice. Every path has to be idempotent, and the books have to reconcile against the bank, not against our own logs.
• An API people build businesses on. Versioned, boring and stable. A field we ship carelessly stays in someone else's integration for years.
• Many tenants, one system. Every TPA, broker and employer sees only their own data, enforced in the database, not in a code review. It's health data, so a mistake here isn't a bug ticket.
• Prices that change under you. Drug prices, codes and contract terms update every week, sometimes retroactively. A claim priced last month has to be explainable against the data as it was then, and correctable against the data as it is now.
• Prices you can audit. Every number we show has to trace back to a contract, a drug file and a claim. If an employer's auditor asks why, we have the answer.

You don't need healthcare or payments experience. The mechanics are learnable in months. The instinct for not breaking things isn't, and that's what I'm hiring for.

What you'd own

• The platform. The API partners integrate with, and the abstractions that have to outlast the first version.
• The core. Claims priced, paid and reconciled correctly, every time.
• The customers. You'll talk to the TPAs and brokers using what you build, and hear it directly when something's wrong.
• The bar. Everyone after you gets hired against the standard you set, and you help pick them.

The stack today is Python, TypeScript and Postgres on Google Cloud. Pick it apart.

Who I'm looking for

• You've owned a system in production that moved money or records other people relied on, and you know which changes can be undone and which can't.
• You've designed or maintained an API that outside teams built on, and you've lived with a decision you'd make differently now.
• You'd rather tell me I'm wrong in week one than fix it in year two.

Working with me

I move quickly, and I change my mind when the facts change. I need someone who slows me down where it matters and doesn't where it doesn't. I'm an engineer, and I'm in the code every day, so you won't be explaining your work to someone who can't read it. Most recently I led AI and machine learning at a healthcare company. Before that I was technical cofounder and CTO of a healthcare AI company that was acquired.

Today the team is me and our pharmacy and clinical people, and I'm hiring a Head of Distribution at the same time as you. You'd be the first engineer, not the only one for long. Once you're here, the platform is yours to run: I'll keep writing code, and you'll review mine.

This role is in person in New York, at our office on Broadway by Union Square. Meaningful ownership in the company, as the first engineer, with the numbers in writing early.

Pay

Base salary of $230,000 to $310,000 a year, plus equity.