Eight situations, worked through
Concrete setups people actually have, what breaks in each, and exactly which parts of the product apply — including the parts that do not.
These are scenarios, not customers. We have not put a company name, a quote or a saved-hours figure on any of them, because we would have had to invent all three. Each one describes a setup we designed for and what the product does about it.
One developer, eleven side projects
No team, no compliance requirement, and a key problem anyway — because the projects outnumber the memory.
Read the scenario →The first hire needs the keys on day one
Two people is the point where "just send it to me" stops being a workable process, and it is also the point where nobody has time to set up anything better.
Read the scenario →Twelve clients, and their keys must never meet
Client credentials are borrowed, not owned. Mixing them up is a professional problem before it is a technical one.
Read the scenario →The key that leaks is the one with a credit card behind it
A leaked model API key is not a data breach. It is a bill, and it arrives fast.
Read the scenario →The project ships, and then it belongs to someone else
Handover day is when every credential decision made over six months comes due at once.
Read the scenario →The repository is public and the secrets are not
Maintaining something public means every accident is public too, immediately and permanently.
Read the scenario →The engagement was three months and the access was not
Time-boxed work does not automatically produce time-boxed access, and the gap is invisible until it matters.
Read the scenario →Development, staging and production, three times over
The same eight variable names with different values in each environment, and one file that decides which is which.
Read the scenario →