Working with microservices in a startup-sized dev team is a bit like juggling on a unicycle. 🎪
It's flexible, scalable, and empowering — but also demanding when you have limited hands (and hours) to keep everything running smoothly.
What we're actually doing
At Waitly, we've started building a modular architecture where our core app is gradually being decoupled into independently deployed services.
The goal is to gain speed, autonomy, and clearer responsibility boundaries. But it already requires careful orchestration, shared ownership, and constant focus on observability, security, and resilience.
There's no "and then we just split the service" moment. It's incremental, sometimes ugly, and you discover hidden coupling every time you try to draw a clean boundary.
What I've learned
Microservices can shine even in small teams — if you invest in the right tooling, deployment processes, and communication habits. Without those, you've just turned a monolith's complexity into distributed complexity, which is much harder to debug. With them, you actually get the speed and autonomy promise.
There's no such thing as "just a backend" or "just a frontend." You need generalists who can collaborate tightly across domains. The team has to understand the seams. A backend dev who can't reason about the frontend's expectations will design APIs that hurt everyone.
Prioritization is key. We can't build everything — so stability, GDPR, and clarity always trump bells and whistles. In a small team, every "nice to have" is a real cost somewhere else.
What I focus on day to day
Strengthening our technical foundation, maturing key services, reducing incident load, and ensuring that what we build is sustainable and secure — even as new things are added on top.
The hardest part isn't designing the services. It's designing the operational discipline that keeps them maintainable when one person is responsible for three of them at once.
Curious how other small teams tackle this — or if you're building something similar, let's talk.