We’ve spent the last decade optimizing for scale. How do we handle more traffic? More users? More engineers? The assumptions were baked in: Growth is coming. Prepare accordingly.
So we split things apart. We mapped services to teams. We built for the org chart we were about to have.
Then 2023 happened. And 2024. And now 2025.
Turns out, the future isn’t always bigger.
The Question Nobody’s Asking
What if your team gets smaller? Not as a failure scenario. As a design constraint.
What if you architect with the assumption that in three years, you’ll have less capacity than you do today? Less engineers. Less time. Less runway to maintain complexity.
How would that change what you build right now?
The Playbook We Borrowed Doesn’t Fit
A lot of engineering leadership came from places where growth was a given. Amazon. Google. Netflix. Facebook. They brought their playbooks with them. Microservices. Team autonomy. Service boundaries.
Great ideas. When you have the teams to staff them.
The rationale made sense: Big teams step on each other’s toes. You need boundaries so people can move fast without coordination overhead. But most companies don’t grow like FAANG. Most companies hire in waves and contract in cycles.
Yet we’re still designing like growth is inevitable.
Most of the splitting we do isn’t for compliance or security. It’s organizational. We split things because we have teams. And teams need ownership. Fair enough. But then what happens when the teams go away and the repos stay?
The Repo-to-Engineer Ratio Nobody Tracks
Here’s a question I keep coming back to: What’s a healthy ratio of engineers to repos?
If you have 15 engineers responsible for 50 repos, something’s wrong. Not touching them. Just… responsible for them. Who’s keeping those repos updated? Who’s patching dependencies? Who’s maintaining CI/CD pipelines across all of them?
Here’s what usually happens: You have a team of 15 engineers and 14 of them aren’t even thinking about those 50 repos. It’s that one hyper-motivated engineer who created them all. The one who knew where everything was. The one who kept mental track of dependencies and deployment quirks.
Then they got a new job last year.
Now you have 50 repos. And nobody who really owns them.
Some companies solve this with platform teams. Dedicated engineers who keep the infrastructure healthy so product teams can focus on features. Great strategy. If you can afford it.
But what about the teams with 10-15 engineers who already have 30-50 repos and no platform team? They don’t have a platform team. They are the platform team. And the product team. And the infrastructure team.
Every repo is another thing to maintain. Another place for secrets to live. Another pipeline to keep green. And when that one person who understood how it all fit together leaves? You’re left holding the bag.
Redundancy vs. Excess
A resilient team isn’t one that can do everything. It’s one that can absorb change.
Redundancy is about people, not systems. It means two people can deploy. Three people understand the payment flow. Someone can go on parental leave and the app doesn’t fall apart. It means you’re not hit by the bus factor. That dreaded moment when the one person who knows how something works leaves and you’re stuck reverse-engineering their decisions.
Redundancy is good. It’s insurance against reality.
Excess is different. Excess is ten services that could’ve been three. Four repos when one would do. Coordination overhead that only makes sense if you have twice the people.
We need redundancy. We can’t afford excess.
Design for the Team You Might Have
Here’s a thought experiment: What if you designed your architecture assuming your team would be half its current size in two years? Not because you’re pessimistic. Because you’re realistic.
Would you still split that app into twelve services? Would you still introduce that new framework? Would you still custom-build that thing you could’ve used a library for?
Maybe. But you’d think harder about it.
What This Looks Like in Practice
Architecture for contraction means:
Prefer monoliths until you have a really good reason not to. Splitting things up creates coordination costs. Make sure you can afford them long-term. And “we might hire more engineers” isn’t a good enough reason.
Count your repos. Seriously. How many do you have? How many engineers touch them regularly? Is that ratio sustainable if three people leave?
Optimize for fewer moving parts. Every service is another thing to deploy, monitor, and maintain. Every repo is another place things can break.
Build for handoffs. People leave. They go on vacation. They take parental leave. Your architecture should assume the person who built it won’t always be around to maintain it.
Reduce cognitive overhead. If it takes three weeks to onboard someone, your architecture is too complex. Simplify until it takes three days.
Resist the urge to “get ahead of it.” You don’t need the architecture for 100 engineers when you have 20. You really don’t.
So What Do We Do?
Start asking different questions:
Not “how do we scale this?” but “how do we keep this simple?”
Not “what does this look like at 10x?” but “what does this look like at 0.5x?”
The playbook for growth is everywhere. It’s well-documented. It’s what got funded for a decade.
But we need a different playbook now. One that optimizes for durability, not growth. One that assumes less, not more. One that doesn’t mistake complexity for sophistication.
Because the team that can do more with less isn’t just efficient. It’s resilient.
And resilience is what we need right now.
Need Help Getting There?
If you’re reading this and thinking “we have 50 repos and the person who understood them all left last year,” you’re not alone.
A lot of teams find themselves maintaining complexity they didn’t choose and can’t afford to rewrite. You don’t need a full platform team. You need someone who can help you consolidate, simplify, and build redundancy into what you actually have.
That’s what we do at Planet Argon. We work as a fractional platform team—helping Rails teams reduce complexity, improve maintainability, and build systems that don’t require heroics to keep running.
If that sounds like something your team could use, let’s talk.
