Vercel

I used to keep prod secrets in encrypted files checked into git. This meant every deploy required decryption, every env had its own schema, and one careless moment leaked everything. The cognitive load was constant. I moved to the pattern where only env var names live in version control. I commit a .env.example that lists what keys must exist, nothing more. All actual values come from the runtime environment. For local dev I use direnv to load from a .env file that git ignores. For production, Vercel handles injection directly in the UI. Running direnv allow in a project directory loads the .env automatically whenever you cd into it. The.env.example file stays lean: API_KEY=, DATABASE_URL=, AUTH_SECRET=. If someone forks the repo, they see the shape of what they need without seeing actual values. A leaked .env.example is just a checklist. This breaks down in teams that refuse to use direnv or need secrets in CI/CD systems that don't integrate cleanly. If your pipeline expects files instead of environment variables, you end up bolting on an extra layer anyway. But for anything touching Docker or serverless platforms, this approach removes a whole category of mistakes.

I used to ship whatever I built first. The vibe coded version would go straight to production, and then I'd spend weeks untangling it because the code was optimized for speed, not clarity. Claude and I would just keep patching things, and eventually I couldn't even remember why certain decisions got made. Then I started treating prototypes like actual disposable prototypes instead of secret first drafts. I build the thing fast with Claude, get it working, understand what I actually need, then I start completely over with a real spec. The second version gets written deliberately with the person who'll maintain it in mind. It's weird but it works. When I start the rewrite I always run `vercel env pull` first to make sure I have the actual production config, then I'm building from a fresh Next.js template and a spec that's just a few sentences about what this needs to do and why. The prototype taught me what the thing should be, and now the real code gets to be what it should look like. The caveat is that this only works if the prototype is actually fast to build. If it takes you two weeks to prototype something, rewriting it from scratch is going to feel ridiculous. This technique is for the stuff where you can throw together a real working version in a day or two, learn what you need to learn, and then do it right.