Sample content: This article exists to exercise the publishing system. It is not presented as Patrick’s writing.
The Hidden Cost of Just One More Service
A sample architecture analysis of the operational, organizational, and exit costs concealed behind a seemingly small service dependency.
Adding a service often begins with an appealing comparison: a few API calls instead of months building a capability. That can be exactly the right decision. The mistake is comparing implementation effort while ignoring the relationship the system must operate afterward.
The true unit of architecture is not the package or endpoint. It is the responsibility the team accepts.
Trace the dependency beyond the happy path
Copy link to section “Trace the dependency beyond the happy path”A production dependency creates questions that a quick integration rarely answers:
- How are credentials issued, rotated, and revoked?
- What happens when requests are slow, duplicated, or unavailable?
- Which data leaves the system, and under what terms?
- How will cost change with traffic or usage shape?
- Who responds when the provider changes behavior?
- Can the product keep working in a degraded mode?
- How would the data and workflow move elsewhere?
These are not arguments against services. They are part of evaluating one.
The best managed services remove substantial undifferentiated work and operate it better than the team reasonably could. The cost is a dependency on another organization’s interfaces, priorities, economics, and failure modes.
Count organizational surfaces
Copy link to section “Count organizational surfaces”A service may touch engineering, security, legal, finance, support, and product. Each surface adds coordination even when the technical integration is clean.
| Surface | Hidden work |
|---|---|
| Reliability | Timeouts, retries, rate limits, incident communication |
| Security | Secret handling, access review, vulnerability response |
| Privacy | Data mapping, disclosures, retention, user requests |
| Finance | Usage forecasting, invoice review, spending controls |
| Product | Degraded behavior, user messaging, roadmap dependency |
| Exit | Export, replacement, migration, contract timing |
Small teams feel these costs sharply because one person may own several surfaces. Large teams can hide them in organizational boundaries, but the cost still exists.
Compare against the real alternative
Copy link to section “Compare against the real alternative”“Build versus buy” is often framed unfairly. The build estimate may include production quality, while the buy estimate includes only the first successful request. Or the internal alternative may be imagined as a fully custom platform when a smaller capability would meet the need.
Compare complete options at the same service level. Include setup, ongoing operation, expected change, compliance needs, and opportunity cost. Also consider what the service enables the team not to learn or staff. That can be a major benefit when the capability is far from the product’s differentiation.
Design the boundary before the adapter
Copy link to section “Design the boundary before the adapter”An adapter can make a provider replaceable in code while the product remains deeply shaped by its semantics. The more important boundary is the product contract: what the system promises, which data it owns, and what degraded behavior is acceptable.
Keep provider-specific identifiers and payloads from spreading without reason. Retain the source data needed for migration. Test failure behavior. Document the small set of features that make the dependency valuable so future teams know which coupling is intentional.
Revisit the decision with evidence
Copy link to section “Revisit the decision with evidence”Service decisions are not permanent simply because migration is inconvenient. Review them when cost shape changes, reliability becomes product-critical, contractual terms shift, or the dependency blocks important work.
Do not migrate because a bill feels emotionally large without comparing replacement cost. Do not remain because the original integration was easy. Use current evidence.
One more service can be an excellent trade. It becomes dangerous when the organization accepts the operating relationship without seeing it.
