Scaling a Kotlin Backend Team: Three Lessons We’ve Learned

Over the past couple of years, we’ve grown the Kotlin backend team responsible for Lendable’s Super App from just two engineers into multiple teams.

1. Monoliths Don’t Scale for Developer Experience Either

Breaking up monoliths is usually discussed in the context of performance and scalability. But as our engineering team grew, we quickly found that monolithic systems can also become a major blocker from a developer experience perspective.

Longer build times started to slow us down, and while merge queues helped initially, they couldn’t prevent PR clashes from becoming a regular frustration. Engineers began waiting longer for reviews, rebases became more frequent, and merging changes became harder than it needed to be.

A monolithic codebase also creates ownership challenges. With one large system, ownership can become murky, making it harder for teams to work independently and truly own their features end-to-end.

These issues pushed us to start developing new features in new services, and to plan the gradual breakup of our backend monolith - not only for technical scalability, but for the scalability of our engineering culture and processes too.

2. Tech Strategy and Leadership Groups Matter More as You Scale

As more teams began working on more products and services, we found that decisions we could previously defer suddenly became critical.

For example: our approach to messaging, how we document APIs, and how we test services. In the early MVP stage, when product-market fit was still uncertain, it made sense to prioritise speed and experimentation over aligning on deeper technical decisions.

But as we scaled, we needed clearer structures to guide technical direction across teams.

To support this, we formed tech leadership groups - a forum for tackling these cross-cutting topics collaboratively. Over time, this evolved into a more formalised tech strategy.

We’ve also established a dedicated Product Platform team whose remit is to work across all services and implement solutions to engineering challenges that impact everyone.

3. Standardisation Across Services is Hard But Worthwhile

Standardisation brings huge benefits for productivity and product velocity.

When services follow consistent patterns, engineers can move between teams more easily, we can adapt faster to shifting product needs, and we can spin up new services with less effort and lower risk. It also enables our platform team to operate far more effectively when solving organisation-wide engineering challenges.

That said, achieving standardisation across a growing number of teams and services is an ongoing challenge. Teams naturally want to diverge to solve immediate problems, and getting multiple teams to follow consistent approaches isn’t always easy.

We’ve found architectural decision records (ADRs), thorough documentation, and frequent touch points between backend engineers across teams to be useful tools for driving alignment. Even so, rolling out technical improvements consistently across all services remains a constant effort — but one that is absolutely worth it for the long-term health and scalability of our engineering organisation.

Final Thoughts

The biggest takeaway is that as our product and team grow, we need to scale not just our systems, but also how we work together.

And that way of working needs to keep evolving.