> Markdown version of [/jobs/ext/3855051-backend-engineer-foundation](https://www.wearedevelopers.com/jobs/ext/3855051-backend-engineer-foundation). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Backend Engineer (Foundation)

- **Company:** Proton
- **Location:** Barcelona, Spain
- **Contract:** Permanent contract
- **Skills:** PHP (Programming Language), Application Programming Interfaces (APIs), Management of Software Versions, Backend, Build Management, Api Design, Microservices
- **Published:** October 22, 2026
- **Apply:** https://www.adzuna.es/details/5935962720

## About the Role

What you will do Design and build shared libraries, framework layers, and internal services used across every Proton product Turn recurring patterns into good abstractions Write documentation and examples people actually use, and treat adoption as part of shipping Improve the day-to-day: build times, local dev setup, test ergonomics, debuggability, developer experience Work in the open with product teams - RFCs, design reviews, and the occasional pull request into someone else's repo to show what you mean Work closely with other developers to help integrate libraries seamlessly into applications Job requirements: 5+ years building and operating backend systems in production, including code you stayed responsible for long after launch, with a focus on modern PHP Working knowledge of Rust, or clear evidence you can get there quickly - we care that you understand ownership and lifetimes Genuine taste in API design.

## Description

You will work in PHP for API related work, and in Rust for components where performance and memory safety justify it or for microservices.
You will own libraries or initiatives end to end: design, implementation, documentation, versioning, and the migration path for everyone already depending on the old version.
Architecture is a large part of this role.
Many engineers work in the same monorepo, which means module boundaries, dependency direction, and ownership are not academic concerns - they decide whether the codebase stays navigable or slowly turns into something nobody can change safely.
You will help define those boundaries, make the structural calls that keep teams from stepping on each other, and do some work to enforce them: writing the RFC, adding rules, untangling the cycle that shouldn't have been there.
None of this happens in isolation.
You will work closely with other teams who consume and use what you build.