Build sovereign AI for the doctors who keep Australia well

You own the appliance: the ASR and the drafting model that turn a consultation into a clinical note, running on hardware in a doctor's office.

Why this role exists

Everything a scribe normally does easily, we do the hard way on purpose. We can't call a frontier API. We can't ship audio to a datacentre for batch processing. We have one GPU box per practice, a doctor waiting at the end of a consult, and a note that has to be good enough for a clinician to sign their name to.

Today the pipeline is faster-whisper for transcription and a local LLM for drafting, wired through a Python worker that pulls audio from an on-LAN object store and posts partial transcripts back over SSE. It works. It is nowhere near as good as it needs to be, and there is no one whose job it is to make it better. That is this job.

What you would work on

• Note quality, measured rather than felt. Eval sets that tell us whether a change improved anything — across accents, specialties, interruptions, three-way consults with a family member in the room, and the Australian clinical vocabulary that general-purpose ASR mangles.
• Latency and footprint. The draft should be waiting when the doctor stops talking. Quantisation, batching, model selection, KV cache behaviour, and what actually fits in the RAM of a box a practice will pay for.
• The safety boundary, as an engineering problem. The model must not produce a diagnosis. We enforce that with a prompt, a schema, a deny-list validator and a release gate that fails the build. All four are yours to strengthen — the interesting failures are subtle, like a model that writes "consistent with" instead of naming the condition.
• Speaker handling. Knowing who said what changes a note from a wall of text into a record.
• Choosing what runs. Local model landscape, licence terms, what we can fine-tune, what we should not.

What we need

• Real experience getting models to run in production under hardware constraints — quantisation, serving stacks (vLLM, llama.cpp, TensorRT-LLM or similar), and the profiling to know where the time went.
• Python, and enough software engineering to own a service rather than a notebook.
• Evaluation as a discipline. If your instinct on "is the new prompt better" is to build a dataset rather than read ten outputs, you're who we want.
• ASR experience, or the appetite to own it quickly.

Nice to have

• Speech: diarisation, alignment, streaming decoders, domain adaptation.
• Clinical NLP, or any work where being wrong had consequences.
• Fine-tuning small models — LoRA and friends — with a clear view of when it's worth it and when a better prompt was the answer.

You would build Curaeon's first mobile app, from nothing.

Why this role exists — and what is honestly undecided

There is no mobile code today. There is a web application that works on a phone, and a patient booking site. That is the whole of it.

We know two mobile products want to exist. Patients want to book, see what they're due for, and get their results without a phone call. Doctors want the appointment book, their results inbox and their messages when they're not at the desk — the two phrases we hear most are "check on the way in" and "sign off from home".

What we have not decided is which comes first, or whether it's native or React Native. We would rather hire the person who's going to live with that decision than make it in their absence. If you have strong views, bring them to the interview — that conversation is part of how we'll assess you, and it's a real decision, not an exercise.

What you would work on

• The platform call, made properly: what each option costs us at our size, and what it costs the person maintaining it in three years.
• The first app, end to end — design partnership, build, store submission, and the release process that goes with it.
• Authentication that suits a doctor's hands. Biometrics, sessions that survive a pocket, and a lock policy that doesn't become the reason someone props the app open all day.
• Offline, honestly. A doctor in a nursing-home basement has no signal. Deciding what's safely readable offline, what must never be written offline, and how a conflict resolves is more of this job than the UI is.
• Push notifications carrying clinical meaning without putting clinical content on a lock screen.
• Working with our backend engineers on the API the app needs, rather than bending the app around the API the web happens to use.

What we need

• You've shipped and maintained an app real people used — through store review, a bad release, and the version-fragmentation tail.
• Depth in Swift/Kotlin or React Native, and enough honesty about your stack's weaknesses to argue the other side.
• Offline-first data sync experience, or clear-eyed respect for how hard it is.
• Care about accessibility. A meaningful share of patients will have low vision, tremor, or be doing this in a second language.

Nice to have

• Health app experience and the store review rules that come with it.
• Both platforms.
• Anything involving audio capture on mobile — the scribe reaches the phone eventually.

You own the screens a doctor uses six hours a day.

Why this role exists

There are around 60 screens in Curaeon and they're not a dashboard. They're the appointment book, the consultation, the prescribing flow, the results inbox — the software that stands between a doctor and their patient, all day. Speed and clarity here aren't polish. A consultation is fifteen minutes, and every second the interface wastes is taken from the person in the chair.

The stack is Next.js 15, React 19 and TypeScript, deliberately light on dependencies. Design tokens are shared with our design system and enforced in CI — a hand-written hex code fails the build.

What you would work on

• The consultation screen, the hardest surface in the product: live transcript streaming from the appliance, the note drafted underneath it, past history one keystroke away, and a doctor who must never lose a word of what they typed.
• Making it fast on the hardware clinics actually own — which is not your laptop. Six-year-old desktops, ten tabs open, a patient waiting.
• Keyboard-first everything. The doctors who love their current software love it because they never touch the mouse. That's the bar.
• Error states that tell the truth. We have a rule with a name and a test behind it: an API failure must never render as an empty state. A results screen that shows "no results" when the server is down is how a doctor misses a cancer diagnosis. We treat that as a class of bug, not a nicety.
• Accessibility as a build gate, not a cleanup task — automated a11y checks run in CI and we keep raising the bar.
• Print — paper still matters enormously in healthcare, and we maintain real print stylesheets for scripts, referrals and letters.

