Staff Engineer (Builder)

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 QuickBooks, 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.