New
Full-Stack Tech Lead
Cooperation type: B2B
Compensation: 280 – 340 € / manday
Location: Remote 100%
Seniority: Senior
Project length: 12 months
Start: 11/9/2026
Language: Slovak
Profession: Full-stack
Required technologies
General Description
We are looking for a Full-Stack Tech Lead to lead the technical work of one pod within a large audit platform while continuing to write production code. You will be the pod’s technical voice for design, code reviews and release decisions.
The platform is delivered through value streams and pods covering areas such as administration and approvals, content search, audit-item templates, data catalogues, testing of details, scoping and test planning. Delivery is agile, using Kanban or sprints, with QA working as part of the delivery rather than as a separate phase after development.
The platform runs on Microsoft Azure. Its services use .NET, while the user interface uses React and TypeScript. Exact libraries vary by value stream.
What will you be doing?
- Lead the technical work of one pod and continue to design and build production software across its services and user interface.
- Work with the Product Owner, QA and technical leads in the US time zone. Explain technical decisions in plain language, including to people who do not write code.
- Identify when a request is not ready because the requirement is unclear, the deadline is unrealistic or there is no evidence that the change works.
- Listen to the pod, offer options and allow the team to reach decisions where appropriate rather than forcing decisions unnecessarily.
- Monitor the distribution of work, notice when someone lacks work or when too much work is assigned to one person, and help balance the workload.
- Review designs before large changes begin and keep the pod’s repositories consistent, including API shape, OpenAPI documentation, security checks and pull-request descriptions.
- Review pull requests personally. Reject changes that the author cannot explain, and do not approve generated code that nobody has read or tested.
- Ask for meaningful proof with each delivery. This may be a user-interface change, a backend endpoint or an integration test, and should demonstrate understanding of the problem, its impact and the fact that the change works.
- Involve QA when the backlog item is written, agree acceptance checks early and support developers writing happy-path automated tests so that QA can review them and cover edge cases.
- Define how the pod uses AI coding tools. Maintain rules and skills in the repository, share useful skills through pull requests and adapt shared starters to the pod’s domain without making one setup mandatory for every stream.
- Use AI coding tools with judgment by providing context, reading the plan before implementation and keeping a human check on anything that leaves the repository, such as a push, ticket comment or pull-request approval.
- Participate in coordinated release work across pods and help make the pod’s part predictable through environment and configuration checks and confirmation that the change was deployed successfully.
- Take part in approved, rotated on-call coverage when the pod needs it. This is not a standing weekend commitment for one person.
- Help new teammates become productive during their first weeks by directing them to repository rules, the relevant domain and the person who can unblock them.
- Raise risks early, including limited QA capacity, broken environments, dependencies on other pods and late scope changes.
- Treat the backlog item as the unit of delivery. Stop and clarify thin requirements before the pod starts work.
- Handle short-notice work while still requiring a clear requirement and a deadline the pod can realistically meet.
- Share the real state of the work in a weekly lead sync and keep the pod informed.
- Follow a practical delivery sequence covering documentation and readiness, planning, implementation, branching, pull requests, code review and a security pass. Adapt the sequence to the pod’s work where needed.
Requirements
You do not need to know every library on your first day, but you must be productive in the common technology stack and able to learn the additional tools used by a particular pod.
- Strong practical experience with C# and .NET, including ASP.NET Core Web APIs.
- Experience with React and TypeScript.
- Knowledge of REST APIs, Swagger/OpenAPI and careful management of changes that could break callers.
- Experience with microservices and user interfaces split into micro-frontends.
- Practical Microsoft Azure experience, including at least Azure App Service or Azure Kubernetes Service, Azure Functions and Azure Service Bus.
- Experience with both relational and document databases. The platform uses SQL Server, Azure SQL, MongoDB and Azure Cosmos DB across different services.
- Experience with Docker for local runs and service images.
- Ability to read and extend automated tests. Developers own small integration tests and happy-path UI tests; Playwright is the UI testing tool currently in use.
- Daily use of an AI coding assistant and the habit of reviewing its output. Cursor is currently used by the pods; some people also use Claude or Claude Code, and there is no single mandatory tool list.
You should be able to apply the following architectural approaches where appropriate:
- A thin backend-for-frontend in front of services.
- Clean Architecture on .NET services that already use it.
- Events through Azure Service Bus, including an outbox when a service publishes a message.
- Feature flags using LaunchDarkly or a shared feature-management library.
- API versioning and stable contracts for other pods.
- Repository rules covering security, OpenAPI and the pod’s own domain that can also be followed by an AI agent.
Squidex headless CMS and content search are useful on one specific stream but are not required for every pod.
- English is the working language, and you speak and write it clearly every day.
- You can explain trade-offs, risks and proposed changes to engineers and non-technical stakeholders.
- You take ownership of the pod’s technical result and ask for help when a decision falls outside the pod.
- You remain calm under release pressure or when late changes affect the pod, and you communicate risks early.
What we offer
- A remote-team working environment with occasional in-person sessions in Prague, typically about once per quarter.
- Working hours overlapping with the US time zone. A normal working day runs until approximately 18:00 CET, with either 09:00–18:00 CET or 10:00–19:00 CET suitable. A wider overlap is welcome; the time difference to US Eastern Time is approximately six hours.
Is your colleague looking for a change?
Recommend them for one of our projects and, once a deal closes, earn a commission every day.
How referral works