I Got Tired of Sharing `.env` Values Over Slack

There is a small problem I have seen in almost every development team I have worked with. Someone adds a new environment variable, updates `.env.example`, opens a pull request, and eventually merges it. A few hours later another developer pulls the latest changes and the application stops working because their local environment is missing the new value. What follows is usually a Slack message asking where the value is, followed by a DM, a password manager link, an old `.env` file, or somebody copying the value directly into the conversation.

None of this feels serious enough to justify a large infrastructure project. It is usually solved in a minute or two, which is probably why teams tolerate it for years. But it keeps happening. New developers join, people switch machines, repositories gain more services, environment variables change, and the same small interruption repeats itself.

What bothered me most was that the rest of the development workflow had already become quite structured. Git tells us exactly which version of the code we have. Package managers describe the dependencies required to run it. Database migrations describe changes to persistent state. CI verifies that a pull request satisfies a set of expectations before it gets merged. Local environment variables, however, often remain a piece of state that exists mostly through convention and team memory.

A committed `.env.example` helps, but only partially. It tells me that `STRIPE_SECRET_KEY` now exists, but it does not tell me how my machine should obtain the value or whether the version I already have is still the one the team expects.

I started building local.env around that gap.