All open roles

Engineering

Founding Product Engineer

Apply for this role

Two conversations, then a paid exercise — about three weeks end to end. Applications reviewed weekly.

About the role

There is a compiler that produces signed rule packs, and there is nothing yet that puts one in front of a human being who is about to send a container to Rotterdam. You build that.

Concretely: today the front end renders from a synthetic fixture and makes zero calls to a backend, because there is no service surface for it to call. Your first substantial piece of work is the one that makes the rest of the product possible.

After that it is document intake that has to cope with a scanned invoice photographed at an angle, extraction that carries its own provenance, reconciliation that can say exactly which of three documents disagrees, and a reviewer console that a customs broker will trust enough to put their name against.

This is not a role where you get a specification — you will often be the person who writes it. It is not front-end only and it is not back-end only. And it is not a job for someone who wants a large existing codebase to maintain.

What you’ll do

  • The API that does not exist yet — the thin service surface between the compiler and everything downstream.
  • Document intake and classification, with "unknown" as a first-class outcome rather than a fallback.
  • The extraction pipeline. Every field carries its source document, page, bounding box, extractor version and confidence tier — provenance here is structural, not a log line.
  • Cross-document reconciliation. Invoice, packing list and bill of lading have to agree, and when they do not the system must say precisely where.
  • The evaluator that returns one of four states and never silently defaults to "fine".
  • The packet engines, and the reviewer console the whole product will be judged on.

What we look for

  • You have built something end to end that another person then depended on. We will ask about that thing in detail.
  • Python and TypeScript — or clear evidence that you pick up a stack in a fortnight and are not precious about which one.
  • You are comfortable wrapping vendor document-AI rather than building OCR, and you understand why that is the right call here.
  • You accept a boundary: you consume the ontology, you do not redesign it. Arguing it should change is welcome — through the amendment mechanism, not through a pull request.
  • You write things down. This company runs on files.

Nice to have

  • Document AI — Docling, Azure Document Intelligence, Surya, Marker, or anything in that family.
  • Next.js, TypeScript in strict mode, Tailwind, shadcn.
  • You have worked somewhere the output had to be defended — finance, healthcare, legal, logistics.
  • A public trail of things you have made. A good repository beats a good CV here, and we will read it.

Application

Apply — Founding Product Engineer

Twenty minutes. The written answers carry more weight than the CV, so give them the time.

A link is easier for us than an attachment — Drive, Dropbox, or your own site.

PDF only, up to 3 MB.

A few questions

The last part is the one we read closest. "Immediately" is rarely true.

0 / 1200

We are building a system whose job is to say "unclear" rather than guess. We are asking whether you do the same.

0 / 1200

We are interested in the workaround, and in what it cost you later.

0 / 1200

We use what you send here only to assess this application. See our privacy policy.