All roles

CTO / Technical co-founder

Build the patient simulator and the grader. Those two things are the product.

Co-founder, full-timeRamallah, or remote within ~3h of Palestine timeEquity-led

Klinico is an AI patient simulator for OSCE history-taking. A medical student holds a real conversation with a simulated patient. The transcript is then scored against the official OSCE checklist, item by item, with feedback on what to practise next. Students in Palestine and Jordan are using the pilot today.

The front end and the account layer are already built. What is missing is everything that makes this a product instead of a demo: a patient who stays in character, and a grade a student will trust even when it goes against them. That work would be yours. You would be the second founder, running the technical side alongside the CEO and a small group of interns.

What you would own

  • The simulated patient. It holds a hidden clinical history, gives it up only when a student actually asks, keeps character when someone tries to break it, and behaves differently for a second-year than for a final-year.
  • The grader. Free-form transcript in, defensible per-item OSCE score and feedback out. This is the hard part. Students will argue with their marks, and the system has to be right often enough to be worth arguing with.
  • Retrieval over our case library and the clinical material behind it. You pick the vector database, the embedding model, the chunking, and whether a reranker earns its latency. Done well, RAG here means a patient who does not invent a symptom and a grader that can point at the checklist line it marked against.
  • An eval harness, so changing a prompt or a model is a decision with numbers attached. "It looked good in the demo" is not a quality bar we can ship on.
  • The backend, starting from nothing. A FastAPI service, the case and session data model, streaming, queues, background work. Today we run no service of our own.
  • Cost and latency, which are product features here. One session is many model calls, and students feel both the bill and the time to first token.
  • Safety and scope. A simulated patient must never drift into giving real medical advice, and the product must never touch real patient data.
  • The dull infrastructure that keeps it all up: deploys, CI, observability, backups, secrets, and the judgement to keep those choices dull.

What you would inherit

  • React 19, Vite, Tailwind v4, React Router, framer-motion. A marketing site, auth, and an onboarding flow, all finished.
  • Supabase: Postgres with row-level security as the real authorisation boundary, email and Google auth, storage. The browser only ever holds the anon key.
  • No backend service, no model orchestration, no retrieval layer, no grading pipeline, no evals. Those are open decisions and you would make them.

You probably fit if

  • You have shipped an LLM product to production and then kept it running for a while. Prototypes do not really count for this one.
  • You write serious Python and know FastAPI properly: async endpoints, streaming responses, Pydantic models, background tasks, dependency injection, and tests that run fast enough to be worth running.
  • You have built RAG systems and know where they fall over. Embeddings, chunking strategy, hybrid search, reranking, evaluating retrieval separately from generation, and recognising when retrieval is the wrong tool.
  • You have run at least one vector database in production, whether pgvector, Qdrant, Weaviate, or Pinecone, and you can say why that one and where it hurt.
  • The rest of the AI engineering toolkit is familiar: structured outputs, tool and function calling, context design, prompt caching, model routing, agentic loops, LLM-as-judge and the ways it lies to you, and where fine-tuning beats prompting.
  • You are fluent in Postgres and schema design, and you treat authorisation as something you design up front.
  • You have taste in product. You have opinions about what to build and what to cut, and you have carried features through the full lifecycle: talking to users, scoping, shipping, watching what actually happened, then fixing or killing it.
  • You can write React when the work calls for it, even if it is not the part you enjoy.
  • You can take a clinician telling you a grade is wrong and turn it into an eval case rather than a one-off prompt patch.
  • You are fine with pre-funding and pre-revenue, with deciding on incomplete information, and with being the only engineer for a while.
  • You want the co-founder job rather than the first-engineer job: technical strategy, hiring, and saying no.

Nice to have, genuinely optional

  • A clinical background, or having sat the exam we are simulating.
  • Arabic and English. Our first users are in Palestine and Jordan.
  • Realtime or voice work. Spoken stations are the obvious next step.
  • Experience building review tooling for domain experts.

What we can offer, and what we cannot

  • Meaningful co-founder equity, standard vesting with a cliff, discussed openly and early and written down before you start.
  • We are pre-revenue and pre-funding. This is equity-led rather than salaried until that changes, and we would rather put that on the job page than save it for the third conversation.
  • Users already in the product, and direct contact with the medical students and faculty who use it.
  • Full autonomy over technical decisions, and a co-founder who will not pretend to make them for you.

How hiring works

  • A 30-minute call about the product and what you would change about it.
  • A scoped, paid piece of real work, or a deep walk through something you have built and operated.

Apply for CTO / Technical co-founder

Everything except your name, email and CV is optional.

CV

Your CV is stored privately and read only by us, for hiring. Ask us to delete it at any time and we will.

All roles