Adding a best-of-breed product to your stack looks cheap. The licence is a line item you can defend, the capability is real, and the team that wants it has done the evaluation. On the spreadsheet, it is obviously the right call.
The spreadsheet is measuring the wrong thing. Software cost is the part of a vendor relationship that is easiest to see and often the smallest.
What actually arrives with a new vendor
Every additional product tends to bring, at minimum:
- A procurement cycle
- A legal review of terms that differ from everyone else's
- A security assessment, and a re-assessment when they change something material
- A commercial relationship somebody has to own
- A billing model that does not align with your other billing models
- An operational model your team has to learn and remember
- A support escalation path, distinct from the other paths
- Renewal planning, on its own calendar
- Specialised expertise that becomes a person-shaped dependency
None of these appear in a feature comparison. All of them are real work with real people attached. And the cost is not linear -- it is closer to combinatorial, because the hard part is rarely any one product. It is the integration between them, and the number of integrations grows faster than the number of tools.
The failure mode nobody plans
The most expensive line item usually arrives during an incident.
Something breaks. The symptom is visible in the observability product. The cause looks like it might be in the gateway. The gateway vendor says the upstream provider returned an error. The provider says the request was malformed. The framework maintainers point out that this is application code.
Every one of those responses is accurate. And you still have an outage, because the failure happened in the space between four well-drawn boundaries, which is precisely the space nobody sold you support for. The person resolving it is on your team, at two in the morning, holding a problem that no vendor considers theirs.
Where consolidation is worth it, and where it is not
This is not an argument that specialist tools are bad. They are frequently the right answer, and being explicit about their organizational cost is not the same as refusing to pay it.
It is an argument for asking the question deliberately. A specialist tool earns its overhead when the capability genuinely differentiates you, when the alternative is materially worse, or when you have the depth to own the integration well. It does not earn it when the capability is table stakes that every project needs and nobody's business depends on being special.
Logging formats, credential handling, audit conventions, failover behaviour, and common access patterns are usually in the second category. They are decisions where local variation adds very little and costs quite a lot.
Counting properly
A better architecture evaluation adds three columns to the usual ones:
How many relationships will we manage directly? Not products -- relationships, each with its own contract, security posture, and renewal.
Who owns the gaps? For each pair of products that must work together, name the team responsible when they do not.
Where does accountability change hands? Draw the line on a diagram. If you cannot draw it, that is the finding.
Curated integration deliberately trades some breadth for coherence. The reduction in choice is not a limitation being apologised for -- it is the source of the value, because every option you do not have to evaluate is an option you do not have to procure, secure, operate, and renew.