What we need

• Strong React and TypeScript, with judgement about state that comes from having been burned.
• Genuine care about the details: focus management, loading/empty/error states, what happens on a slow network.
• Accessibility fluency — semantics, keyboard, screen reader, contrast — as something you do by default.
• The instinct to ask what the user is actually trying to do, and to push back when the answer doesn't justify the screen.

Nice to have

• Data-dense interface experience: tables, timelines, scheduling grids.
• Streaming UI — SSE or websockets — and the state problems it brings.
• Design ability, or a track record of working closely with a designer.
• Any experience of software used by professionals under time pressure — clinical tools, trading floors, dispatch, air traffic. The discipline transfers.

You own the API, the data model, and the integrations that make Curaeon a real clinical system rather than a demo.

Why this role exists

The backend is a Go modular monolith — chi and pgx over Postgres, with numbered SQL migrations embedded in the binary and applied on boot. Around 282 endpoints across the clinical record, scheduling, prescribing, billing, messaging and the scribe.

It is deliberately not a distributed system. We're a small team building software that has to be maintainable for a decade, and a monolith we understand completely beats microservices we half-understand.

The hard part isn't the CRUD. It's that the domain is unforgiving: correctness has a patient at the end of it, deletes aren't allowed, money is never a float, and half the systems you integrate with were specified in the 1990s.

What you would work on

• Clinical integrations. HL7 v2 over the Australian secure messaging networks — referrals out, pathology and imaging results in, acknowledgements both ways. Then Medicare: the Healthcare Identifiers service, the immunisation register, PBS authorities, claiming. Specification-driven, conformance-tested, and unglamorous in a way that's either satisfying or intolerable depending on the person.
• The result pipeline, where a mistake is most expensive: matching an incoming result to the right patient, handling amended and corrected results without ever overwriting what was on file, and making certain nothing lands somewhere a clinician won't see it.
• Data model work that has to be right the first time. Migrations are forward-only against databases holding real patient records. There's no "we'll fix it in the next deploy" here.
• Correctness under concurrency. Two receptionists booking one slot; two workers reaching for one appliance. We use advisory locks and we test for it.
• Reference data at scale — the Medicare schedule, the PBS catalogue with thousands of listings and the restriction rules that decide whether a script needs an authority.

What we need

• Strong Go, or strong systems experience in a comparable language and the appetite to switch. We care more about judgement than years of Go.
• Real SQL and real Postgres. Comfortable reading a query plan, designing a schema you can't change casually, and reasoning about transaction isolation.
• Experience building against a specification someone else wrote and will test you against.
• Testing discipline. We run integration suites against a real database, not mocks — because mocks agree with you.

Nice to have

• HL7, FHIR, X12, EDI, or any messaging standard with a conformance process.
• Healthcare, banking, or another domain where an audit trail isn't optional.
• Multi-tenant systems, and appropriate paranoia about tenancy leaks.
• On-premises deployment experience. Our software runs on other people's hardware, which we can't log into.

You take a clinical problem from the doctor's description to the thing running in their practice.

Why this role exists

Most of what a practice asks us for doesn't fit one side of the stack. "I need to see which of my diabetic patients are overdue for a review" is a database question, an API question, a screen, and — most of all — a question about what a doctor means by overdue. Handing that across three people loses the part that mattered.

This role is for someone who can hold the whole line: talk to a GP, design the data model, write the Go, build the screen, and watch someone use it. We're explicit that this is a different skill from being a backend engineer who can also write React. The value is in the seams.

What you would work on

Whole features, owned end to end. Recent examples of the shape:

• Recalls — patients due for follow-up. The rules for when someone becomes due, the worklist, booking straight from it, and what happens when the appointment is cancelled. The obvious build is wrong in a way you only find by watching reception use it.
• Care plans and chronic disease — the structured programs Medicare funds, the review cycle, and the reporting a practice needs to prove it happened.
• Correspondence — letters and referrals composed in the consult, sent over the secure messaging network or as a password-protected PDF by email, filed automatically into the record, and reconciled when the mail server bounces it two hours later.
• Assessment tools — the standard clinical questionnaires, scored, trended, and dropped into the note.

What we need

• Genuine competence on both sides. Not expert in both — competent in both, and honest about which side you're weaker on.
• Product instinct. You ask what a doctor is trying to achieve before you ask what to build, and you can tell the difference between the two.
• Comfort with ambiguity. Features here often start as a sentence from a GP.
• A completion habit. Full-stack is where work goes to be 90% done. We need the last 10%: the error state, the empty state, the migration, the test, the documentation.

Nice to have

• You've talked to users directly and enjoyed it.
• Healthcare, or another regulated domain.
• Design ability.
• Experience at a company small enough that you saw the consequences of your own decisions.