Tech Lead

Key Responsibilities Own the engineering of the whole platform — the Python and FastAPI backend, the React web application, the mobile application, the Artificial Intelligence (AI) plug-ins and the cloud they run on — and be the single person accountable for whether it ships Lead through senior engineers who each own a group of modules, with the quality, cloud and mobile engineers shared across both, so no module has one person who cannot go on leave Split the work by what a hospital does rather than by technology: one team on the clinical side — records, orders, laboratory, radiology, pharmacy — and one on everything a hospital runs on — reception, billing, insurance, canteen, administration Set the technical direction and record it as decisions a new engineer can still read a year later, including the ones that were wrong and why they were changed Stay hands-on: review every change that touches a clinical record, a price, a ledger or a claim, and write the parts nobody else should be left alone with — tenancy, the billing engine, the synchronisation layer Be accountable for the pilot hospital going live, and for the fact that a ward at two in the morning is not a place where software gets a second chance Delivery You Can Commit To Sequence the work so two teams run in parallel without waiting on each other, and say in the week it becomes likely — not in the week it becomes certain — that a date will move Hold estimates that hold: break work down until the team can commit to it, and treat an estimate that keeps slipping as a specification problem rather than an effort problem Own the release path end to end — trunk-based development, migrations only through version control, a deploy anybody on the team can run, and a rollback that has actually been tested Own what happens when it breaks at three in the morning: who is called, what they can see, and how the hospital is told before it telephones us Keep the weekly picture honest — what shipped, what slipped, what is at risk and what you need from the business — in a pack somebody outside engineering can read Correctness, Because This Is a Hospital Hold the line on the paths where being wrong is not a bug but a harm: allergy and interaction checks, dose limits by age and weight, critical results that must reach a human, and money that must reconcile to the rupee Make every write auditable and attributable — who did it, when, and what it replaced; corrections by reversal, never by silent overwrite Build multi-tenancy in from the first table: one platform, many hospitals, and no path by which one can see another's data Own the security posture — access control, audit, encryption, secrets, and a third-party Vulnerability Assessment and Penetration Test the platform passes before go-live rather than after Own the standards work that cannot be compressed at the end: Fast Healthcare Interoperability Resources (FHIR) R4, Health Level Seven (HL7) version 2 from analysers, Digital Imaging and Communications in Medicine (DICOM) worklists, and Ayushman Bharat Digital Mission (ABDM) with Ayushman Bharat Health Account (ABHA) linking The People Part, Which Is Most of It Take a team that is already building and make it better at it — and own the hiring as it grows, being honest in the interview about what the job is: a hospital, a deadline and a real pilot, not a research project Grow the senior engineers into people whose review is trusted, so that within a year the hardest module is not yours to review Give feedback in the week it is useful, run the performance conversations, and make the growth path visible to a junior engineer who cannot yet see it Protect the team from thrash — take the interruption yourself, decide, and let them keep building Pair the engineers with the ward: every one of them should have sat beside a nurse or a billing counter before they design for one Working With the Business Work with the Product Delivery Manager on scope and sequence, and with the Business Analyst on turning a hospital's actual documents — a tariff sheet, a rate contract, a scheme circular — into something the software can hold Say no with a reason and an alternative, in a sentence a hospital administrator can repeat to their own board Own the technical half of a customer conversation: what the platform does today, what it will do by go-live, and what it will not do at all Keep the demo honest — a screen shown to a hospital is a promise, and this team does not show what it cannot build Tech Stack Python · FastAPI · Pydantic · SQLAlchemy · PostgreSQL · React · TypeScript · React Native · AWS · Docker · Terraform · GitHub Actions · pytest · Playwright · FHIR · HL7 v2 · ABDM We build in Python on FastAPI with React in front of it, on Amazon Web Services. That is what this role writes, reviews and is accountable for, and we would rather say it plainly at the top than have you find out in week one. What you will work in every day Backend — Python 3.12 with type hints everywhere, FastAPI, Pydantic v2, SQLAlchemy 2.0 in async mode, Alembic for migrations, and Structured Query Language (SQL) you write yourself when the query matters Typing, enforced — mypy or Pyright in strict mode, failing the build. Python's type hints are optional at runtime, so we make them non-optional in continuous integration Frontend — React 18 with TypeScript, function components and hooks, a data-fetching and caching library (TanStack Query or equivalent), schema-based validation (Zod or equivalent), and Vite Mobile — React Native, sharing types and validation with the web application API contract — FastAPI generates the OpenAPI schema, and the TypeScript client the web and mobile applications use is generated from it, so the contract cannot quietly drift Database — PostgreSQL 16: schema design, migrations, indexes and query plans, on Amazon Relational Database Service (RDS) or Aurora Caching and queues — Redis on Amazon ElastiCache, and a task queue with idempotent consumers, dead-letter handling and replay: Celery, Dramatiq, arq or a PostgreSQL-backed queue Cloud — Amazon Web Services , which is where we build and run: Elastic Container Service (ECS) Fargate, Simple Storage Service (S3), CloudWatch, Identity and Access Management (IAM), Virtual Private Cloud (VPC), Secrets Manager, and the Mumbai region for data residency Containers — Docker everywhere, so that a hospital insisting on Google Cloud or Azure is a piece of work rather than a rewrite. That is a possibility we design for, not a thing we are doing this year Infrastructure as code — Terraform, with the AWS estate defined in version control and nothing clicked in a console Delivery — GitHub Actions, trunk-based development, short-lived branches, code review on every pull request Testing — pytest and pytest-asyncio, Vitest or Jest with React Testing Library, and Playwright for the end-to-end journeys that protect money and clinical safety AI — the AI services are Python too, which is one of the reasons we chose it: models served behind the same contract discipline as everything else, subscribing to events and writing suggestions back, never writing directly into clinical or financial tables Healthcare standards — Fast Healthcare Interoperability Resources (FHIR) R4, Health Level Seven (HL7) version 2 over Minimal Lower Layer Protocol (MLLP), Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), International Classification of Diseases (ICD-10), Digital Imaging and Communications in Medicine (DICOM), Ayushman Bharat Digital Mission (ABDM) and Ayushman Bharat Health Account (ABHA) What we need you to have used in production Python , written with type hints and tested, in a service somebody depended on A modern relational database , PostgreSQL for preference — schema design, transactions, indexes, and reading a query plan React with TypeScript — enough to review a component,