We build the system that tracks surgical implants from the moment they arrive in a warehouse to the moment they go into a patient.

That means pick and put orders, surgical kit assembly, consignment and loaner custody, returns and quarantine, carrier-booked shipping, and lot-level traceability under FDA Unique Device Identification rules. It is orchestrated by a separate process platform that talks to us over signed HTTP rather than reaching into our database.

This is not a CRUD role with a medical logo on it. The hard problems here are modelling problems: what is the one true home for a fact, what happens when the physical world and the record disagree, and who is holding this box right now.

What you'd work on A typical feature spans the whole stack — a database migration, an entity and service, an API, the data-fetching hook, the screen, and tests on both sides. You will write both halves, not occasionally touch a template.

Recent work on this codebase, as a sample:

- Modelling GS1 device identifiers so a scanner and a hand-typed lot number resolve through the same path, and a label that contradicts our records is refused rather than quietly accepted.
- Splitting custody so that scanning stock off a shelf and transferring it to a recipient are two separate events, because they are two separate facts.
- Consolidating a filtering capability that had been reimplemented per screen down to one shared component.

The stack Backend — Java 21, Spring Boot 3.3, PostgreSQL, Flyway, JPA/Hibernate, MapStruct, Resilience4j, JUnit 5

Frontend — React 18, Vite, TypeScript (strict), TanStack Query, Zustand, React Hook Form Zod, Tailwind on CSS custom properties, Vitest, Testing Library, MSW

Domain — ISO 13485, FDA UDI/GUDID, GS1 barcode standards, HMAC-signed service APIs, multi-tenant data isolation

What makes it hard These constraints shape almost every decision. If they read as obvious to you, that's a good sign.

Custody, not just quantity. Stock doesn't simply decrease — it moves into someone's custody and has to come back. "How many do we have" is the easy question. "Who is holding this, and since when" is the one the system exists to answer.





Records are evidence. Audit trails are append-only. The scan ledger keeps what was physically read, not our interpretation of it, because a mis-printed label is a finding and the record has to survive the argument about it.

One fact, one home. A device identifier is composed from data we already hold, so we don't store it a second time as a string. Two sources of truth for the same fact isn't redundancy — it's a future contradiction with a date on it.

Migrations are permanent. An applied migration is never edited. Schema history is the record of how the system came to be shaped this way.

Tenancy is enforced in the query. Another tenant's record must be un-resolvable, not merely hidden.

Who we're looking for Seniority here is about judgment, not years on a CV. We want someone who:

- Argues with the requirement when it's wrong — and brings the alternative in the same breath. "We shouldn't store that, here's where it already lives" is the most valuable sentence on this team.
- Writes down the why. Our code records the reasoning behind non-obvious decisions, because the next person to touch a custody rule needs to know what it protects.
- Consolidates instead of duplicating. Finding and deleting the second implementation of something is real work here, and it's recognised as such.
- Treats a nullable column as a design decision. Every optional field is a claim about what may legitimately be unknown, and it needs a reason.
- Tests what would actually break. A test that pins a real invariant beats a coverage number.
- Verifies rather than assumes. Migrations get checked against real PostgreSQL, because the test suite runs on H2 and would never catch it.

Three questions These come from real decisions on this codebase.



We're not looking for our answer — we're looking for whether the question is familiar territory.
1. A scanned barcode says the lot expires in March. Our database says April. What should the system do?
2. If your instinct is that this is a non-conformance rather than a lookup failure, and that proceeding on the stored value is the dangerous option — we should talk.
3. A retried API call would create a second order. Where does the idempotency key come from?
4. Anything freshly generated defeats the mechanism while appearing to work perfectly: every call succeeds, and every retry silently duplicates.
5. Approving a request reserves a specific physical kit. Is that right?
6. It depends entirely on whether a promise was made to a particular item or merely to a type of item. Getting that wrong shows up months later as stock that exists on paper and not on a shelf.

Experience
- 6 years building production systems, with real depth in both a JVM backend and a modern typed frontend.
- Relational data modelling you can defend — constraints as enforcement rather than documentation, and migrations on a live system.
- Service-to-service integration where correctness under retry matters: signing, idempotency, circuit breaking, and knowing when not to add another retry layer.

Valuable, not required: a regulated domain (medical device, pharma, aerospace, GxP); warehouse, inventory or logistics systems; GS1 standards and scanner workflows; workflow orchestration engines.

You don't need to arrive knowing ISO 13485. You do need to find it interesting rather than tedious — most of it is the discipline of being able to prove what happened, which is positive engineering with paperwork attached.

How we work

- Small team, direct access to the people who decide what gets built.
- Coding standards are written down and enforced in the build, so review is spent on design rather than formatting.
- Design decisions are documented as they're made, not reconstructed afterwards for an audit.
- Changes are verified against a real environment before they're called done.

📌 Senior Full-Stack Engineer (Chennai)
🏢 Marek Systems
📍 Chennai