Deletability

Deletability is the property of a well-designed business system that it can be removed from a company's operations in about a week with no business impact: data exported in open formats, integrations redirected, a documented manual fallback for the workflow it served. A system that cannot be deleted carries hidden coupling — and a switching cost the buyer never agreed to pay.

Why it matters

Switching cost is a defect from the buyer's side, not a vendor asset. A vendor who says "you should stay, because leaving would be hard" is selling the solution to a problem they created. Deletability is also a forcing function: designing for it produces modular architecture, clean documentation, and a neutral data store — the same properties that make a system operable at all.

Common confusion

Deletability is not an anti-retainer position. A retainer is legitimate when the client chooses it for its value — availability, continuity, engineering depth — rather than being held by the cost of leaving. It is also not only a contract clause: in practice it is a delivery structure, where every phase of a build ends with something finished and working.

Where we use it

The exit clause in What to check before you sign, and the sequencing argument in One app or four?.