Backend Developer

Stack direction: Python, FastAPI, PostgreSQL, SQLAlchemy/Alembic, queue-backed workers, AWS, object storage, CI/CD, audit/event-led architecture

Build the backend of a healthtech platform that cannot afford to be vague.

Health systems already has dashboards, prescribing data, formularies, BI tools and committees. This application is being built for the harder part: turning medicines signals into board-safe decisions, provider-safe handoffs, tracked execution, blocker resolution and audited realised value.

This is not another dashboard product; it is an action layer above existing health systems, and the workflow is the product. The current controlled baseline defines it as a shared-core medicines action layer that helps health systems discover medicines actions, justify them with decision-grade evidence and move them into owned delivery and tracked closure.

We are hiring three backend engineers in Glasgow to help build the platform spine.

This role is for engineers who like hard backend problems: state machines, provenance, multi-tenant data models, async pack generation, audit trails, release gates, RBAC, workflow events, evidence metadata, and reproducible outputs.

It is not for people who think backend means "make APIs for the frontend."

What you will build

You will work on the core backend objects and services behind the product.

ActionCase Operating System ActionCase is the atomic operating object. It carries lane, owner, blocker, due date, review cadence, closure status and realised-value state. The backend must enforce lifecycle rules, not leave them to the frontend. The architecture baseline is explicit that deployment and closure are part of the platform, not an afterthought.

Decision Pack and Evidence Pack engine You will build services that generate buyer-safe outputs with provenance, assumptions, completeness status and release controls. Draft packs and released board packs are separate lifecycle objects. A pack must never become "ready" just because the frontend wants to show it.

Gate engine and tri-state controls The platform uses PASS / FAIL / UNKNOWN logic. Unknown must stay unknown. A hard FAIL or UNKNOWN must block release unless there is a named override with rationale and source basis. Annex A is clear: no Release Board Pack if any hard gate is FAIL/UNKNOWN absent named override.

Publish-to-Provider handoff You will help build Publish Mode A and Mode B: secure external share, receiver scope, share permissions, expiry, acknowledgement, and linked Flow ActionCase creation where relevant.

Realised Value Ledger It must track approved value versus realised value, with baseline, benefit type, implementation cost, variance, reviewer identity, assumptions reviewed and evidence link. This is what makes the platform CFO-grade, not just pharmacy-interesting.

Reference and provenance control Every buyer-visible number needs source, transform rule, timestamp and confidence status. The backend must store source manifests, reference snapshots, run hashes, source windows, versioned outputs and audit records. The architecture rule is simple: no number on screen should exist without visible source, transform rule, timestamp and confidence status.

AI-assisted intake and human review The platform will use AI to help draft, summarise, detect gaps and convert source-grounded notes into draft ActionCases. AI may assist, but it may not decide, approve, sign off, invent evidence, or turn UNKNOWN into PASS. The platform AI standard is explicit on that boundary.

Do you have experience in Python?, * You should be comfortable with backend engineering that survives scrutiny.

• You should be able to design relational schemas, write migrations, reason about state transitions, enforce permissions, build reliable APIs, handle async jobs, test edge cases, debug production behaviour and document what future engineers need to know.
• You should care about boring things that matter: idempotency, transaction boundaries, audit logs, tenant isolation, rollback paths, reproducibility, structured logging, data lineage and release evidence.
• Strong Python experience, ideally FastAPI or similar.Real PostgreSQL experience: constraints, indexes, migrations, transactions, performance, schema design.
• Experience with queue-backed workers, async jobs, retries, idempotency and generated artefacts.
• Experience building workflow, fintech, healthtech, govtech, enterprise SaaS, logistics, data platform or regulated systems.
• Ability to explain trade-offs clearly.Ability to work in a fast-moving startup without hiding behind process.High ownership and low ego.Not a fit

• You only want to build simple CRUD endpoints.
• You think frontend validation is enough.
• You cannot explain how to enforce a state machine server-side.
• You are casual about secrets, permissions, migrations or logs.
• You treat test coverage as optional.
• You rely on AI-generated code you do not understand.
• You cannot work from imperfect requirements.
• You want a "manager" title but cannot personally ship backend code.
• You need six people to define every ticket before you can move.