"Shifting the Burden": How We Became Addicted to Other People's Problems
System Thinking 101
Why does every technical decision meeting sounds like a late-night infomercial? "Struggling with user authentication? There's a service for that! Can't handle file uploads? There's a service for that! Need to send emails? Why build it when you can just integrate with..."
Six months later, you're juggling API keys for seventeen different services, debugging integration failures that span four time zones, and explaining to your CEO why a outage at some startup in San Francisco just took down your entire checkout process.
Welcome to "Shifting the Burden"—the systems archetype that explains how we accidentally outsourced our core competencies to whoever had the shiniest API documentation.
Understanding the "Shifting the Burden" Pattern
"Shifting the Burden" is a deceptively simple archetype that shows up everywhere in complex systems. Here's the basic pattern: When a problem appears, there are usually two ways to address it—a quick external fix or a longer-term internal solution. The external fix provides immediate relief and makes the problem "go away," but it has a sneaky side effect: it prevents us from building the internal capabilities we actually need.
Over time, this creates a dependency cycle. Each time we choose the external solution, our internal muscles atrophy a little more. The more dependent we become, the less capable we are of handling similar problems ourselves, which makes the external solution seem even more necessary. What started as a convenient shortcut becomes a structural addiction that's incredibly hard to break. In software systems, this pattern explains why many companies find themselves trapped in a web of dependencies they can neither control nor escape.
The "There's a Service for That" Syndrome
Fiction: Your startup needs to handle user authentication. You could build a solid auth system—research best practices, implement secure password handling, set up proper session management. But that'll take weeks, and your competitor just launched their beta.
Then someone mentions Auth2. "Why reinvent the wheel? It's battle-tested, handles OAuth, has great docs..." Twenty minutes later, you've integrated their SDK and authentication is "solved."
Fast-forward eighteen months: Your auth provider raises prices by 300%. Your users are experiencing random login failures because of issues in their infrastructure. You want to implement a custom login flow for enterprise customers, but you're locked into whatever features they decide to build. The simple change that would take two days if you owned the code now requires a support ticket, a feature request, and a six-month wait.
You've successfully shifted the burden of authentication to someone else. The problem? You also shifted away your ability to control one of the most critical parts of your user experience.
The Modern Dependency Buffet
The Email Outsourcing Special:
"Why build email sending when SendGrid exists?" → Deliverability becomes someone else's problem → Your marketing campaigns are at the mercy of their reputation and rate limits
The Payment Processing Hand-off:
"Stripe handles all the complexity!" → PCI compliance becomes their problem → You're locked into their fee structure and limited by their feature roadmap
The Analytics Delegation:
"Google Analytics tells us everything!" → Data analysis becomes their specialty → Your data lives in their silo, accessible only through their interface and subject to their algorithm changes
The Search Service Shuffle:
"Elasticsearch as a service!" → Search infrastructure becomes their expertise → Performance tuning, data modeling, and cost optimization are now support ticket conversations
The Notification Outsourcing:
"Push notifications? There's Pusher for that!" → Real-time communication becomes their domain → Your user engagement features are limited by their WebSocket reliability and pricing tiers
The Hidden Cost of Convenience
What's really happening when we shift these burdens is that we're not just buying a service—we're selling our future flexibility. Each integration creates a small dependency, a tiny loss of control, a minor constraint on our technical evolution. These seem insignificant individually, but they compound like interest.
Your architecture starts looking like a complex Rube Goldberg machine where half the components are in other people's data centers. You become the integration specialist for your own product, spending more time managing vendor relationships than building features your users actually want.
The longer you rely on external solutions, the scarier it becomes to bring them in-house. Your team loses the institutional knowledge of how these systems work. The gap between "we use a service for that" and "we could build that ourselves" grows until it feels impossible to cross.
When Shifting Makes Sense (And When It Doesn't)
Smart Burden Shifting: Commodity services far from your core business (payment processing, SMS delivery, DNS hosting)
Dangerous Burden Shifting: Core capabilities that differentiate your product (user management, data processing, search algorithms)
The Gray Zone: Everything else—where the decision depends on your team's capabilities, growth stage, and strategic priorities AKA Context
The key question isn't "Can someone else do this for us?" It's "Should someone else control this for us?"
Architect's Alert 🚨
The most dangerous thing about "Shifting the Burden" is how reasonable it sounds in the moment. "Focus on your core competency! Don't reinvent the wheel! Ship faster!" These aren't wrong principles, but they become problematic when every technical decision defaults to "let's find a service for that."
Remember: Every service you depend on represents a decision you're giving up. Every API you integrate is a vote for someone else's roadmap over your own. The goal isn't to build everything yourself—it's to be intentional about what you choose to control and what you choose to delegate.
Breaking the Dependency Cycle
Want to escape the "Shifting the Burden" trap? Start asking better questions:
Before adding a new service:
Is this core to our business differentiation?
What happens if this service disappears tomorrow?
Are we solving a knowledge gap or a capacity constraint?
What would we lose by not owning this capability?
For existing dependencies:
Which services could we realistically bring in-house?
What vendor lock-in are we comfortable with?
Where are we paying the "convenience tax" that no longer makes sense?
Sometimes the best architectural decision is to do the hard work of building something yourself. Sometimes it's choosing temporary inconvenience over permanent dependency.
Your Turn
Look at your current architecture: How many external services are in your critical path? Which dependencies felt like good ideas at the time but now feel like constraints? If you had to rebuild your system from scratch today, which services would you still choose and which would you bring in-house?
Your dependency map tells a story about what you value: speed versus control, convenience versus capability, someone else's roadmap versus your own. What story is your architecture telling?
While in this article I focused mainly on SaaS dependencies, but this works in a very similar way to libraries that you bring in your code base.
I realize that all this might sound a bit daunting in the current AI ecosystems, but you could still use ElasticSearch, but self-host, and this gives you best of both worlds.