Systems without unnecessary captivity

COTS, ecosystems, and the right to leave.

Ready-made technology can be the responsible choice. The real test is whether it preserves clear ownership, useful exports, replaceable parts, and a path forward that does not depend on one vendor—or one exhausted person.

August 25, 2026 Original analysis 6 minute read

Small organizations rarely need to invent every layer of their technology. They need systems they can understand, afford, recover, and change without turning routine ownership into permanent emergency work.

The useful question is not simply “buy or build?” It is: where should the complexity live, who remains responsible for it, and what happens when today’s sensible choice stops fitting tomorrow?

01 · COTS

Buying a shared solution can be a strength.

A standard product can bring established support, familiar workflows, documented behaviour, and skills that more than one person understands. Those are not signs of laziness. They can be signs that an organization has chosen to spend its limited attention on the parts that genuinely make it different.

Custom work still matters when a requirement is truly distinctive, when integration needs demand it, or when control over a critical function justifies the continuing responsibility. But “custom” is not automatically more independent. A one-off system that only one person can repair may create more captivity than a widely understood product with a clean export.

COTS is not the absence of engineering. It is a decision to buy a shared problem—and keep your own attention for the work that remains uniquely yours.

Andreacchi Digital field note

The honest tradeoff

Ready-made tools can also change their prices, interfaces, policies, or product direction. Integrations can become dependencies. An export can exist without being useful. The ethical response is not to frighten people away from every vendor. It is to identify the dependency, explain its practical effect, and preserve choices where the cost is proportionate.

02 · Ecosystems

A healthy ecosystem has an exit plan.

An ecosystem is more than a list of products. It is the set of accounts, identities, domains, data, integrations, people, and procedures that must cooperate for useful work to happen.

Healthy ecosystems reduce duplication while keeping responsibility visible. Unhealthy ones make every change feel dangerous because nobody can say which account owns what, where the data can go, or what breaks when one component disappears.

Ownership can be named.
The organization knows who controls its domain, billing, primary accounts, data, and recovery methods. Access is not confused with ownership.
Useful information can leave.
Exports are understandable enough to support recovery, reporting, or migration—not merely a technical box marked “download.”
One part can be replaced.
A reasonable component change does not require rebuilding the entire operation or abandoning unrelated information.
The system survives memory.
Important connections, responsibilities, and recovery steps are documented instead of living only in one person’s head.

This does not mean every tool needs an immediate substitute waiting beside it. It means the organization understands where switching would be difficult and makes that dependency deliberately rather than discovering it during a crisis.

03 · Automation

Automate repetition, not accountability.

Automation is most useful when it makes routine work quieter: checking whether a site responds, confirming a certificate is healthy, recording a release, or noticing that disk use has crossed a clear threshold.

It becomes risky when a system quietly expands its own authority, changes production without an understood recovery path, treats an AI-generated conclusion as certainty, or moves confidential information somewhere nobody explained.

A responsible operating model keeps the boundary simple: machines can collect evidence, repeat bounded checks, and prepare drafts; a responsible human approves material changes, owns communication, and remains answerable for the outcome.

Minimum necessary access.
An automated task receives only the permissions and information required for its specific job.
Visible limits.
People are told what is checked, what is not checked, and what a passing result does—and does not—mean.
A safe failure state.
A failed check should stop, preserve evidence, and avoid turning a small fault into a larger change.
Human responsibility remains.
Automation supports judgment. It does not become an excuse for hidden decisions or abandoned accountability.

04 · A practical decision

Choose the smallest ecosystem you can responsibly own.

A good system is not the one with the longest feature list. It is the one that supports the real work, has understandable boundaries, preserves recovery options, and can be operated without chronic heroics.

Before adding another platform or custom layer, write down the problem it solves, the information it receives, the account that controls it, the cost of keeping it, the way out, and the person responsible for reviewing the decision later. If those answers are unclear, another integration may be adding uncertainty rather than capability.

That is the quieter promise behind reliable digital operations: not perfect independence, and not fear of every vendor—just deliberate dependencies, documented choices, and enough room to change direction.