Staff Engineer (Builder)
at Famly, Copenhagen, Denmark
Listed on EduAtlas: live school vacancies from schools’ own careers pages and public job services. Apply on famly.recruitee.com.
- Salary
- Not given in the advert
- Closing date
- Open until filled
- Start
- Not given in the advert
- Type of post
- IT and technicians
A support post, not a teaching post. - First seen
- 9 November 2026, on a public job listing
On famly.recruitee.com · Send it by: WhatsApp · LinkedIn · Email · X
Find posts like this from Claude: add EduAtlas to Claude.
The advert
Raising a young child takes a village: families, educators, and everyone else in a child's early life. But too often those grown-ups work in isolation from each other, and from the information that would help them nurture a child together. Famly is the early childhood platform that closes that gap. One place for the adults around a child to connect, share the workload, and learn, so they can focus on the early interactions that count. For over a million parents it's how they stay close to their child's day, for educators it's how they collaborate with families and each other (and get the boring admin off their plate), and for providers it's how they run a thriving setting. All of it in service of a better start for every child.
We're looking for experienced engineers to help us make it better. We call them Builders. Right now we have two open spots, both of them backend-first, and both in the parts of Famly where the complexity is the highest.
Both are staff level: we're looking for people who've designed systems other engineers then built on, gone deep in something exacting, and made the teams around them better rather than only their own output — how we test, review, and design, and how we use AI, included.
All that being said, you'll still be surrounded by kind and clever colleagues to spar with every day.
Open positions
Finance - Billing, Payments & Funding
Fees are where a nursery's goodwill gets tested. Parents want a bill they can understand, owners want the money actually in the bank, and the person in the office wants an evening back instead of a spreadsheet reconciling government funding against 200 children's attendance. Childcare pricing is awkward by nature: fees per session and per product, sibling discounts, deposits, surcharges, credits, and public funding that changes shape in every market.
What the team takes care of
• Plans and pricing - pricing structures and bands, session and product catalogues, term dates and attendance schedules, discounts, deposits, surcharges, and the plans that turn a child's schedule into a bill
• Invoicing - invoice runs and batch reissues, billing schemes from actuals to annualised, bill payers and how one child's bill splits between them, credit notes, and balances
• Payments - card and direct debit through Stripe, autopay, parent bookings and ad hoc purchases, UK Tax-Free Childcare, and payment methods that differ market by market
• Getting paid - debt collection with overdue buckets, payment reminders, bank statement imports, and the revenue and debt reports owners run every month
• Public funding - UK funded hours, entitlements and eligibility codes, US state subsidies with parent copay, German parental contributions, and the reports that claim the money back
• Accounting exports - the chart of accounts and exports into DATEV, Sage, Xero, and Quick Books, so the numbers land where a finance team already works
Every number here is someone's money, and a rounding error is a phone call from a parent. Precision matters, though it rarely means one right answer. Where regulation is exact (funded hours, tax rules, what a direct debit mandate allows) the code has to match it to the decimal. Everywhere else, a nursery in Berlin prices care nothing like a nursery in Ohio, so the work is giving each of them room to do it their way without handing them a blank spreadsheet. Drawing that line well, over and over, across markets, is most of the craft here.
One honest note for a backend engineer: Finance carries more of our remaining PHP than most teams, alongside a lot of Scala. Moving it across is part of the job, and it comes with the kind of ownership that only old, critical code gives you.
Finance is a team of 14. Eight Builders (plus the one we're hiring), two Product Managers, two Designers, and a Head of Product.
Frameworks - the ground every other team builds on
Some problems don't belong to any one team. They turn up on every screen, no single team owns them, and each one quietly decides how fast the rest of Famly can move. That's Frameworks. You build the foundations other Builders build on, and when they're done right, the teams using them barely have to think about them.
What the team takes care of
• Unified profiles - one profile for a child and one for a member of staff, that every corner of the product reads from and writes to
• Custom data fields - the things a provider needs to track that nobody at Famly thought to ask about, without us shipping a hardcoded bespoke field for each one
• The shared toolkit - the data models, APIs, and patterns a dozen teams build their features on, and the work of keeping them coherent as the product grows
The hard part is rarely any single feature. It's designing something general enough that six teams can use it and sharp enough that it's actually good for each of them. Get that wrong and every team routes around you. Get it right and it disappears into how Famly works. At our scale, anything cross-cutting sits on a hot path by definition, so data modelling and performance are the daily craft rather than an occasional concern.
We'll be straight about the size, because it shapes the job. Frameworks is one Builder today, and you would be the second. That means unusual influence over what gets built and how, and a scope you shape rather than inherit. It also means this isn't a big group all pushing at the same feature — the teams you build for are your closest collaborators, and there are plenty of them. But the appetite for shaping something from a standing start needs to be real.
Frameworks is a team of 3: one Builder, the Builder we're hiring, and Michael, our Director of Engineering. The team is part of the Enablement space, where a total of 6 other Builders work and social events are done together. We have ambitions to scale the team even more over time and you will be surrounded by many talented colleagues that you can spar with.
About the role
At Famly, engineers are called Builders, and it's not just a nicer word for a developer. A Builder owns work end to end: not just writing the code, but shaping the problem, scoping the solution, and shipping it. You'll work across a large and mature codebase.
Both of these roles are backend-first. Most of what you build lives in Scala (we've just upgraded to Scala 3), close to the data and the rules, and there's some PHP that we're actively migrating away from, so you'd spend time in it, but the direction of travel is clear. It runs on AWS and Kubernetes, backed by MySQL, at real scale: over a million users and around 15,000 requests per second at peak. Enough load that the hard problems are hard.
The frontend is React and Type Script, and our teams work full stack. We're not asking you to become a frontend engineer, but the Builders who get the most done are the ones who'll follow a feature all the way to the screen rather than hand it over at the API. If you've done that before, or you'd like to, say so.
We're not looking for a Scala expert. We want a strong engineer who is curious, technology-agnostic, and not put off by an unfamiliar language — the kind who has learned several stacks over a career and knows the letters on the tin matter far less than the thinking.
How we actually work
This is where Famly differs from a lot of engineering teams, so we'll be straight about it. It suits some people brilliantly and isn't for everyone.
High autonomy, high ownership. There's no one handing you a ticket with the answer already in it. You pull work from a prioritised board and own its refinement — the problem framing, the scope, the open questions — before you build. For most tasks that means writing the problem statement yourself; for bigger projects, breaking them into shippable slices with your colleagues.
Getting it done, but knowing when done is not enough. Kanban, no sprints, no story-point estimates. We size work by appetite (how much time it's worth), not by guessing effort. Builders judge what’s good enough and what needs extra care.
We think together, not just alongside each other. Autonomy doesn't mean alone. A short daily keeps us aligned and Linear is our shared source of truth, but the real work happens in the sparring: bouncing an approach off a colleague, pairing on something gnarly, reviewing each other's work, and talking problems through before and while we build. You own your work, but you're never stuck on it by yourself.
Chapters and guilds connect us across teams. Beyond your team, Builders come together in cross-team chapters and guilds to share craft, align on how we build, and learn from each other, so good ideas and hard-won lessons don't stay trapped in one team.
AI is part of how we build
We experiment with AI and agentic coding to work faster and better, and we share openly across the teams — when someone finds a workflow that helps, they pass it on, and when something flops, we say that too. One current experiment auto-generates PRs from our error monitoring. If you're keen to help work out what AI can actually do for a real engineering team, rather than just talk about it, you'll be among people doing the same.
You'll thrive here if