Staff Engineer (100% Remote within Poland)

Responsibilities

• There is a written, agreed technical direction for the Marketplace on the monorepo: which domains move next, in what order, and what "done" means for each. It includes a realistic plan for making the monorepo the source of truth for bookings. Teams use it to plan, not just to read.
• At least one core Marketplace capability, such as bookings, is exposed through a clear, versioned contract that another Docplanner product consumes in production. For example, patient-facing products know which visits a patient has had without calling into the monolith.
• The monolith is shrinking in a measurable way: fewer ad-hoc endpoints and proxy layers, and more domains where the monorepo is the source of truth. Shared domains such as insurances, services, calendar and addresses have a clear owner and a target home.
• You are personally shipping, with AI agents writing the code and you owning the design, review and quality. You set the bar for what AI-native engineering looks like in a large, real codebase.
• AI-assisted workflows for migration and integration work, such as generating contracts, tests and adapters, are proven in one team and being adopted by others.
• The real indicator of success: teams across the portfolio come to you when they need Marketplace data or capabilities, and they leave with a contract they can build on, not a workaround.
• Own the Technical Direction of the Marketplace
• Be accountable for the target architecture of the Marketplace across search, listings, doctors' profiles and the booking flow. Make sure search, doctors' profiles, listings and the booking flow fit together end to end on the new stack.
• Shape the monolith-to-monorepo migration: decide which domains move next, how to move them safely (strangler routing, anti-corruption layers, shadow traffic, staged source-of-truth flips) and when a domain truly counts as migrated. Q&A, already fully migrated, is the reference; the hard cases come next, such as doctor…
• Move domains from "thin proxy over the monolith" to "owned natively in the monorepo": data, business logic and persistence, not only the frontend. Profiles and listings, which already run on the new frontend, are the first candidates.

Languages